Bruce Eckel says: When you have the experience of really being able to be as productive as possible, then you start to get pissed off at other languages. You think, "Gee, I've been wasting my time with these other languages."

Read this Artima.com interview with Bruce Eckel:

http://www.artima.com/intv/aboutme.html

What do you think of Bruce's comments?

This looks like shaping up to be a great interview. As a fan of Python it's great to see so many "big names" getting on board.

Just a quick query for any Python experts reading this:

for line in open('filename').readlines():

Does the above line close the file automatically or does it leave it hanging open? Since the result of the open() call isn't assigned to a variable I imagine it gets garbage collected and when it does the file gets closed, but is this instant or does the file stay open for a while? If the latter is true, it's probably best to replace the one liner with this:

f = open('filename')
lines = f.readlines()
f.close()
for line in lines:
...

This is what I normally use, but if the one liner does work without leaving open file handles hanging around I'll start using that instead.

Yes, Python has automatic destructor calls (it uses reference-counted garbage collection, and yes, they've solved the self-reference cycle problem) so when the (unnamed) file object goes out of scope it is automatically closed.

Interesting article!
A lot of hard-core Java folks are trying Ruby and Python
lately with various level of excitement.

My view is somewhat conservative, though. I think a great "development platform" is made of 4 equally important ingredients:

1. Language (keywords, types, static<->dynamic checks, OOP features, etc. )

2. Powerful and rich API (sockets, IO, regex, RPC, XML, Graphics, Transactions, HTTP, RDBMS interface, etc ...)

3. IDE (Refactoring, Search, Debugging) support

4. Performance and built-in security

That is why I am always amazed when someone is only focused on Item 1. Sure, Scheme is great, but how many enterprise projects it delivered? I wish reading lines from files serves as a benchmark for language merits, but things are a lot more complicated in the real software projects...


I would like to take defense on the Java side now:

1. The language itself is getting more and more pleasant to work with, especially with assertions, all of the JSR014 and JSR201 features. It really does lead to more compact code! I already prototype some stuff with generics and I am very happy with the code-reduction/expressiveness of the design!

2. I disagree with the idea of relieving the compiler from doing pedantic static check of the code and putting the burden on the developer to write (let's say) unit tests.
I love unit tests/XP, but I will sleep better when I know that javac has caugth all other things I did not envision in the unit tests;-)

3. An enormous advance was made by some Java IDE tools (such as Eclipse, CodeGuide and IDEA). This really changes the economics and relative price of Java code. The idea that writing Java code is expensive and should only be reserved for serious stuff, while configurations and test should be written in toy languages/XML, IMHO, is not valid any longer. It is all due to the advance of the Java IDEs!
Instead, I just "tag" some piece of Java code as "cheap-to-refactor" and some other as "core-and-well-thought-of".



4. On the issue of checked exceptions. I will only present a couple of two real examples, you judge:
a/ A friend of mine works in a ISP company (San Diego, A+net). Some while ago (around 2001-2), they upgraded to the latest MSSQL server. To their surprise, the new server was incompatible with their server side COM objects. After enormous debugging effort, it turned out to be an uncaught C++ exceptions, killing the whole db server! Sure, they filed bug report with Microsoft, prayed 2-3 weeks for the patch, LOST THOUSANDS OF DOLLARS ... plus all the frustration.
b/ Look at the web page of James Gosling (java.sun.com/people/jag/). There, he points to a investigation report for the reason behind the Ariana 5 crash. Guess what - uncaught exception!
You calculate the money involved.

5. Performance is an issue for way to many real applications! Please hear me! If a language makes Floats first class object sacrificing performace, then no, I won't implement my 3D rendering toolkit in it! Sorry!

Hristo

> Interesting article!
> A lot of hard-core Java folks are trying Ruby and Python
> lately with various level of excitement.
>
> My view is somewhat conservative, though. I think a great
> "development platform" is made of 4 equally important
> ingredients:
>
> 1. Language (keywords, types, static<->dynamic checks, OOP
> features, etc. )
>
> 2. Powerful and rich API (sockets, IO, regex, RPC, XML,
> Graphics, Transactions, HTTP, RDBMS interface, etc ...)
>
> 3. IDE (Refactoring, Search, Debugging) support
>
> 4. Performance and built-in security
>
> That is why I am always amazed when someone is only
> focused on Item 1. Sure, Scheme is great, but how many
> enterprise projects it delivered? I wish reading lines
> from files serves as a benchmark for language merits, but
> things are a lot more complicated in the real software
> projects...
>
>
> I would like to take defense on the Java side now:
>
> 1. The language itself is getting more and more pleasant
> to work with, especially with assertions, all of the
> JSR014 and JSR201 features. It really does lead to more
> compact code! I already prototype some stuff with generics
> and I am very happy with the code-reduction/expressiveness
> of the design!
>
> 2. I disagree with the idea of relieving the compiler from
> doing pedantic static check of the code and putting the
> burden on the developer to write (let's say) unit tests.
> I love unit tests/XP, but I will sleep better when I know
> that javac has caugth all other things I did not envision
> in the unit tests;-)
>
> 3. An enormous advance was made by some Java IDE tools
> (such as Eclipse, CodeGuide and IDEA). This really changes
> the economics and relative price of Java code. The idea
> that writing Java code is expensive and should only be
> reserved for serious stuff, while configurations and test
> should be written in toy languages/XML, IMHO, is not valid
> any longer. It is all due to the advance of the Java
> IDEs!
> Instead, I just "tag" some piece of Java code as
> "cheap-to-refactor" and some other as
> "core-and-well-thought-of".
>
>
>
> 4. On the issue of checked exceptions. I will only present
> a couple of two real examples, you judge:
> a/ A friend of mine works in a ISP company (San Diego,
> A+net). Some while ago (around 2001-2), they upgraded to
> the latest MSSQL server. To their surprise, the new
> server was incompatible with their server side COM
> objects. After enormous debugging effort, it turned out
> to be an uncaught C++ exceptions, killing the whole db
> server! Sure, they filed bug report with Microsoft,
> prayed 2-3 weeks for the patch, LOST THOUSANDS OF DOLLARS
> ... plus all the frustration.
> b/ Look at the web page of James Gosling
> (java.sun.com/people/jag/). There, he points to a
> investigation report for the reason behind the Ariana 5
> crash. Guess what - uncaught exception!
> You calculate the money involved.
>
> 5. Performance is an issue for way to many real
> applications! Please hear me! If a language makes Floats
> first class object sacrificing performace, then no, I
> won't implement my 3D rendering toolkit in it! Sorry!
>
> Hristo


All very valid points. To play Devil's advocate here, when I was first introduced to Java, it was mostly though of (at least by most of the people I worked with) as something only a little better than a toy language for doing some really cool dynamic stuff in web pages. I'll bet 10 years ago you could substitute Java for Python and C++ for Java in the above observation and it would mostly hold. In Java, when we first looked at it, performance was terrible (still is on some apps like the Oracle management suite), database access wasn't very good, RMI was, well, quirky and there were a whole host of other issues that made us abandon it for the projects we were evaluating it for at the time. Not to mention there wasn't an IDE worth a damn.

Now most, if not all, of that has changed. I submit that one of the reasons, if not the only one, Java has improved dramatically on all the points mentioned is that it had a whole lot of #1 going for it. It took a lot of the things that were good in C++, dumped most of the bad, and wrapped it up in a nice little package that in theory let you write once and run anywhere.

For what it's worth, I don't think anybody I know would write a 3D rendering toolkit in Java, either. All the people I know that work on that kind of stuff still use a mix of C, C++ and <gasp> assembler.

I can't wait for the rest of the interview, or for more discussion on this thread. I've got some experience in a pretty wide variety of languages and like to tinker in what passes for my free time. I haven't done too much with Python yet, but what I have done looks very promising to me. I haven't touched Java in years (unless you want to count our company's jump onto the .NET bandwagon and all the C# I've been writing...), so I might be missing some things in my little critique, but at the time we were evaluating it for some large projects after I had done some work in the language, we ended up using a combination of C++ and VB because Java didn't satisfy points 2, 3 and 4 of the equally important ingredients.

> for line in open('filename').readlines():
>
> Does the above line close the file automatically or does
> it leave it hanging open? Since the result of the open()
> call isn't assigned to a variable I imagine it gets
> garbage collected and when it does the file gets closed,
> but is this instant or does the file stay open for a
> while? If the latter is true, it's probably best to
> replace the one liner with this:

I think it is okay, since the file was only opened for read access and it will be closed automatically (just not necessarily deterministically).

This is probably an even better and a little more modernized version of the above:

    for line in file( filename ):
        ProcessTheLine( line )

> This is probably an even better and a little more
> modernized version of the above:
>
> for line in file( filename ):
> ProcessTheLine( line )

Actually, Bruce suggested I change it to the more modern idiom, and I did. So now the article uses the file() idiom, not the open() one.

> "I can't remember how to open files in Java."
> "Oh, I see. They're putting their curly braces here or there."

Wonderful! I thought these sorts of problems were just me being stupid. I'm glad to see gurus are human, too.

Vince.

> > This is probably an even better and a little more
> > modernized version of the above:
> >
> > for line in file( filename ):
> > ProcessTheLine( line )
>
> Actually, Bruce suggested I change it to the more modern
> idiom, and I did. So now the article uses the file()
> idiom, not the open() one.

It wasn't just replacing open() with file() that I was suggesting, but also the idea of iterating on the file object rather than using readlines(), which loads the whole file into a list in memory.

I strongly agree with the observation about how to open a file as an example of clutter that Python avoids very successfully. I recently ported a Java utility to Python and took 8 classes and a couple of interfaces and boiled it down to less than 100 lines of very readable Python. One feature of the standard Python library that I relied on is the os.path.walk method. Why I ask myself, hasn't such a common routine been made a standard part of the Java API?

Python is amazing in how it helps me to be productive and I am also thrilled to hear well regarded folks like Bill and Bruce agree and are providing the forum for publicizing Python's capabilities.

> > "I can't remember how to open files in Java."
> > "Oh, I see. They're putting their curly braces here or
> there."
>
> Wonderful! I thought these sorts of problems were just me
> being stupid. I'm glad to see gurus are human,
> too.
>
> Vince.

Fact Vince, I feel exactly the same way even with straight forward DB connectivity. I think we tend to forget that we are all just mammals at the end of the day, regardless of status/qualifications etc etc

And if you want to see the original keynote presentation then go to:

http://www.python9.org/p9-keynotes.html

(PS: Can someone add this link to article references too?)

Ah, sorry, that page has only link to Guido's presentation. Bruce's is here:

http://mindview.net/FAQ/FAQ-012

My problem with Python is that I can't remember what the names mean. I see lots of names but I don't see what kind of things they denote.

def sellHouse(buyer, seller, contract):...

Is buyer the id of a person, the name of a person, a person object, which subclass in my person hierarchy? Sure I could encode the types of everything in the names. But what if I change the type? Then I'd have to change all the names.

To find out what all the names mean I have to go read the documentation. I'm just too lazy for that, so I'll stay with Java for the time being.

-Alexander

> My view is somewhat conservative, though. I think a great
> "development platform" is made of 4 equally important
> ingredients:
> ...
> 2. Powerful and rich API (sockets, IO, regex, RPC, XML,
> Graphics, Transactions, HTTP, RDBMS interface, etc ...)

Python also has a rich and powerful set of libraries. The key phrase is "batteries included".

> 3. IDE (Refactoring, Search, Debugging) support

There are some Python IDEs (Idle, PythonWin, Boa onstructor, Bicycle Repair Man, Wing, etc.) but Java currently leads here.

It would certainly be possible to build Eclipse support for Python. I've toyed with the idea for Jython (Python implemented in Java that can smoothly interoperate with Java and compile to Java byte codes).

> 5. Performance is an issue for way to many real
> applications! Please hear me! If a language makes Floats
> first class object sacrificing performace, then no, I
> won't implement my 3D rendering toolkit in it! Sorry!

Yes, but... Performance is important. Python is slower than Java. Global weather simulation research was being done in Python three years ago. How does this match up? The Numeric Python module performs very efficient computations on numeric arrays while the interpreted Python steers the computations.

While there are certainly some tasks for which Python is too slow they are almost never all of an application. The general Python approach to this problem is:

1. Write application.

2. Profile and measure.

3. Adjust algorithms as needed.

4. Profile and measure

5. Rewrite critical parts in C (or Java if you're using Jython). Notice that this is done only after improving the algorithms because the potential gains from algorithmic speedup are much greater than from a low level rewrite. These days this step is frequently replaced by: use common module XXX that already does the rewrite.

Dan Pierson