Link Details

Typical Java-ist smear of a scripting language.

I'm so amused by the history though. 12 years ago, the C/C++ people made these same types of arguments about Java.

No we didn't; we made fun of Java because it was slow (which it was, then), not because it didn't have rules, structure, and order--it had more than C/C++.

Should have been more clear.

Java was ridiculed for all the things it wasn't or couldn't do as well at the time, with no credit given for what you could do with it, that was easier or possible vs. the equivalent in C/C++.

Same thing here. This is yet another argument that doesn't highlight where python and other scripting languages are better, but just where it is different than Java.

You could almost put the name of any scripting language in place of the word "python" throughout the article. A lot of that is just he nature of dynamic languages. Love them or hate them, but don't compare them to Java (or any other statically typed language).

Stupidiest article ever. The guy has absolutely no idea what Static vs Dynamic typing means. Comparing apples with oranges again. And Gregg is right: Ruby, Erlang, Lisp, Smalltalk, whatever dynamic language you put in fits the description. And the irony is that what he describes as being " good" is exactly the reason for the demise of Java and other static languages for application development.

I don't understand why people will STILL not follow the creed of "right tool for the right job." Java has its place and so does Python -- python isn't a REPLACEMENT.

write an xml-rpc or SOAP client in Python, you will adore it !
a web scraper using urlib , mamamia :)

That's why you don't use Python with a team.

I don't?

I don't really understand the author to be honest. Some of his gripes would appear to simply come down to poor documentation of a library rather than the language, in his case Python. As for his views on exceptions, I won't go into that too much as I'm not really a huge fan of checked exceptions, but some of his concerns may be addressed with a good set of unit test.

Totally undisciplined hacking teams are probably better off with an extremely strongly typed language since it will catch at least some problems.

But if you look at them big projects at github et al, those folks TDD so they can use Python, Ruby, whatever for the job.

Valid point, but most projects go from disciplined creation to hacked maintenance. I guess if the unit tests are maintained this will not be a problem.

I think the article has valid concerns for those looking at Python from a Java perspective. I've been hacking python on google app engine and have enjoyed it, but have noticed the speed of initial development is tempered by interacting with new libraries.

I'd be interested to hear from experienced developers working in teams.

brain : Python is "battery Included" , most of beginners , including me, spend a lot of time with Python discovering the libraries and modules. what i really dislike about Python is the lack of decent IDE, not python's fault anyway.

What a craptastic article. I'm disgusted by the amount of hate rather than discussion this blog posting presents.

The author has two complaints of python compared to java, which as others have pointed out, can apply to most scripting languages instead of just python. The two points are: 1) duck typing requires more contextual knowledge of the developer than static typing where the method signature contains all knowledge needed to properly call the method and 2) checked exceptions communicate better to the developer about exception handling requirements.

It's astounding to me that the response here has been to bash the author. Both points are VALID benefits of static typing (and of Java's exception model). This is not to say that python (or ruby, perl, etc...) don't offer their own offsetting benefits, and then there is a legitimate debate as to which language feature set is best in a particular setting. But to scoff that this is just a java love fest strikes me as defensive beyond what's defensible. Use the best tool for the job and don't be so zealously attached to proving your particular tool is the one true uber tool. The author, in his first sentence acknowledges that python offers time savings. In his view, this savings diminishes as team size increases and he offers two valid technical reasons to support (not prove) his point. If you disagree, offer the offsetting advantages.

Some of the arguments of posters here are bogus: neither issue can mitigated by adding documentation. The creation and maintenance of docs has a cost, and using them also has a cost. The same arguments apply if you say "you can address his issues with unit tests". Yes, but not without adding costs.

Someone referred to the "demise" of java and static typing. There is no such demise. Go look at the Tiobe language index. Java is still #1 and C and C++ are #2 and #3. Python is growing, true, but coincidentally this is by about the same amount that perl is falling. They have a nice graph showing static vs dynamic languages over 7 years. In 2004, there seemed to be a one time shift in favor of dynamic languages, but the ratio has held firm at 60/40 in favor of statics for the last five years. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

So the conventional wisdom would say that 3/5 problems are best solved using static languages and 2/5 problems are best solved by using dynamic languages. So learn and use both if you want to be a good developer.

@bwtaylor,
Your point 1 is usually wrong. A typed signature does not tell you how a function works. The function body could just be a place-holder, or a botched copy of another similar function. In Python we are used to assuming something isn't right unless it has been tested. We cannot rest on type safety and so are less prone to making that error.

On Java's checked exceptions, I guess you haven't been bitten yet ;-)

I do agree that it is good to learn a wide variety of languages and language types.

The original authors argument I see as:
* Java (and its IDE's) produce a lot of code.
* A lot of code needs more programmers
* Java has constructs for handling large teams of programmers.

Alternatively, If you have a language and development style that doesn't produce copious amounts of code for particular problems then you don't require as many programmers; and just because a language may not seem to have the standard crutches for dealing with a large codebase, does NOT mean that it cannot tackle the problem.
As an example their are the newer web frameworks written in Python and Ruby that are carving into, and stealing developer mindshare from entrenched Java solutions.

Mind-you, its hard being number one, as you quote in TIOBE, as you can climb no higher and everyone is snapping at your heels.

- Paddy.