Adventures across space and time with the Python programming language

Main menu

Post navigation

Python & Java: A Side-by-Side Comparison

I wrote this little piece a long time ago — it was last updated in May 2007. In 2009 I moved it from my website to this blog. At this point I consider it an historical artifact, in the sense that I consider it frozen; I’m no longer going to update it when, for example, Java acquires a new programmer-friendly feature.

During the years when it was on my web site, I received a number of email comments. I responded to them all, but no one — other than their authors and me — ever saw the comments and my responses. By moving this piece onto a blog, I hope that folks who feel like commenting can do so more easily, and can share their comments with a wider audience.

During the years when it was on my web site, virtually all of the comments that I received were from Java programmers. Some were calm and helpful, pointing out (for example) new programmer-friendly features of Java. Many were hot and angry and accused me of writing the piece for the sole purpose of bad-mouthing Java. If this describes you, please don’t fire off your angry counter-blast immediately. Go away, calm down, come back and read it again carefully.

I was recently asked if I still hold the opinions that I expressed in this article. I think that’s worth talking about… but in another post.

— Steve Ferg

Updated October 14, 2011 to fix a few minor typos

Note that this post has a companion post on the concepts of weak vs. strong, and static vs. dynamic, typing in programming languages.

Comparing Python and Java

A programmer can be significantly more productive in Python than in Java.

How much more productive? The most widely accepted estimate is 5-10 times. On the basis of my own personal experience with the two languages, I agree with this estimate.

Managers who are considering adding Python to their organization’s list of approved development tools, however, cannot afford to accept such reports uncritically. They need evidence, and some understanding of why programmers are making such claims. This page is for those managers.

On this page, I present a list of side-by-side comparisons of features of Java and Python. If you look at these comparisons, you can see why Python can be written much more quickly, and maintained much more easily, than Java. The list is not long — it is meant to be representative, not exhaustive.

This page looks only at programmer productivity, and does not attempt to compare Java and Python on any other basis. There is, however, one related topic that is virtually impossible to avoid. Python is a dynamically-typed language, and this feature is an important reason why programmers can be more productive with Python; they don’t have to deal with the overhead of Java’s static typing. So the debates about Java/Python productivity inevitably turn into debates about the comparative advantages and drawbacks of static typing versus dynamic typing — or strong typing versus weak typing — in programming languages. I will not discuss that issue here, other than to note that in the last five years a number of influential voices in the programming community have been expressing serious doubts about the supposed advantages of static typing.

Finally, it is important to note that asserting that a programmer can be more productive in Python than in Java, is not the same as asserting that one ought always to use Python and never to use Java. Programming languages are tools, and different tools are appropriate for different jobs. It is a poor workman whose toolbox contains only a hammer (no matter how big it is!), and it is a poor programmer (or software development organization) whose development toolkit contains only one programming language. Our toolboxes should contain both Python and Java, so that in any given situation we have the option of choosing the best tool for the job. So our claim is not that Python is the only programming language that you’ll ever need — only that the number of jobs for which Python is the best tool is much larger than is generally recognized.

Java vs. Python Productivity – an Overview

There are three main language characteristics that make programmers more productive with Python than with Java.

Java

Python

statically typed

In Java, all variable names (along with their types) must be explicitly declared. Attempting to assign an object of the wrong type to a variable name triggers a type exception.That’s what it means to say that Java is a statically typed language.

Java container objects (e.g. Vector and ArrayList) hold objects of the generic type Object, but cannot hold primitives such as int. To store an int in a Vector, you must first convert the int to an Integer. When you retrieve an object from a container, it doesn’t remember its type, and must be explicitly cast to the desired type.

dynamically typed

In Python, you never declare anything. An assignment statement binds a name to an object, and the object can be of any type. If a name is assigned to an object of one type, it may later be assigned to an object of a different type. That’s what it means to say that Python is a dynamically typed language.

Python container objects (e.g. lists and dictionaries) can hold objects of any type, including numbers and lists. When you retrieve an object from a container, it remembers its type, so no casting is required.

“abounding in words; using or containing more words than are necessary”

concise (akaterse)

“expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous”

not compact

compact

In The New Hacker’s Dictionary, Eric S. Raymond gives the following definition for “compact”:

Compact adj. Of a design, describes the valuable property that it can all be apprehended at once in one’s head. This generally means the thing created from the design can be used with greater facility and fewer errors than an equivalent tool that is not compact.

Example

The classic “Hello, world!” program illustrates the relative verbosity of Java.

Example

In the following example, we initialize an integer to zero, then convert it to a string, then check to see if it is empty. Note the data declaration (highlighted), which is necessary in Java but not in Python. Notice also how verbose Java is, even in an operation as basic as comparing two strings for equality.

// print the integers from 1 to 9
for (int i = 1; i < 10; i++)
{
System.out.println(i);
}

print the integers from 1 to 9
for i in range(1,10):
print i

Example

Your application has 15 classes. (More precisely, it has 15 top-level public classes.)

Java

Python

Each top-level public class must be defined in its own file. If your application has 15 such classes, it has 15 files.

Multiple classes can be defined in a single file. If your application has 15 classes, the entire application could be stored in a single file, although you would probably want to partition it sensibly into perhaps 4, 5, or 6 files.

Example

In your application, method A calls B calls C calls D calls E calls F. You discover that F must throw exception SpecialException, and it must be caught by A.

Java

Python

You must throw SpecialException in F, and catch it in A.and
You must add “throws SpecialException” to the signatures of methods B, C, D, E, and F.

You must raise SpecialException in F, and catch it in A.Exceptions will propagate upward automatically; there is nothing more that you must do.

The reason for this is that Java, virtually alone among object-oriented programming languages, uses checked exceptions — exceptions that must be caught or thrown by every method in which they might appear, or the code will fail to compile. Recently (as of June 2003) there seems to be an increasing amount of unhappiness with Java’s use of checked exceptions. See Bruce Eckel’s “Does Java need Checked Exceptions?” and Ron Waldhoff’s “Java’s checked exceptions were a mistake”.

I like the idea of checked exceptions in some situations, but forcing every method to deal with (catching or throwing) all exceptions that its child calls or may call can be tedious. I’d rather be able to ignore an exception and let it propagate upwards. Sometimes, I’d rather not worry about exceptions at all.

Example

Your application has an Employee class. When an instance of Employee is created, the constructor may be passed one, two, or three arguments.

If you are programming in Java, this means that you write three constructors, with three different signatures. If you are programming in Python, you write only a single constructor, with default values for the optional arguments.

I can remember many Python idioms because they’re simpler. That’s one more reason I program faster [in Python]. I still have to look up how to open a file every time I do it in Java. In fact, most things in Java require me to look something up.

Example

Java’s string-handling capabilities are surprisingly weak. (But they have improved considerably with the addition of the split method to the String class in Java 1.4.)

Function or Method

Java

Python

Remove leading and trailing whitespace from string s

s.trim()

s.strip()

Remove leading whitespace from string s

(not available)

s.lstrip()

Remove trailing whitespace from string s

(not available)

s.rstrip()

Example

Code to add an int to a Vector, and then retrieve it.

Prior to Java 1.5, a new Integer object had to be created and initialized from the int before it could be added to a Vector. In order to retrieve the value, the member of the Vector had to be cast back to an Integer, and then converted back to an int.

This clumsiness was eliminated in Java 1.5 with the introduction of generics (which allows you to “type” a container object) and autoboxing (which automates conversion between primitive types and their corresponding wrapper classes). With generics, it is possible to code:

Example

Verbosity is not just a matter of increasing the number of characters that must be typed — it is also a matter of increasing the number of places where mistakes can be made. The Java code on the left has 5 control characters: ( ) { } ; where the corresponding Python code has only one control character, the colon. (Or two, if you count indentation. See below.)

Omitting or duplicating such characters is easy to do accidentally, and constitutes a severe error in the code. In my personal estimate, I spend 5 times as much time fixing such errors in Java as I do in Python. It really cuts into your productivity — and your creative energy — when you spend that much of your time just trying to satisfy the compiler.

Technically, Python has another control character that Java does not — indentation. But the requirement for correct indentation is the same in Java as it is in Python, because in both languages correct indentation is a practical requirement for human-readable code. The Python interpreter automatically enforces correct indentation, whereas the Java compiler does not. With Java, you need an add-on product such as the Jalopy code formatter to provide automated
enforcement of indentation standards.

there are many outofthebox implementation, sorted, unorderd, from synchronized list (vector) to Stack
but there are many other in libraries es Bags (special kind of set) as FastArrayList, look in org.apache.commons.collections

-Example formatter

Come on guy, there are so many IDE, command line tool, addon to versioning system that format code,
for every language.

You are simply proving that less verbose in java is really really bad and complicated !!!
Your points have nothing to do with python.

About IO differences in python, you’re describing it as if every day, the behaviour of the funcitions is defined by some arbitrary evil function. Like one day it will add newline, and the day after it won’t -_-

Impressive! Never thought one has to type so much boilerplate in Java. IMO, all those IDEs are the cure of this very issue which is artificial.

I’ve been writing a lot of Python code recently, getting away with gedit only. I can sketch a piece of code on a piece of paper at lunch (I don’t like smartphones). Would that be possible in Java?

Seems like using IDEs with auto-completion, utility libraries, and other stuff in Java cures the issues that could have been avoided. It’s like buying a Porsche Cayen in a city like Buenos Aires, San Paulo or Moscow: most your driving time you’ll be in traffic jams, but there are things to make sitting in the car comfortable (TV, audio, maybe bar, maybe even a toilet xD).

If you actullay knew Java then this article actually would make sense. Now it’s more fooling rookies.

Experienced programmers would never fall for these bad examples… Comaring python to Java is like comparing a bicyle to a car. Sure, it’s easier to learn to ride and you don’t need to struggle with the licencse, but as soon as you want to go more than 10 miles (“write an enterprise application”), the only choice of the two is the car.

You clearly have not counted in bicycle addicted like me… With which I do not want to state that I would not consider to stretch the application of Phyton a bit to see how far it will go. Or are you suggesting the car being the metaphor for Phyton? ;-) Of course in this case the metaphor is a bit off too as we are using Phyton (Django front end) and Java (with rest interfaces) in the same project. ;-)

Your argument about compact / not compact is not really valid. Note that your quote from Eric S. Raymond talks about *design*, and not about any specific programming language. How you design the structure of an application is largely independent of the programming language you use. And the box “not compact” in the Java column is empty, you’re not even presenting an argument why “Java is not compact”.

I do agree that Java is more verbose than other languages such as Python, but a Hello World program is not a realistic example to demonstrate this.

Your second example, converting an int to a string and looking if the string contains “0”, is strange and is not the way you should normally write programs. And note that in Java you can leave off the braces, so the example with the for-loop in Java can be written in two lines (or even one line), just like the Python version.

There’s a good reason why in Java you would want to save each public top-level class in its own file. This makes it easy to find the file in which a class is defined.

The example about the exceptions is only true if SpecialException is a checked exception. If you make SpecialException an unchecked exception, you do not need to change the method signatures of B, C, D, E and F. Your example makes it seem as if there are only checked exceptions in Java, which is not true.

Some notes:
Static vs dynamic typing:
static type checking may not help much with getting less errors but it helps immensely to get better tools. Show me an IDE that can do the same Eclipse can do for Java like
– show all callers of a method / uses of a variable/field project-wide
– change a class/method signature including all callers in a few clicks
– context assists and hyperlinks everywhere
I find bigger refactorings in dynamically typed language much harder because you often have to resort to simple text search/replace.

Multiple classes in one file:
This is nice for small scripts but bad for bigger projects… for best readability you want all your units (metohds, classes, files) to be as short as possible.

Java is verbose / parantheses, etc:
yeah, they are often superflouos. But modern IDEs mostly solve this problem with their content-assist and templates.

the rest:
For nearly everything that is complicated in Java (and all other things, too) there are good (as in enterprise-ready, properly documented (thanks@Sun for Javadoc), free) libraries. And you can assume that a JRE is already present on most PCs and smartphones and that, as long as you don’t attempt any low level things, your code will run 100%. For python, you have it on most unixes by default… that’s it.
Jython helps a bit, but its incomplete and far behind C-Python.

I don’t say that Java is flawless, but I think that it currently is the best cross-OS development platform for big projects.

1- Java is pure Object Oriented and you MUST declare all objects, Python supports other programming paradigms so you don’t need to declare all variables…that’s also a Fortran problem and turn codes into “black boxes”. For your example is ok….but if you have thousands of variables you have to guess each???

2- PythonDoc is an implementation of JavaDoc for Python…(yes, verbose helps a lot and Python copied that from Java!!!!) see how many men-hour can be saved if a good documentation is generated and attached.

3- Try to run programs that require tons of memory with undeclared variables. The reason Java declares all of them is ’cause it does allow memory allocation (virtual machine) and the Garbage Collector (never mentioned) can run efficiently.

4- Messiness is mostly due to the programmer not the language. Besides IDEs (Eclipse) already fix that problem.

there is a good reason for declaring variables. suppose that you have been working with the variable “foo” for a while. Later, you want to reassign it, but you make a typo, instead of:
foo=7
you type:
fooo=7

in a language that requires variables to be declared, this would generate a compile-time error. in a language that doesn’t, the program would generate a new variable “fooo” and carry right along.

Since everyone above is saying that Eclipse saves Java programmers from a lot of these problems, I’ll use the same defense for python. Python has libraries like pyLint and pyChecker that IDEs can use. For instance, in the example above, if you typed fooo=7 the IDE (such as Eric5) would periodically check the code in real time and then flag that line with a warning like “Variable initialized but never used”. Do something like “x = fooo + 3″ and it’ll warn you with “Variable used but never initialized”, etc.

The author claims that the increased productivity of python is due to its dynamic typing, but it seems to me that the overhead of having to declare the type of a variable is actually pretty small. And that small overhead brings many advantages, e.g. the ability of IDEs to autocomplete function names, show helpful tooltips, etc.

Java is verbose, yes, but most of that is not related to static typing. It’s more for other reasons, e.g the unwillingness of the language designers to allow operator overloading; the horrible decision to use checked exceptions; no delegates; no multiple class definitions in a file; the unwillingless to “clutter” up the standard library with useful functionality that can be achieved in other, albeit more verbose, ways; the legacy from C syntax. And so on.

If you want to see a statically typed modern language done (mostly) right, check out C#. Sure it’s a product of Microsoft, but it’s one of the most nicely designed languages out there. Where Java prefers “elegance” and verbosity, C# is designed with practical programming constructs in mind. And since version 3.0, it does type inference as well.

Don’t get me wrong, I still like Python, but for production quality large programs, I think C# is just as productive, runs faster, and is far less likely to contain stupid runtime errors caused by typos.

Java wins because of refactoring and consistency.
Before super smart ide’s like Eclipse, Netbeans, and Intellij I would say Python was a better programming environment then Java.

But these new ide’s have changed the game completely. Instead of refactoring at the start of a new development cycle I refactor all the time. Instead of having UML charts and CRC cards and all that good OO planning crap you now (because of refactoring) can just write the code. I find proper language very important in expressing the domain you are working with that I care very much about the names of objects.

With python I would have to plan this in advance because it is a pain in the butt to refactor in dynamic languages.

Python is also not very consistent compared to Java. People can’t decide on consistent naming of methods and there are few odd things (like print with out parens).
BTW have you noticed Python 3 looks more and more like Java.

“Python is also not very consistent compared to Java”
No, it’s different form the beginning. Try to import your habits rom a language to another, the result will never be good. To understand the power of the Python language, you *must* play the game and conform yourself to the discipline.
Moreover, why would I need a complex and heavy IDE since simple Gedit/Geany do the work ?
Finally, you can refactor in any language you want. it does not depend on the syntax or whatever, but on your skills to avoid redundancy in your code.

Since everyone is bashing python, I would like to give my point of view from someone who has programmed in java and in python, and that likes python more than java.

For the ones that say that super IDE’s solve the problems of java, I would like to say that I have used both Oracle JDeveloper, Eclipse and Sun Netbeans. And from JDeveloper I have to say that it lacks features from the other two, for Eclipse that I need to get an extra 1Gb of RAM in order to run it together with my other applications (Try to configure Eclipse, to show how many memory it is “eating” in order, to check what I say), and them we have Netbeans that is the nicest IDE for java, but the fact that it isn’t easily expandable like eclipse with plug-ins means that you will have to download another version if you happen to suddenly develop something that requires J2ME instead of J2EE that you normally use. But all of these IDE’s require memory and some experience time in order to be used efficiently, so using a super IDE to correct java problems it’s not a way to solve things, at least not the way that I would use.

Now from the python side, it’s true that you don’t have a super IDE, but you don’t need one in order to use python… All you need to use python is the own interpreter, to indent your code and a basic idea of what you want to do. And a simple text editor, like notepad to type your code if you would like to persist it… It’s sure that python hasn’t a lot of libraries and tools as java has. But the ones that it has, are enough.

I can write my python programs in Microsofts note pad, even on iPod – heck on the back of a paper napkin if I want to… 98% of the time they’ll run first time with no exeptions!
by the time you’ve finished cleaning bugs i.e: “crap that should be an int, hmmm… and the bracket”, I’ll be watching old episodes of baywatch, having already delivered the software to the client.
To top it all of I can (thanks to jython) write python for your beloved Java VM.

“Jython, lest you do not know of it, is the most compelling weapon the Java platform has for its survival into the 21st century” – SeanMcGrath

But who really wins?… the programmer who can code in both languages proficiently, and who knows which to use and when.
… and who knows resisting the tide of change is futile…
———-
evil_laugh = “mwa” + “ha “*100
print(evil_laugh)#i havent even tested this code yet i know it just works :-). Python 3.1
———

The last point about code comments is laughable – “In my personal estimate, I spend 5 times as much time fixing such errors in Java as I do in Python”. Here is a secret – next time try using a decent IDE :)

Overall agree, that py is very terse, readable and to the point – but it still lacks the ability to parallel process and is way too slow when compared to Java.

* With python you have direct access to the pthread (posix) library: thread
* A higher level threading interface easier to work with than thread: threading
* Jet another library for trivially parallel loops: multiprocessing

it is foolish to ignore the importance of a compiler’s help. so python would be a disaster for a new large project, BUT today 99% chance is you build a small part of a big system, so python may be more productive and flexible.

@Anonymous (#17) – You seem to assume that Python is just as overly complex as Java, but this is not the case. Python is quite simple to read and it therefore reduces the amount of errors that are made in the first place so you do not need to declare errors before compilation (and btw, Python checks the files syntax on load). Also, Python functions and methods can have a docstring which can explain exactly what type of data to pass to it and again, without the extra complexity of Java, it is easy to figure out. And your last comment is simply a myth. I have absolutely no problem reading or maintaining Python code which has even a small amount of documentation. Instead, type declarations just make the code more complex than is needed and restricts flexibility.

As far as IDE auto-complete for certain types, it is not needed as the small number of methods used to interface with Python objects can be built-in and it can still save you many keystrokes.

Definitely not agreed with your article. Java is far more better for many reasons. I grant you that put down some lines in a bare notepad and compile them in Java is error prone, longer and surely boring (you have probably to search for imports, write long names, etc…) but with all the existent environmnents around JAVA and for Java, you don’t have any problem. All is fast, reliable, fit for big and scalable projects, and you can open files in any editor without screwing all with a wrong Tab option set (The Python biggest deficency for me is to be tied with the way you write and so the editor you are using).
I programmed in python but the performance is also poor. You can consider python for little projects, and be aware of some inheritance differences with java.
Also, if you want to use some third party library , you have to hope that the maintainer were careful about documentation sync with the code, thing that I rarely found in python external libs.

As in php (that is currently better than python as a web language), i’m a fan of the static type instead of dynamic. This eliminates the principal cause of errors in compiling and (worse) running sessions. In a lot of coded lines, it’s difficult to see an error like :
variable=1;
…
print varialbe;

python does not warn me (because of dinamic typing the ‘varialbe’ is initialized to null).

Anyway i think that python could become a good language in the near future if it’ll be surrounded by many support and enterprise structures that’ll permit to use it as a strong and solid base for enterprise applications. And in any case it will be good surely for fast prototyping.

i m a student and using java and found it too useful for big projects.i used c and c++ already and now unfortunately learning python :(and found it too difficult bcoz sometimes its too difficult to use such a simple syntax and i often got stuck in it :(((((((((

I have used Java for over 12 years now, and I agree that Java has become cumbersome in some areas, which is why open minded Java developers are looking elsewhere. However, definitely not for the above reasons. Most of them are either syntactic sugar variations of the same thing, or otherwise subjective opinions.

When one looks objectively at the above examples, they definitely do not demonstrate the 5 to 10-fold speed optimisations claimed in the article. In most examples its simply a question of syntactic sugar (e.g. Java requires { } to surround a block of code while Python does it with indentations… no big deal or optimisation, especially considering that most IDEs do these automatically, so if you’re a manager thinking that this will make your developers faster, it won’t.)

In most cases its just a question that Java requires some structure and not things floating around. The latter is available in Python simply because its a scripting language.

If one considers Example 1, on its own yes Java requires a class to put your stuff in so its 2 extra lines. But realistically no minimally useful script or class will be that simple. So its just a question of wrapping things in a structured way in Java.

== Static vs Dynamic ==

The question of static typing versus dynamic typing is a purely a question of opinion and the application domain you’re developing.
One downside to dynamic typing is that larger enterprise applications become more difficult to refactor. In static typing, changing a couple of classes will automatically break the compilation and you’ll immediately know what else you need to fix in order to have the program working again.With most modern IDEs this is also facilitated by refactoring tools which tell you immediately what will be impacted before the change and also automate the changes.

Another problem with dynamic typing is that its more difficult for IDEs to auto-complete fields and methods if the type cannot be disambiguously deduced.

== Multiple classes in one file ==

One can’t seriously state that this is an advantage. Java enforces you to do it not because the Java guys couldn’t do it, its because it is good practice to do so. If you don’t do this the code becomes unmaintainable as soon as it exceeds the 15 classes mark. You want to change the Employee class in java, you just have to open Employee.java, you need to do it in Python… good luck searching through the files.

I also use PHP and even though PHP carries the same ‘advantages’ from Python (it is both dynamically typed and allows multiple classes in one file) I still put my classes in separate files which carry the same name. Any serious work I’ve seen also adopts the same approach.

Again, if you’re a manager, this will slow your developers due to decreased maintainability not make them faster, so dont even consider it. If you do go for Python, it still makes sense to have classes in one place.

== Compactness and Readability ==

I tend to disagree with most statements in the examples.
Java adopts a very simple convention, that constructors have the same name of the class. Its logical, intuitive and makes perfect sense.
Why should a class have a method with the same name? It only makes sense to be the constuctor.

Instead in Pyton you have to use a cryptic method called __init__
Apart from the varargs issue, which is in fact supported (maybe not as cleanly) in Java, constructors in Java are far more intuitive.

You might also have noticed the ‘self’ argument in the constructor. So essentially, the class’s constructor also needs to be polluted with this parameter because there is no inherent ‘this’ that can be used within the class. Java supports this much more cleanly with a supplied ‘this’ keyword. Its also consistent because all developers use that, while Python all developers do what they want, some use ‘self’, some use ‘this’, some use ‘myself’…. confusion welcome.

With regards to using indentations instead of curly brackets. Again this is not an advantage at all. It just invites confusion in. Most IDEs put the closing curly automatically so its not something that will contribute to slower development. On the other hand it clearly delineates code blocks.
Using indentations just invites problems with different text editors. The curly also has the advantage that most IDEs highlight the opening curly when you select hover over the closing curly (even though if you adapt the allman-style coding this won’t be needed anyway).

———

I am not saying that all is rosy on the Java side. I am just saying that these examples are the perfectly wrong reasons to consider.

Some of the problems of Java are:

1. JAR hell.

The way libraries are managed in Java were elegant in the early 2000s where you would have a handful of Jar files and you would know what each was doing. Nowadays, there are so many of them that you would need to include in an application that it becomes a nightmare to manage, especially due to interdependencies between them and conflicting versions.

Maven came along which kind of solves this problem, but its still there, just managed a bit more intelligently.

2. Desktop performance

The performance of Java on the desktop for some reason never got anywhere near native or .Net applications. You immediately know that you have a Java desktop application because its slow to start up, hangs intermittently (due to garbage collection) and has a lousy UI.
In fact the only ‘successful’ desktop apps written in Java are in fact Java IDEs.

This is in fact a true source of slowness. Java developers typically waste 20% of their time playing around getting their environment to work. Starting up the IDE takes minutes. Then it starts hanging after an hour or so of developing. You can throw more computing power at it obviously, but we’ve been throwing more computing power at it for the last 10 years with newer PCs, more memory and faster CPUs, and the problem is still there.

3. Web Applications

Developing a web application in Java is in fact very complex.You have to understand the whole framework of web application servers, servlet containers, application contexts, and all just to even start doing a simple web application. When you’ve done that you realise that what you know is not really enough to make a maintainable reasonably sized application, so you have to learn other technologies such as Spring, Spring MVC, or JSF. After you’ve done that you realise you also want to hit the database, and you have to learn JDBC and JPA.

By that time, a developer in another more web-oriented language would have already completed the project, got the pat on the back and moved on to another one.

The end result in Java is very neat but the learning curve is very steep. You can easily go wrong somewhere and the moment you have a problem the tools are less than helpful. The only advantage of going for Java for web apps is when you have a large application which requires thought, discipline and good object oriented design, maybe with some scalability needs and requirements for message queuing (JMS etc.) or integration with more Java friendly components.

Developing web services is also similarly complex. Conflicts between the bundled JAX-WS and any updated version often drive Java developers crazy and is a major cause of suicides.

So, yes this is a true source of slowness of Java.

Bottom line is that most of the slowness of Java is not with the language itself, which is just C-style like 70% of the other languages (C, C++, C#, Javascript, PHP…). Its because expectations in certain areas have outgrown its original design and other more domain-specific languages provide a more agile framework.

Disclaimer: I’m not a proper programmer, I’m a mathematician looking for unbiased advice.

I like python, don’t know Java. I find it highly productive. I don’t get the arguments that it’s not suitable for large scale applications because it doesn’t enforce “discipline” or “good object oriented design”. I don’t want the language to enforce anything, but maybe it helps if your coworkers write sloppy code.

However, it seems like Python is used more by the academic community (most notably the academics without a CS background, such as myself), whereas Java is used more for large enterprises, can someone enlighten me as to why this is the case? I’m currently in the process of writing a prototype for a large data retrieval and analysis framework. I get results quickly in Python (hence why I use it for prototyping) but I’m worried that I might have to rewrite everything in a non-scripting language later on. Should I be worried? The plan is to get investment capital so we can employ some “proper” programmers who knows these things!

Basically, is this article as biased towards Python as it appears to be from all the comments?

“…whereas Java is used more for large enterprises, can someone enlighten me as to why this is the case…”

There are perfectly valid reasons for using Java on enterprise projects (strong server infrastructure, frameworks, portability, etc), but there are also other reasons why Java is often used for enterprise projects, even where it is not necessarily the best choice, especially when large outsourcing consultancies are involved:

1. Universities teach Java, so CS grads know it (a bit…) => cheap grunt programmers easily available.
2. Indian universities turn out lots of Java-enabled CS grads => even cheaper grunt programmers available offshore.
3. Java “culture” encourages the idea that you can do everything in Java => no need to teach your grunt programmers about anything else, even if it would be useful to do so.
4. Java EE is very complex and becomes ever more complex in line with Moore’s Law i.e. complexity doubles every few years. Complexity => costs => profits for consultancies.
5. Efforts to combat that complexity e.g. Spring have themselves now become almost as complex as the “problem” they were intended to solve => complexity generates complexity.
6. Once you’ve invested in a complex Java EE system, you’re pretty much trapped in Java-land => more profits for long-term support agreements etc.

“… Java is used more for large enterprises, can someone enlighten me as to why this is the case…”

I’d like to add to Matt’s last point, which I’ll rephrase like this: “For any given programming language J, once you’ve got a major investment in J, you’re pretty much trapped in J land.”

Suppose you are an enterprise IT manager. Your staff know programming language J. You’ve developed a number of large systems in J; you’ve created build, test, and deploy procedures and tools for programs written in J; you and your staff are comfortable with J and have mastered the art of system development in J.

Now suppose that you have some new kind of programming task to perform. The task can be done using J (albeit it will take a while, and the result will be not very elegant) or it can be done using using some other programming language P, where the task can be done in P much more easily and elegantly.

The problem is that you already know J — there is no learning curve to climb with J — but you’d have to expend some time and effort to learn P. And you know that there will be other tasks down the road that might be best done in some other language P2, and some other tasks for which P3 is the best tool, and then P4, and P5, and so on. And you know that that way lies madness. If you go down that path, you’ll soon have to maintain systems written in a dozen languages, and eventually you’ll find yourself in a situation where some programmer leaves; he wrote some system in programming language P9; but he was the only one who knew P9; now he’s gone and none of your staff can maintain the system.

So you decide to standardize on J, where J is some general-purpose widely-used language that has a lot of add-on packages and frameworks that allow you to do just about anything in J. You make the decision: “From now on, we do EVERYTHING in J.”

The managers of many (most?) enterprise shops are in this situation, and they choose to standardize on Java because they need to control costs, and to control the number of programming languages that they are using. This decision is partly a matter of economics (the need to control costs), and partly a matter of management (the need to manage the number of languages used in your shop). These are good reasons, and the basic ideas behind the decision are undeniably good ones.

So that is my take on why “Java is used more for large enterprises.” Now: here is my take on why that is a bad idea.

The problem is that — although the basic reasons motivating the decision are good ones — the idea that ONE size fits all is simply too restrictive. A tool box that contains only one tool is simply not enough. If you confine yourself to just ONE language, you will find that there are cases that are simply too much of a stretch for that language. Personally, I think that every shop needs to standardize on at least *two* general-purpose languages — one “system” language for major systems where performance is the highest priority, and one scripting language where ease-of-use, flexibility, and speed of development are the highest priority.

Personally, I think a combination of Java and Python is a good choice. And I believe that a management decision that “From now on, we do EVERYTHING in Java,” is a big mistake.

But that was the situation that I was in when I originally wrote this article. Our shop at the time used a systems language and a scripting language— Java and Perl. We had found through experience that the Perl was unmaintainable. And we had decided to migrate our Perl applications to something else. I thought that Python would be an excellent replacement for Perl.

But the division chief felt that we should standardize on a SINGLE language — *only* on Java — and that we should migrate all of our Perl apps to Java. In my opinion, this would have been a very bad (actually, a ridiculous) decision, so I wrote this post to explain (in part) why I thought that for some applications Python is a better choice than Java.

So that’s all I have to say on that subj… What? Oh, you want to know the end of the story? Well, OK…

There was a management turn-over. The new division chief had a completely different “let a thousand flowers bloom” philosophy. It was like a breath of fresh air. Soon the group — in addition to its older systems in Java and Perl — had new systems written in Python and Ruby. I eventually developed a large application (30,000+ lines) in Java, and a testing framework for the application (the first such framework in our group) written in Python.

That was the upside. The downside is that because the group never decided to standardize on a scripting language (Perl, Python, Ruby, whatever), it now faces the problem that I mentioned earlier. I was the only one in the group that used Python. When I left the group, they were left with a large, sophisticated test harness written in Python… but without anyone who knows Python to maintain it.

is this post as biased towards Python as it appears to be from all the comments?

As the author of this post, I’d like to talk a little bit about why (I think) there are so many allegations (most of them, in fact, attached to the companion article on typing) that the post is biased, and about whether or not I agree with those allegations. I’m going to paint with a broad brush here.

I think that the first reason for the charge of bias is that the wording of the post is carefully nuanced, but many readers missed the nuances. In fact, many readers completely missed the point that I was trying to make.

If you read the post carefully, you will see that I make no claims that Java is a better programming language than Python, or that you don’t need Java because Python is the only programming language that you will ever need, or that you can do all of your programming in Python, or that Python is superior to Java in any way other than productivity. I make no claim that I’m offering a comprehensive, technical feature comparison of the two languages. In fact, the post contains several statements denying that I’m making any such claims.

But I think that many Java programmers quickly skimmed the post and responded as if I’d simply grunted “PYTHON! GOOD! JAVA! BAD!”

Naturally, their reactions were negative and, in many cases, angry. If you read the comments, you can see that some of the commentators are almost incoherent with rage.

I want to note, however, there were a few Java programmers who read the post more carefully, and responded with helpful information and calm, reasonable, comments. It was a pleasure and a learning experience to read those comments, and (amazing as it may seem) I agree with many of them.

The second reason is that most of the comments are from Java programmers. After reading the post, I think that most Python programmers simply shrugged — “Yeah. So what. I know that. Nothing new here.” — and moved on. In contrast, many Java programmers read the post as an ignorant yet vicious attack on their favorite technology (see reason number one, above). Naturally, many of them responded, and responded with vigorous dissent.

So I think the charges of bias can be accounted for by the fact that most comments are from Java programmers, many or most of those Java programmers are angry, and many of the angry Java programmers did not read the article carefully or objectively. I don’t think the post was biased, but I think that many readers read it as making more sweeping claims about Python and Java than I was actually making. (Probably, I should have worded the post differently, although I’m not sure how much difference that might have made. For what I would do differently if I were writing the post today, May 2012, see below.)

Let me talk a bit about the kinds of comments on the post. There were many kinds of comments, but a few (sometimes overlapping) categories stand out.

The first category includes comments citing (a) the superiority of Java IDEs (over simple text processors or Python IDEs), and/or (b) the superiority of Java’s declarative static typing over Python’s dynamic typing. Some of these comments asserted that — “Yes, Java is more verbose than Python. But Java IDEs are so good that they make up for the difference, and in effect allow a Java programmer to be just as productive as a Python programmer (as measured by function points per keystroke).”

Some of these comments asserted simply that you cannot build large (enterprise-scale) applications in a dynamically-typed language. Some of these comments asserted that — “The declarative statically-typed nature of Java allows Java IDEs to be much more powerful and useful than simple text editors or Python IDEs; this makes Java programmers more effective when developing — and especially when refactoring — large code bases.”

A second category asserted that I was comparing apples and oranges. Python may be OK for small systems, but for large systems (a) Java’s static typing, (b) Java’s superior performance, and (c) the superior powers of Java IDEs make Java the only rational choice. A nice example of this type of comment came from Daniel:

Comparing Python to Java is like comparing a bicyle to a car. Sure, it’s easier to learn to ride and you don’t need to struggle with the license, but as soon as you want to go more than 10 miles (“write an enterprise application”), the only choice of the two is the car.

A third category of comments focused on features of Java. Such comments typically included assertions like — You don’t really know Java; your example of Java feature F was wrong; the latest version of Java has a new feature F which invalidates one of your points; or you should have mentioned the following Java features (followed in some cases by quite a long list of features). In this category, many comments began with words to the effect that either (a) “You’re wrong. Java is by far the best language because Java …[list of Java features]” or (b) “I agree. Python is by far the best programming language. I can’t stand Java because Java …[list of Java features]”.

I’m not really sympathetic to the third category of comments, because they completely miss my point. I don’t think that there is any “best” programming language. As I wrote in the introduction to the post:

Our toolboxes should contain both Python and Java, so that in any given situation we have the option of choosing the best tool for the job. So our claim is not that Python is the only programming language that you’ll ever need — only that the number of jobs for which Python is the best tool is much larger than is generally recognized.

I’m much more sympathetic to the first two categories of comment. The comments citing the superiority of Java IDEs were appropriate a few years ago, although they now seem less compelling with the release of the JetBrains PyCharm Python IDE. But I think that I would agree that the statically-typed nature of Java allows Java IDEs to be much more powerful than Python IDEs, and this helps Java programmers immensely as they develop and refactor large code bases.

The downside, of course, is that it is virtually impossible to develop a Java program outside of an IDE. Java programmers are virtually chained to their IDEs (and their specific IDE — Eclipse, NetBeans, whatever) in a way that Python programmers are not. Technically, this may not be a productivity issue, but for some developers it is definitely a personal taste issue.

In conclusion — If I was writing the post today, I would be less inclined simply to talk about the “productivity” of Python programmers compared to Java programmers. There are many dimensions for measuring productivity, and many kinds of applications, and a language feature that enhances programmer productivity for one type of application might actually impair programmer productivity for another type of application.

If I was writing the post today, I think that instead of talking about “productivity” I would instead talk about matching tools and tasks. Any large organization is in the business of building many kinds of software applications. I would emphasize that for building some types of applications, a systems language such as Java is the best tool; and for building other types of applications, a dynamically-typed language such as Python (or Ruby) is the best choice.

Come on man, an open source linux distro will have 100’s if not 1000’s of developers working on it.

————–

I’ve read most of the comments here and I’ve used both Java and Python. Leaving aside the comparisons of the two languages I agree mostly with what JBX and what Steve Ferg had to say in the end.

I think as programmers and software “houses” we shouldn’t be comparing languages, each language has a specific purpose because of their differences.

A heavy language like Java, C, .NET and objective C is a good weapon in your arsenal for systems programming (Java and C would be the clear winner since .NET and objective-C are platform dependant). A scripting language like ruby, python, hell even PHP is a good weapon for web development and rapid prototyping. A lightweight powerful language like Ada is great for embedded programming and for use in safety critical situations where program proof of correctness is more important than lack of bugs (which beats strongly typed by a long mile if bugs are a huge issue).

So at the end of the day, having a plethora, yet minimal amount of languages suited for different purposes is key to being a good programmer or software ‘house’. I can’t speak for development time (that is a none issue in a perfect world, and our aim should be to make the world perfect, because we’re engineers, not bankers or financiers).

So using the right tool for the right job is more important than which programming language is better. Oh and coming up with the right architecture for your system, might give you the ability to use more than one language for different parts of your system possibly making development time faster.

Two things. In Java I use an IDE, which is a machine that helps me write code. It can do this well, much better than any Python IDE can, because Java is strongly typed. I use Jython to script my Java application, and Jython is great for building small applications, but it’s looseness makes it difficult to build anything large. My Java app is 400K lines long and I can get around no problem because of Java’s precision. Jython scripts that drive it get long and a bit unmanageable at 500 lines…

agree. verbosity with Java is not a problem unless you write your codes in a text file, and no one does that for a big application. python is a great language and it has its own purpose. This is just another meaningless article.

Productivity isn’t only measured at the time you actually write the code. Java is much more easy to maintain (static language in general are much easier to debug , test and maintain) it has some pretty powerful editors that shrink the productivity gap with dynamic languages.

I understand that this is about productivity, but, it seems you’ve forgotten to talk about type checking. With Java, you are forced to fix type mismatches, while with Python, you can get type related errors without even realizing they are there. From personal experience, doing manual type checking sucks. Another thing I want to point out, is in some places, you’ve over complicated the Java code. For example, in the employee class, you could’ve just forced the calling method to pass all the variables at once, and shortened the code hugely. Also, in your tuple demonstration, you could’ve have just used an array.

For me, the biggest hit against Python is it’s IDE, and the file setup. Pythons IDLE had a horrible font, that looks bad, and is to small. I also dont like the folder structure of Python. Unlike Java, it has no folder structure, leading to Python being to open ended, which lead to my next point.

Based off your article it seems you like Python for its open endedness. For the ability to form and more variables without casting or declaring types. For the simplicity of the coding such as the ability to say print() rather than System.out.println();. But, the necessity to type everything, the structure,the rigidity of Java, is Java’s greatest triumph. When you see System.out.println(); you know that you are calling println(); from class out, from the basic system. With Python, print() tells you nothing. This might seem useless and verbose, but it has actually helped me.

I needed to change the background of Swing’s JComboBox, but combobox.setBackground(Color.BLACK) did nothing at all. (I was using the basic UI) To fix it, I knew that the line of ancestry was JComboBox, Popup, List, and thanks to the well documented Java API (another one of Pythons down points) I new that that JList was where you set the background. This would have been much harder if Java allowed multipul inheritance.

I know that over the web, intent is hard to uncover, so take the point about verbosity as a joke.

Over all, your article was very well written, and very enlightening, but the one thing I wished you had touched upon, not because I want to hurt your opinion or anything, but rather, because I'd find it interesting from a Pythonian's point of view was the debugging, type checking, and things like that. Again, very well written article, thanks for this great resource

Unfortunately I cannot edit my older post (the one above), so I’ll add one thing to my IDE point. Java has more and better IDE’s than Python, such as Eclipse. (yes, Python can be coded in Eclipse, but when I make errors, it keeps telling me error in “JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC.” I’m sure you’ll agree with me that it isn’t an enlightening message. :-)

Did you install PyDev? I dislike Eclipse (slow and fat), and prefer Notepad++ with the NppExec plugin. Beginners on windows probably prefer PyScripter. I’d use Eric for Python GUIs, and Pfaide if decadent.

I’m a programmer from a diverse background and I’m considering learning Python as another string to my bow, so I’ve found this article and the associated comments extremely helpful in gaining an understanding into Python. There’s one thing I’m not clear on though – aren’t we comparing apples to oranges?

To me it seems that Python is more analogous to PHP or Perl than Java. Or am I missing something?

The stereotypes go that PHP is for websites and Pearl is unreadable. PHP still feels like an inconsistent speed hack to serve dynamic websites, and Python is a readable Perl that is less text-oriented. Java is a “write once, run anywhere” replacement for C++, and still is a lot like C++, complexity-wise.

“There’s one thing I’m not clear on though – aren’t we comparing apples to oranges?”.

Exactly. It’s all about comparing something cannot be compared. I’m a person who programs from time to time, just to create some simple tools working for me and performing repeatable and time-consuming tasks. I’ve tried a few different languages, including Java (works perfectly with modern IDEs, indeed; and your tasks may be even triggered on your old rusty mobile phone, which is really cool).

But for sure Python is a simplest and smartest tool for people like me. For me there is often a matter of “to code or not to code”. Some projects would not be done, if I was not able to achieve a goal in reasonable time (which is possible in Python only). From this perspective Python rules. But I would never say “it’s better than Java”. It’s just misunderstanding to compare them using criteria presented above.

I too am a programmer from a diverse background, having written in assembly, Fortran, Pascal, BASIC, C, C++, Java, Ruby, LISP and a few others. I am looking at Python, not because I want an alternative to Java, or need yet another language to program in, but because I am looking at a hardware/OS environment that simply offers development in Python.

In many cases, I find the choice of programming languages and environments are not free for us to chose but are instead thrust upon us by extenuating circumstances. That said, there are still cases where we get to make a choice. BTW, my introduction to Java was just one of those cases, using a software framework, provided by the company who’s systems we were utilizing for a project, that framework being written in Java.

That said, as I go back to the beginning of the article and look at the objective, productivity, I am once again disappointed in the way this was presented. Too many articles do the same DAMN thing, they talk like productivity centers around one thing, in this case language…this is simply not true! Productivity starts long before any language is even used. With the exception of ridiculous and meaningless tasks, like “Hello World”, which is misused abusively as a representation of or comparison between languages, I dare say a vast majority of programming tasks undertaken are large and complex (albeit, built on smaller components). Productivity starts with design!

I’ll say it again to make sure it came across, “Productivity starts with design!”. I read an article recently, and I wish I had taken the time to blast back at the author who claimed “flow-charting is dead”. Anyone who undertakes a programming challenge without any planning is not a programmer, they are a tinkerer. The amount of planning varies on the task and may range from a simple mental statement (“I’m gonna write a program to print ‘Hello World’ on the computer display”) to a 100+ page Statement Of Work (SOW) outlining all the interfaces to the system, storage requirements, accesses, processing, graphs, measurements, controls, the list can go on. The thing is, the system should be DESIGNED before it is built. And I think the good programmers out there who read this know and understand what I am talking about.

So am I detracting from the article, the article after all was all about programming and here I am saying hold on, the article should have been about preparation? Yes…and…no. The article was about productivity, but chose to center that productivity around languages, and this is wrong. Why?

Once you design what you want to build, the language begins to have less importance than the article suggests, and at the same time, more importance as may be understood by many of the discussions. In a complete system design, once you know what you want to accomplish and how you want to go about it, details like static or dynamic take on less importance. You already know in advance the majority of the data elements you want, so you can easily define them in advance in a static manner or define them as you go in a dynamic manner, little difference since you already defined them in the design! However, as you design, you may also recognize certain code reuse, code complexity, task breakdowns, interfaces and other aspects for which one language may have advantages over another. And yes, in this overall view, static vs. dynamic may play out as an advantage, either way.

The point I am making, and will direct this at the author, is that there is a lot more that goes into the choice of language than just the ease at which certain things can be written. I do realize you did not specifically make out that Python is always superior to Java, and although I have to agree with many that the format of the article did seem to present that Python was superior to Java, that doesn’t matter to me. What disappoints me is that you presented an article, suggesting that the choice of language was THE thing to consider in productivity and it is but one little piece of the game.

As I stated at the start, I have written code in numerous languages and to add to that, I have written everything from simple short applications, barely more than the infamous ‘Hello World’ to large machine and systems control applications and database systems. I always start with a thorough plan and consider all aspects. I typically work in C and Java (a complexity on its own) and often that is driven by the environment, the other people I work with, but that doesn’t stop me from looking at alternatives (just like the thing that brought me to this article). I always consider not just the task at hand but the ‘reuse’ ability and future maintenance of the work I do. I will not go so far out as to be the sole maintainer, leaving the company “holding the bag” if I leave, unless there are dramatic and very compelling reasons, usually coming down to efficiency and productivity at a significant level.

I apologize to those reading my whole response for the long winded nature (that seems to be my nature, I never do anything short). Please don’t make the choice of languages based on a misconception that one is necessarily easier or more appropriate than the other. Any surviving language has a reason that it is surviving, and for the most part, that fact alone makes the language viable for any application. Look at all aspects of the application, look at yourself, look at the others who may want to use or extend your application, and then chose the language that best fits the total environment.

Reading of code happens more than writing of code, thus the code should be as clear and simple as possible. Python has clarity and simplicity as its main goals, and is more suited to quick adaption than Java. I do not recall any real-world project that did not require changes, as users rarely know exactly everything they’ll ever want in the product until they use it.

Too many people on here mention IDE’s. We are comparing two languages, not the tools that we use to code them with (imho, Eclipse is garbage, but that’s another topic all-together.)

You can do in Python what you can in Java in a faction of the lines of code, but that doesn’t necessarily make it “better”. I am more productive in Python because I have less code to write, which also means fewer lines to debug (important!).

Clean and efficient code are what you need at the end of the day, and both languages can achieve this. There are just some simple tasks that Java makes too verbose and Python steps in to fill that void. If I had to choose between the two languages for my daily coding, I’d choose Python each and every time. For me, it’s the simple fact that I can get a heck of a lot more accomplished in Python [than Java] in a noticeably shorter amount of time.

I’m new to Python. If Python, when used for gaming, derives its power and speed from diverting many CPU/GPU bound routines to C (or C++ in the case of Boost Python), who do they interface with data when Python uses dynamic types and C uses static types?

Let’s be honest guys, the choice between any programming languages is based on personal habits and taste. I tend to make a good few mistakes the first time around, and therefore java is my favourite language. I also find it less complex than almost all others. Sure, it uses up a bitchton of lines, but that doesn’t really matter once the application is effective.

I read almost all comments and I there is one point that all of you missed! The logo is important for productivity!

The Python logo is obviously a snake. The name of the language, however, was based on Monty Python. So what this means is that you are going to have good laughs when the python bytes you. Specially when the code is too long to debug or understand.

The Java logo is a cup of coffee. What this means is that you are going to need coffee when programming in Java or you will fall asleep. In fact you are going to need loads of coffee when your code is near production stage. BTW I don’t drink coffee, so my job is twice as hard.

Jython is when you give coffee to a snake. Jython users are people that drank toomuch coffee and over time it doesn’t have any effect anymore. Since the python needs to sleep, the solution is giving coffee so that Java programmers can also have laughs at late hours of the day.

I know that you are aiming to make the code examples comparable, but do you have to use camelCase in Python? The Python conventions call to use underscores for variable and function names, and CamelCase only for class names (and camelCase where the first letter is lowercase nowhere).

I know Java very little and I do not know Python ( which I am looking at right now as a free alternative to C# ). I immediatelly feel from where the power of python comes – STL-like programming style on collections. Long ago I have got to work with STL and was totally blown by its incredible power. ( STL is an extension of C++ ). Is there something like that in Java? Which language is going to win eventually? ( Besiges unbreakable C++ place under the sun ) The one which realises STL-like programming. Period.

There is nothing like that in Java. You might want to look into Scala instead. It is Java compatible, has the STL-like programming and even more. When it comes to data structures I do see one weakness in python when compared with Java: you cannot choose your data structure implementation.

In Java when you do something like “SortedMap m = new TreeMap()” you know you are using a tree, which is actually a red-black tree. You can also choose a HashMap and so on. In python you only have one choice, the dictionary. How is python dictionary implemented? I don’t know but it seem to be an open hash table.

If you want to go with JVM, Scala goes one step further, you can choose your data structure implementation, has STL-like programming, supports functional programming, etc. I see it kind of like a fusion between Java and Python and some functional languages. You might want to look into Clojure also, although that’s a functional language.

> ** > commented: “There is nothing like that in Java. You might want to look > into Scala instead. It is Java compatible, has the STL-like programming and > even more. When it comes to data structures I do see one weakness in python > when compared with Java: you cannot choose y” >