Summary:
Bruce Eckel talks with Bill Venners about how Python's minimal finger typing allows programmers to focus on the task, not the tool, generating a productivity that makes more projects feasible.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: November 4, 2003 0:31 AM by
Anand
|
Bruce Eckel says, "The main sources of productivity [when programming in Python] are that I am able to look at more lines of code on the screen, put more meaning into fewer lines of code, read and understand code more easily, and deal with higher level concepts." Read this Artima.com interview with Bruce Eckel: http://www.artima.com/intv/tipping.htmlWhat do you think of Bruce's comments?
|
|
|
I'd say that the most demotivating factor to adopt Python currently is the absolute lack of decent IDEs. If, for a moment, we could have a Python plugin for Eclipse, including the support for refactoring, unit tests, hot debugging, and so on, things could be really different.. But it seems that the work to support Python in Eclipse (for instance, again) is stalled. And, in any case, strong typing seems to be useful for IDEs, which can handle things such as autocompletion more efficiently, although the bloat.
|
|
|
I have to admit I'm getting very bored of articles which do nothing more than ramble on about how great Python is. I'm using it myself, and sure, it's a pleasant language. But I'd prefer to have less advocacy and more technical content - why not dissect one of the utilities mentioned in this article and explain how it works?
|
|
|
I have to agree with Edwin's comment. I learned Python and use it for some things, and it is a very enjoyable language to use. But alleged experts like Bruce Eckel are irritating, in that they make grandiose claims like "Python programmers are more than 10X as productive as Java programmers" with absolutely no evidence to back them up.
For example, many of Eckel's reasons for preferring Python seem more centered on personal preference on syntax, or the design of specific libraries, rather than on any radically greater expressive power in the language. In the latest installment of the interview, he made a big issue of the fact that Python is a little more "compact" so more lines of code fit on his screen at one time. Does this lead to 10X productivity?
Without more information or detail, it comes across as empty hype. What types of applications is he writing? What is the scale? Is he working in a team or by himself? Are there any cases where Python didn't work out as well as expected?
Again, as I said I like Python and use it where it is appropriate, but I am not yet an expert. I am going to continue using and exploring it, but the unrelenting hyperbole (like some of the early hype about Java) is doing the language a disservice.
|
|
|
> I have to admit I'm getting very bored of articles which > do nothing more than ramble on about how great Python is. > I'm using it myself, and sure, it's a pleasant language. > But I'd prefer to have less advocacy and more technical > content - why not dissect one of the utilities mentioned > in this article and explain how it works?
Thanks for reading, and for giving feedback. I do care very much about what readers want, and how they feel about existing articles, and use that feedback to guide editorial decisions in the future.
When I did this interview, I wasn't interested in Python advocacy. I was interested in exploring the various ideas and reasons behind Bruce's self-proclaimed "love" of Python. Bruce and I teach a design seminar together and, as a seminar attendee once put it, Bruce is indeed "enamored" with Python. In his career, he has gone through C, C++, and Java before getting to Python. I wanted to know why he likes Python so much compared to these other languages. I suspected that hidden in those reasons would be generic issues about programming that were worth publishing, and those issues were main reason I published this series.
For example, in this installment, some ideas I find interesting, which I think would be good topics for discussion are:
1. The increased productivity Bruce experiences from Python's economy of syntax is not less finger typing, but the reduced mental clutter that he finds accompanies the reduced syntax. This is not just a Python issue, it is a generic issue about programmer productivity.
2. I thought Mark Lutz's comment in Programming Python about Python leading you down the path to code without planning was very interesting. Bruce's reaction was pretty much what Mark Lutz also said in the rest of the section I quoted: that you can refactor something you've whipped up without a plan, and that the design you can come up with after some coding is often more accurate than what you can come up with beforhand by just thinking. But once again, I don't really see this as a Python issue. It is a question about programmer productivity in general. How many obstacles and speed limits should the tool put in the way of the programmer for the good of the programmer. What's the right balance?
3. I also thought the idea of a tipping point for programming was quite interesting independent of Python. If the act of collecting and expressing your programming thought to the machine is made orders of magnitude more efficient, whether through Python or Ruby or Java or your favorite IDE or whatever, suddenly people will start doing things with programming that they never considered before, because the payback wasn't worth the cost. Reduce the cost sufficiently, and there's a cascading effect. I haven't experienced that myself, but I'm curious if others have and how they got there.
But you're right that there's also a lot of Python advocacy in this article, at least in tone, simply because Bruce really does love programming in Python. (I don't think it is marketing hype, per se, because Python is open source. I.e., I don't think Bruce will make any money if you use Python.)
My editorial intent is to give voice to lots of different opinions and perspectives on this site, and Bruce's is one of them. The Pragmatic Programmers gave a few plugs of Ruby in their interview. James Gosling, Josh Bloch, and Guido van Rossum in their interviews all gave their respective opinions on static versus dynamic typing.
But I'm also keen to hear what kind of articles you'd like to read, such as your call for more in-depth, practical tech articles. So feel free to post your article wish lists.
|
|
|
I wonder if either you or Bruce are familiar with Ruby. I myself find ruby more pleasing to read and write then python. It would be interesting to me to read the musings of somebody who was experienced in both languages.
|
|
|
I'd have to agree with the previous posters. When I read a comment like With Python and some sort of build system, such as ant or make files, I can automate everything. And I've found that to be incredibly powerful. I often use make with a lot of Python programs. For example, the CD-ROMs I sell are all generated with a single make command.
I think to myself With these tools we can more or less do what people have done with unix for the past 25 years (see footnote 1). {/i]
In other words, Python allows me to learn an entirely new way of doing something we already know how to do.
I think I would be a bit happier if the article actually explained how and why the author's solution is superior to, say, an older solution which did not employ python for this task.
I would be happier still if the author were to specifically demonstrate some innovative feature of python. For example, how python allowed him to do something like generate a completely different kind of output by simply changing which rendering module is imported or how he could generate his complete cdrom on a machine containing none of his source text simply by using urlopen() in place of open()...
The section "Utilizing Higher-Order Functions in Text Processing" of David Mertz's "Text Processing in Python" http://gnosis.cx/TPiP/chap1.txt is the kind of thing I really enjoy reading.
In that section David introduces the reader to a wonderful set of extremely powerful and useful higher order functions and demonstrates some of the actual features of Python which make it superior to other tools.
Cim
Footnote 1: See sections titled "3 Text Processing Tools" and "4.4 make" of http://www.daemonnews.org/199903/history.html
|
|
|
> My editorial intent is to give voice to lots of different > opinions and perspectives on this site, and Bruce's is one > of them. The Pragmatic Programmers gave a few plugs of > Ruby in their interview. James Gosling, Josh Bloch, and > Guido van Rossum in their interviews all gave their > respective opinions on static versus dynamic typing. And I think that your readers do appreciate that -- Artima.com is undoubtedly one of the best web sites for programming-related articles on the web. Speaking from personal opinion, Artima's interviews are always a great read, and the guests are generally the people I'm most interested in reading about. > But I'm also keen to hear what kind of articles you'd like > to read, such as your call for more in-depth, practical > tech articles. So feel free to post your article wish > lists. I would really like to read an article like that, as long as it maintained the existing quality of the content on this site. Especially with regard to Python programming, because I'm not very good at it. I mean, I understand the language and know some of the standard modules, but I find that when I write Python, I tend to write it as if I were writing Java, and don't end up taking advantage of the legendarily easy-to-use dynamic typing, or Python-specific programming idioms, etc. But of course Java, Ruby, C, or Objective-C tips would all be cool to read too. Recently there was a Python column on O'Reilly's ONLamp.com about the coding style used in BitTorrent ( http://www.onlamp.com/pub/a/python/2003/7/17/pythonnews.html ). And I was really intrigued, since I think BitTorrent is pretty awesome software and there is presumably a lot that can be learned from the code. But while the article mentions a few things that are unique/interesting about the BitTorrent code, there are no specifics or samples taken from the code. Not even a hyperlink to the SourceForge CVS repository where readers can go to see it (although admittedly this isn't too hard to find). I understand that writing a "code review" style article would be very involving and probably take more time than an opinion or interview article. Not every site has the resources to do something like this all the time. But it is something that I think would be cool -- even a small one. One of my favorite articles from any site is Guido VanRossum's tips for using the if __name__ == "__main__" programming convention in Python ( http://www.artima.com/weblogs/viewpostP.jsp?thread=4829 ). It's simple, it's short, and it has changed the way I write Python code.
|
|
|
> I wonder if either you or Bruce are familiar with Ruby. I > myself find ruby more pleasing to read and write then > python. It would be interesting to me to read the musings > of somebody who was experienced in both languages.
I haven't tried Ruby yet, but I definitely plan to. A lot of people whose opinions I respect really like it (and prefer it to Python). I hope to interview the Ruby creator someday too, though I haven't approached him because I haven't had time to try out the language yet. One pattern I believe I've noticed is that people who really liked Smalltalk in the old days seem to like Ruby over Python.
|
|
|
But I'm also keen to hear what kind of articles you'd like to read, such as your call for more in-depth, practical tech articles. So feel free to post your article wish lists
I like interview that actually push the interviewee to explain themselves, and not just give them a soap-box.
Bruce said somethings that would be interesting if they were true (e.g. a 10x productivity gain), but he didn't provide anything substantial to justify them, and my experience tells me that he's either referring to very specific situations, or he's well and truly overstating things.
If you (Bill) had pushed Bruce to actually justify his comments then this could have been a really great interview, but as it was there was lots of advocacy and no one forcing him to explain himself.
A lot of the time your inverview style works really well, I think you got a lot of good stuff from James Gosling, and Andy/Dave. But for Bruce (and to a lesser extent Rusty) I think you need to encourage him to back up his claims a bit, or the intverview ends up without much meat to it.
|
|
|
> But I'm also keen to hear what kind of articles you'd > like to read, such as your call for more in-depth, > practical tech articles. So feel free to post your article > wish lists > > I like interview that actually push the interviewee to > explain themselves, and not just give them a soap-box. > > Bruce said somethings that would be interesting if they > were true (e.g. a 10x productivity gain), but he didn't > provide anything substantial to justify them, and my > experience tells me that he's either referring to very > specific situations, or he's well and truly overstating > things. > > If you (Bill) had pushed Bruce to actually justify his > comments then this could have been a really great > interview, but as it was there was lots of advocacy and no > one forcing him to explain himself. > > A lot of the time your inverview style works really well, > I think you got a lot of good stuff from James Gosling, > and Andy/Dave. But for Bruce (and to a lesser extent > Rusty) I think you need to encourage him to back up his > claims a bit, or the intverview ends up without much meat > to it.
That's very good feedback, thanks. I'll keep that in mind in future interviews. For most interviews I've read a book or at least previous interviews of that person, and I usually try to do a combination of:
1. Get them to repeat things I liked that they said or wrote, things I think are useful for programmers to hear, so I can publish it on Artima.com. 2. Challenge them to justify or clarify things they've said or written that I find concerning or just plain dubious.
When I do the second one, I've often found that I misunderstood what they wrote, or that it didn't come across to me at least as they intended. I was concerned, for example, about a lot of the things the Pragmatic Programmers said in their book, but when I challenged them on those things, their answers made sense. And I think that approach has made for good interviews.
In the particular case of Bruce's claim to a 5 to 10 times productivity boost, my take is that he was talking about his own experience, not saying that by simply moving from Java to Python anyone would get that big a boost. In other words, I understood he was giving anecdotal evidence only, not purported scientific evidence that was backed up by research results. Bruce, any chance we could get you to elaborate on where your 5 to 10 times productivity numbers come from in this forum?
What I'm find interesting is that both of the interviews you pointed to, Bruce's and Rusty's, are the first interviews I've done by taking the slides from a talk and using that as the basis for the interview. (I didn't hear the talks in person.) Perhaps because I can't read the actual details of their message, it is harder for me to find things to challenge them on. They were up on their own soap box, in effect, delivering their message, and I kind of wanted to capture the meat of their message in an interview series. In Rusty's case, I wanted a discussion about Java API design. In Bruce's, a discussion about what's important in programming languages. I did not want them to come across simply as promoting XOM over JDOM or Python or Java and C++, but perhaps they've turned out that way more than I wanted.
Anyway, thanks again for this feedback. This kind of constructive criticism helps.
|
|
|
> I'd have to agree with the previous posters. When I read a > comment like > > > With Python and some sort of build system, such as ant or > make > files, I can automate everything. And I've found that to > be incredibly > powerful. I often use make with a lot of Python programs. > For example, > the CD-ROMs I sell are all generated with a single make > command. > > > I think to myself > > > With these tools we can more or less do what people have > done > with unix for the past 25 years (see footnote 1). > > > > In other words, Python allows me to learn an entirely new > way of doing > something we already know how to do. > > I think I would be a bit happier if the article actually > explained > how and why the author's solution is superior to, say, an > older > solution which did not employ python for this task. > In this case, I believe Bruce was trying to say that the productivity gain he gets with Python is what makes it worthwhile for him to do more automation. You can automate everything with assembly, but if you had to use assembly, you wouldn't automate as much. That's what Bruce meant by the "tipping point." If at some point you get so much more productive, you'll suddenly do a lot more things (for example, a lot more automation), than you did before. So Bruce wasn't saying a Python-based automation solution is better than some other solution to the same problem, just that ever since he started using Python he creates a lot more automation solutions.
|
|
|
I am a C++ programmer, but I have found the python language "soothing". It's syntax is clean, there are many builtins that help write code, the inbuilt data structures are great, and the standard library is pretty decent (though it has lot of room for improvement).
I write hobby apps in Python, not too serious, but not toys also. I whipped up an imageviewer in python & wxPython just 3 months after learning python and 2 weeks after learning wxPython! The language by its nature allows a proficient programmer to be productive much faster than C or C++ does.
Another aspect of python is the ability to "project" code from mind.You can write a few lines of code for your project by just having a vague design in mind, not even needing to write it down or develop elaborate design documents. Once the basic prototype is working you can get into the nitty-gritty by following the process of "refactoring", which is essentially iterative in nature.
Of course this is what they mean by saying "Python is an agile programming language", "Python allows fast prototyping" etc.
The opensource model supports this by its inherent nature. In my view python is ideally suited for the opensource way of programming, probably better than Perl with its arcane syntax.
I have tried my hand at Ruby also, but to me it is python that looks charming!
No comments about java, as I said my evolution has been C->C++->Python.
-Anand Pillai
|
|