Re: Python and the Programmer
Posted: Jun 3, 2003 2:04 PM
> 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
> 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
> 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
> Instead, I just "tag" some piece of Java code as
> "cheap-to-refactor" and some other as
> 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!
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.