I like hristo's points.

In particular, IntelliJ's IDEA is as close to the ideal IDE as possible, with advanced search, intellisense editing and extensive refactorings. These make Java a pleasure to program. And IDEA works for VERY large projects (as long as you have decent RAM). It also does remote debugging of J2EE code with finesse.

I will add another: UML tools. Borland's TogetherSoft makes it easy to reverse engineer huge Java projects. See http://opensource.objectsbydesign.com for some examples. UML for Python seriously lags. See http://objectsbydesign.com/projects/python_uml.html for more information.

While there has been progress in Python tools, it has been very slow.

The other point hristo made about having a rich API:
When Java added regex support, this seriously leveled the playing field with perl and python, which are frequently used for this feature.

Is Java really faster than Python? I developed the same application in both Java and Python which consists of a daemon process, a standard windows MDI gui and a full-screen graphical app. I didn't notice a significant speed difference between the two daemons, but it's a fairly small program. But the difference between using Swing and wxPython was tremendous and the MDI gui in Python was much more responsive and quicker. I didn't make it to the full graphical app in Java as I gave up on it, but it's extremely quick using pygame even before I optimized it.

Also, the applications I took less time to write in Python than in Java even though I knew Java fairly well when I started it but had never touched Python before.

As for IDEs, I use the same for all my non-Microshaft coding, Vim.

> As for IDEs, I use the same for all my non-Microshaft
> coding, Vim.

I'm a diehard VIM/Xemacs user as well. In fact, I write almost everything using VIM, and I was using VIM for Java development until I was introduced to IDEA. BTW, I had tried almost every Java IDE before, going back to ca '96 (remember Java Workshop?), but have given up on every one of them, as they all decreased my productivity.

Once I started using IDEA, there's no going back to VIM for my Java coding. When folks make a big deal out of having to type a lot of clutter in Java, that's true. But then tools like IDEA automate clutter management. Also, Java's type system really shines with IDEA (and, in all fairness, many other more recent Java IDEs), as their code editors find appropriate object references in a given context when you specify method params, for instance. I agree with one of the earlier posters - sometimes I also forget what parameter types a method takes, and then IDEA really helps out.

So, with these kinds of tools the finger typing argument in the Java v Python debate just goes away.

But in terms of having to keep a bigger context in mind with Java, I definitely agree with Bruce. However, that's a problem of APIs, not of Java the language, per se. And one can always use APIs other than the ones that come with J2SE/EE. And one can always propose better APIs through the JCP process. I know that Doug Lea, author of Concurrent Java Programming, is proposing a concurrency-related tool and API, and JDOM is now also going through the JCP. So, one could design a file utils API, etc.

An API is always just one way of doing things, and most APIs reflect thinking in progress - i.e., I like to look at APIs as way to explore a design space. When we discover new aspects to that space, we can design better APIs with the wisdom we gained. Just look at the Swing layout managers as an example (i.e., compare GridBagLayout to TableLayout to the JGoodies FormLayout). As that example illustrates, the best APIs for a given task might not initially be found in the J2SE/EE platforms. That's just how things evolve.

So the argument that doing something in Java is tedious or not so tedious, is a confusing statement, because we're then really talking about a specific API, and APIs are really replacable.

Frank -- can you post a URL to Doug Lea's concurrency proposals?

Here are two links to Doug Lea's site. The first has documentation on Doug's existing util.concurrent package. The second has information about JSR-166, which will add similar facilities to the next major J2SE release.

http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

http://gee.cs.oswego.edu/dl/concurrency-interest/index.html

-- Larry

> I'm a diehard VIM/Xemacs user as well. In fact, I write
> almost everything using VIM, and I was using VIM for Java
> development until I was introduced to IDEA.

> So, with these kinds of tools the finger typing argument
> in the Java v Python debate just goes away.

Likewise (although I use eclipse rather than IDEA).
I still use VIM for all my non-java editing, and everytime I use it to edit (for example) a javacc grammar, I miss all the cool features (eg refactoring support).

> But in terms of having to keep a bigger context in mind
> with Java, I definitely agree with Bruce. However, that's
> a problem of APIs, not of Java the language, per se.

Absolutely.
And I have a big problem with the readlines example for that reason.

My equivalent java code is something like

reader = new FileLineReader("filename")
while(reader.hasMoreLines())
{
     doSomething(reader.getNextLine())
}

while this is more verbose that the python equivalent, it is not painfully so.

And yes, I had to write the FileLineReader, but that also meant I can make it behave the way I want it.
e.g. I can easily modify it to support finding the file on the classpath instead.
That is important to the work I do.

Bruce's argument seems to be that Java lead him to write badly factored code, so that he had too much "plumbing" cluttering up his methods.

If that is indeed his argument, then it's partly about personal discipline, and partly about tools.
I happy to wear the argument that java requires more discipline to maintain code quality, but I have no problem with that.
And the current crop of tools make writing the above code easy.

And the "train of thought" argument is similar.
Bruce said:
> And then all of a sudden you run into something like,
> "I have to open a file and read in the lines."
But I don't think that's the best thought process to take.
I think "I need to get the line from this file", and so I write:
List lines = readlines(file);
I don't need to implement readlines() now, the IDE will create the method for me, and add a "@TODO" in it, and I can focus on the main issue for now.
I'll come back and implement readlines() later.

My experience is that a well disciplined development style makes most of Bruce's issues disappear, and at the end of that, Java comes out ahead of python primarily for:
* Tools/Vendor support
* Performance
* "Enterprise" features (JTA etc)
* Static Typing
My experience with Python has been that most of the bugs I wrote were due to its dynamic nature, and I can eliminate 70% of those bugs in Java1.4 and 90% of them in 1.5 (with Generics)

Bruce,

This page provides an overview:

http://www.jcp.org/en/jsr/detail?id=166

I have two concerns about a weakly typed language: IDE and Self-Documenting

1. IDE

Now that I'm hooked on IntelliJ IDEA, I can't go back to a plain text editor. It seems to me that IDE support for a language is affected by two factors:

1.1 How popular is the language (or how much $$ will someone invest to create a world class IDE for the language)

1.2. How IDE'able is the language. I don't know Python, but i've used un-type-checked languages. Can an IDE work it's magic (like code completion) on this type of language?

I wonder if Bruce is a non-IDE guy.

2. Self Documenting

In Java, I prefer an API that is self documenting. For example, I prefer this:

public LineItem[] getItems();

Over this:

public ArrayList getItems();

How self-documenting is Python?

Andrew,

I wrote the following toy Fibonacci function in Python and Java:

def fib(i):
    if i == 0:
        return 0
    if i == 1:
        return 1
    return fib(i-1) + fib(i-2)

x = 0
while True:
    print x, fib(x)
    x += 1

At about 35, it's on the order of minutes to complete the calculation. With Java, it doesn't slow down to that point til about 41 or 42. Since fib(x+1) is more than twice as much work as fib(x), that's a pretty big difference. (Granted, this is not a very fair test for poor Python; it doesn't get to dip into its C libraries, and Java doesn't have to do any garbage collection.)

Back in real life, though, I've had similar experiences to yours... most apps I've ever written have spent 95%+ of the time waiting on the DB or disk/network IO. Also, Python scripts seem to start up almost instantly whereas the JVM takes a few moments to start up; for short-lived applications like command-line utilities that may be a lot more important.

Vim? You couldn't pay me enough to write Java in anything but IntelliJ! ;) (Or at least Eclipse)

Well, let's talk about Python and making life easier for the programming - no bullshit reasons for not accomplishing this objective.

1. How about a switch statement? Why not? It would make many lives easier in comparison to the resort commonly recommended to fix you the programmer here, and not the language - the if/elif garbage. But has this every been done, this one simple thing that for all we've ever been told by the purportedly beatific designers is _only_ a convenience and therefore never going to be a part of the language? Come on!

2. One thing that makes my life as a programmer easier is if I can write a program in a specific language, learn all of its idiosyncrasies and develop applications written in that language. With python I am faced with the questions of:
- do I write this in the version of python that is on most people's machines, is what most of the extant books contain examples for and isn't so slow people will not want to run my program at all (1.5x)
- do I write this in the version of python that adds more obtuseness yet addresses bitrot and adds in some classes that are handy, one I can run Zope on, where Guido works, for example - well this would be 2.1.this, or is it 2.1.that? And what is the difference in the versions again? Tell me this was for my convenience as a programmer - bullshit alarm going off with klaxon tone.
- how about I write my code on the recommended, modern, version of python. Still has no case construct, even though for all the OO hoity toity poobah about python 90% (oh yeah, take a look!) of every python program I've ever seen are "procedures", but we do manage to make it yet slower than ever. And Zope won't run right with it. And besides Zope, for all of Bruce Eckel's praise and vaporous talent, along with the python luminaries (you-know-who-you-are-ly-yours) so holy that they can't be bothered to take a break from this nonsense for the mere sake of programmer satisfaction with the language when they ask for some simple constructs, a real Internet class library (hey, if were gonna bash PHP let's back it up), and SPEED GODDAMIT. This would be versoin 2.2.. no wait: 2.2.3 Final (released May 30), or wait: 2.3b1 (release April 25th!) - you know it and I know it the only people who are going to write books^H^H^H^H^H programs in this because it's easier is Guid, I mean Tim, ... wait, no one.

--

I want to love python. I really do, but python has a huge glaring faint-hued elephant-sized problem - it doesn't know what it is anymore. If it was convenience for the programmer it isn't anymore, but does Bruce criticize this - no, only praise. Reality check o important ones - this is the disease in action, you just heard the warts being removed because someone with a big mouth but no working neato product said they were removed.

Say it's quick to write programs in? Sure, if you don't bother to read all of the pendantic PEPs, don't care if it will run on any machine that has python installed (they better have 3 versions and we all know it), and you aren't going to write anything big. Many people say that perl isn't good for big projects, Java or maybe python is much better - if that were true I think we'd see alot more big projects written in python than there are in perl, or PHP, or Tcl.. but for all of the inbread blind hype o c.l.py we don't really see any code out there. Show me one single good python based webmail system... or even a decent modern shopping cart, please!

What we have: Lots of basic editors posing as IDE's behind a mask of bloat; only one decent application server that has recently been infected by the "let's change stuff for our own reasons, make things harder (page templates are hard folks, dtml was easier... wasn't that what you were supposed to... oh yeah), and go in 3 or more directions at once behind closed doors and not really produce anything" disease. Maybe it's the new old blood. The few products that do exist that are even half way decent are bound by the most personal and disengenuous licenses any "free software" afficianado has ever seen - and there are a ton of them - these things are _only_ free as in beer. Unless you want the pro version... otherwise you fellas stick to your free classes you get with the language and that big ass application server that breaks down with 5 concurrent requests per second.

Look at Zope and python a few years ago - ahead of its time, small, a toolbox you could work with. You could make the case then that there were features about that language that made it great, one of them being that it was easy (a joy even) to write programs in. Now they are both giant frameworks that the programmer has to bow down to and form themselves to their lofty limits and their narrow exclusions. Tell yourself that it's for your own OO goodness, tell yourself that speed doesn't matter, or backwards compatibility, persisting in a single direction at a time, or that maybe people really believe and respect you when you (at your job that uses some other language) boast casually about the "cleanliness" of python... but that isn't actually make it be any of the good things you say.

Please, DO NOT write an article telling us that what python is right now is a language developed with an eye towards you, the programmer at large and your convenience. Bullshit. And if you do believe that I have some evidence of WMD in Iraq that would justify a war there on its own merit.

puhleeeze... windbags, it's time you stopped with the snippets unless you are talking about putting the language on a diet and speak your proof of authority on this subject with code. And I mean a whole working program... let's see python use patterns and easily generate that large-scale program other languages aren't suited for; do it quickly because you can right? And make it an application like PHPNuke, Scoop or any of the many other very popular and _easy_ to write Internet programs not written in python.

Thanks, we'd all appreciate that and then we promise to take you seriously again and write lots more litle and big programs compared to PHP or perl. Otherwise stop leading around the noobs so that you can pander your product to the paying customers while leaving the others to wonder just how your product works for themselves.

I plead with you influential people that promote python on the basis of programing skill, "craft", that if you can you should salvage this language and give it back the virtues you sing about. Take of the pointy hat and the mantle of "I'll tell you whats good for you" or yet more people like myself will jump ship (to what? alas... we need a new language) and acknowledge the fact that the last thing that python is today is a language focused on You, the ordinary programmer.

It is focused on its luminaries, the light is so bright they won't see the end of their language until the one day it becomes so slow that it actually stops. Of course the academic will have no reason not to continue at that point... remember your roots, and the People's Front of Judea debating on how to save the life of Brian, or leave the rest of us out of our plans altogether.

def quickfib(x, dict={}):
    if x == 0:
        return 0
    if x == 1:
        return 1
    try:
        fib_1 = dict[x-1]
    except:
        fib_1 = quickfib(x-1, dict)
        dict[x-1] = fib_1
    try:
        fib_2 = dict[x-2]
    except:
        fib_2 = quickfib(x-2, dict)
        dict[x-2] = fib_2
    return fib_1+fib_2

x = 0

while 1:
    print x, quickfib(x)
    x += 1

Use python like python, not like java and you've got speed and satisfaction!

> I wrote the following toy Fibonacci function in Python and
> Java:
> 
> [pre]def fib(i):
> if i == 0:
> return 0
> if i == 1:
> return 1
> return fib(i-1) + fib(i-2)
> 
> x = 0
> while True:
> print x, fib(x)
> x += 1
> 
> At about 35, it's on the order of minutes to complete the
> calculation.  With Java, it doesn't slow down to that
> point til about 41 or 42.  Since fib(x+1) is more than
> twice as much work as fib(x), that's a pretty big
> difference.  (Granted, this is not a very fair test for
> poor Python; it doesn't get to dip into its C libraries,
> and Java doesn't have to do any garbage collection.)

Well, Vladimir already showed a superior solution (more on that, later), but I believe a more throrough excoriation is in order for this flimsy "analysis."

This logic is flawed on so many different levels, that it is difficult to decide where to begin.

First of all, you have fallen into the trap of premature optimization in the extreme. If you are choosing your language/platform based on how well it performs on a single algorithm, that is just utterly ridiculous. Heck, why use anything but assembly?

And again, we are back to the old silly, "Java or Python" instead of the more rational "Java and Python and..." For the past few months I've been working on a C# project, but at the same time, I use Python for many code-generating and project maintenence and other tasks. Despite its terrible performance on badly written Fibonacci algorithms, it is a great tool that saves me tons of time and makes me much more productive (that it is also fun is just a bonus).

Secondly, if you use just a little common sense on your algorithm and write something like this:

fibs = [0,1,1]
def smartFib(n):
   for i in range(len(fibs),n+1):
      fibs.append( fibs[-1] + fibs[-2] )
   return fibs[n]

You will see that for this particular case, Python is actually quite superior to Java. Because this implementation will quickly take you to Fibonacci numbers that have thousands of digits, you'll have to rewrite your Java solution to use BigInteger (Python will automatically be using longs which are arbitrary-length integers). Even after making these adjustments, you'll find that Java craps out because of memory problems long before Python does; I don't know the exact cause, but either the ArrayList or the BigIntegers are gobbling too much, or the garbage collector is not giving it back well. The simplicity of the code in this case is particularly dramatic when compared to the (revised) Java code, as well.

In other words, you picked an example which illustrates the opposite of your conclusion.

If your point was to intentionally compare a bad algorithm in the two languages to see which responded better to poorly written code, then that's another thing. I guess the conclusion could be that Java is better at dealing with bad code (maybe that was one of its design criteria; after all, it was heavily marketed and there are likely many more bad Java programmers than bad Python programmers). Anyway, knowing a bit about Python, you wouldn't expect it to excel at recursion, since it is designed to be very flexible and dynamic. If you want some particular algorithm to be highly optimized for performance, then write a C extension, just as you would use JNI to do the same in Java.

On a more realistic note, I have a library of utility functions that I've built up over the years, which includes a GetFileCrc() function. I turned this library into a COM automation server, so that I could use it from JavaScript and subsequently Python (I started the thing before I learned Python and was pleased to learn that Python has very simple access to COM Automation via the Win32 extensions). I was merrily using my COM library to get file CRCs in Python, when I learned that Python's zlib library also had a crc32() function. So, I thought I'd give that a whirl, figuring mine would be much faster, since it does all its work in C. It turns out they are pretty close to equal in performance, even though the data in the zlib case was being read by Python code into manageble chunks (I didn't want read the whole file, because I was working with some that could be several hundred megabytes or more) and sent to the zlib function. The point of this is that you can probably find implementations of common algorithms (CRCs, message digests, encryption, compression, etc.) in Python that have excellent performance (often implemented in C as extensions), so this argument that Python needs to be fast at low-level algorithms (well-written or otherwise) is completely specious.

By the way, as a rule of thumb, if you can write out the results of a calculation faster with a pencil and paper than your algorithm can do on a modern CPU in any programming language, something is wrong. I'm not kidding: try doing the first 50 Fibonacci numbers by hand -- it should take less than 5 minutes, even if you check your numbers.

I've got to agree with Bruce about the usefulness of enforced indentation rules. The indentation is required by Python, so everyone follows the same rule.

The Java/C++/C alternatives means that there are at least 4 ways to indent code(one of them being don't follow any stinkin' rule).

So if I'm working in a team and there are no standards for indentation everytime I look at someone's code where they follow a different standard I waste time thinking about the structure of what I'm trying to read.

Sometimes I (and my colleagues) waste a lot of time. So why not require certain indentation rules for Java/C++/C, etc. [I can hear the howling in the distance].

For a much longer discussion on time wasting while thinking see the book Don't Make Me Think by Steve Krug who runs a site at http://www.sensible.com/.

> I think we'd see alot more big projects written in python than there are in perl, or PHP, or Tcl..

Boa Constructor
http://boa-constructor.sourceforge.net
"Boa Constructor is a cross platform Python IDE and wxPython GUI Builder."

Chandler
http://www.osafoundation.org/
"Personal Information Manager (PIM) intended for use in everyday information and communication tasks, such as composing and reading email, managing an appointment calendar and keeping a contact list"

> Show me one single good python based webmail system

Mailman
http://sourceforge.net/projects/mailman
http://www.gnu.org/software/mailman/mailman.html

also,

spambayes (spam filer)
http://spambayes.sourceforge.net

> 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?


I laughed out loud at this particular quote in the article. I use Perl at work (they won't install Python for us) and I am constantly frustrated by it. Even C++ is a whip after working in Python. Using Python is like a breath of fresh air.