A subjective analysis of two high-level, object-oriented languages

Comparing Python to Java

Foreword

This paper is subjective, and as such, is not meant to be a serious technical discussion of the various merits of these languages. It is my own personal opinion, and we all know what opinions are like.

The purpose of this paper is to provide a perspective for people planning to start their own projects in one or the other of these languages. As such, if you are reading this and have a different paper that you'd like to submit as a counterexample, I will gladly link to it.

Section 1: Performance!

Again, I must stress that these are approximate times, which are specific to my computer, my Java version (JDK 1.1.7B, blackdown), my operating system (Debian GNU Linux 2.2), my python version (Python 1.5.2) and my idiosyncratic test method, which is not strenuous at all. I repeated the tests 3 times and averaged the results to get the numbers you see here. Sources to the tests are available here in .tar.gz format, so you can perform them yourself.

The overall conclusion one may draw from these numbers is that Java is generally faster. If it's that simple a conclusion you're looking for, though, I recommend using C++ as your language -- neither Java nor Python can hold a candle to a true systems-level language. (I originally thought of including C or C++ comparisons here, but the difference is truly laughable, especially with compiler optimisations.)

Test-By-Test

for x in xrange(1000000):
    print x
    

public class ConsoleTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000000; i++) {
            System.out.println(i);
        }
    }
}
    

for i in xrange(1000):
    x={}
    for j in xrange(1000):
        x[j]=i
        x[j]
    

import java.util.Hashtable;

public class HashTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            Hashtable x = new Hashtable();
            for (int j = 0; j < 1000; j++) {
                x.put(new Integer(i), new Integer(j));
                x.get(new Integer(i));
            }
        }
    }
}
    

f=open('scratch','wb')
for i in xrange(1000000):
    f.write(str(i))
f.close()
    

import java.io.*;

public class IOTest
{
    public static void main(String[] args) {
        try {
            File f = new File("scratch");
            PrintWriter ps = new PrintWriter(new OutputStreamWriter
                                             (new FileOutputStream(f)));
            for (int i = 0; i < 1000000; i++) {
                ps.print(String.valueOf(i));
            }
            ps.close();
        }
        catch(IOException ioe) {
            ioe.printStackTrace();
        }
    }
}

    

for i in xrange(1000):
    v=['a','b','c','d','e','f','g']
    for j in xrange(1000):
        v.append(j)
        v[j]
    

import java.util.Vector;

public class ListTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            Vector v = new Vector();
            v.addElement("a");
            v.addElement("b");
            v.addElement("c");
            v.addElement("d");
            v.addElement("e");
            v.addElement("f");
            v.addElement("g");
            for (int j = 0; j < 1000; j++) {
                v.addElement(new Integer(j));
                v.elementAt(j);
            }
        }
    }
}
    

from pynative import *
for i in xrange(1000000):
    hello()
    

public class NativeTest
{
    public native void nativeMethod();
    static {
        System.loadLibrary("javanative");
    }
    public static void main(String[] args) {
        NativeTest nt = new NativeTest();
        for (int i = 0; i < 1000000; i++)
        {
            nt.nativeMethod();
        }
    }
}
    

#include "Python.h"

static PyObject*
pynative_hello(self,args)
     PyObject *self;
     PyObject *args;
{
  printf("Hello, world!\n");
  Py_INCREF(Py_None);
  return Py_None;
}

static PyMethodDef NativeMethods[] = {
  {"hello", pynative_hello, METH_VARARGS},
  {NULL, NULL}, /* Sentinel... what's this? */
};

void
initpynative()
{
  (void) Py_InitModule("pynative", NativeMethods);
}
    

--- Autogenerated NativeTest.h ---
/* DO NOT EDIT THIS FILE - it is machine generated */
#include 
/* Header for class NativeTest */

#ifndef _Included_NativeTest
#define _Included_NativeTest

#pragma pack(4)

typedef struct ClassNativeTest {
    char PAD;
/* ANSI C requires structures to have a least one member */
} ClassNativeTest;
HandleTo(NativeTest);

#pragma pack()

#ifdef __cplusplus
extern "C" {
#endif
extern void NativeTest_nativeMethod(struct HNativeTest *);
#ifdef __cplusplus
}
#endif
#endif
---


#include <stdio.h>
#include <jni.h>
#include "NativeTest.h"

JNIEXPORT void JNICALL
Java_NativeTest_nativeMethod(JNIEnv *env, jobject obj)
{
  printf("Hello world!\n");
}
    

public class NoTest { public static void main(String[] args){} }
    

class ObjectTest: pass

for i in xrange(1000):
    root=ObjectTest()
    for j in xrange(10000):
        root.next=ObjectTest()
        root=root.next

    

public class ObjectTest {
    public ObjectTest next;
    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            ObjectTest root = new ObjectTest();
            for (int j = 0; j < 10000; j++) {
                root.next=new ObjectTest();
                root=root.next;
            }
        }
    }
}
    

for x in xrange(1000000):
    pass
    

public class SpeedTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000000; i++);
    }
}

    

Patterns in these Examples

Java's documentation is generally better, and better organised (at least the API doc) but even though I've been using Java for several years, and python for only a month, I found it easy to remember all of the python necessary for this exercise without resorting to the module doc; I had to look up 3 things about IOStreams and URLs in the Java documentation.

Java programs are longer than their equivalent python programs. In fact, they're approximately 3 times longer, if you're counting bytes in source code (remembering, also, that python programs can run from sources and Java must be compiled first). Totals for the programs I wrote (source only) were: python, 921 bytes, Java, 2,742 bytes.

Java is faster, and more suitable for "systems-level" programming. I believe that c -> c++ -> Java -> python establishes a nice continuum of systems-oriented, low-level programming to application-oriented, high-level programming.

Reasoning Behind Obvious Mistakes

I would love to hear from other people who have run the same test-cases and come up with different results.

Cool things I like about python

• Python is not "pure" as languages like LISP and Java attempt to be -- it abandons individual ideological (Object-Oriented! (Java) Functional! (lisp) Procedural! (Pascal) Efficient! (c) Expressive! (perl)) standpoints to produce a synthesis of all of the above that makes for appropriate syntax for appropriate structures. At the same time, it's ordered enough to escape Perl's wackiness. Sure "for i in j" is a bizarre syntax, but it's something that programmers do all the time in every kind of program. Java's solution to this is the java.util.Enumeration type (an Object!). Lisp's is "map" (a function!). When all you have is a hammer...
• Everything is an object -- like, actually an object! The other language which approaches this is Lisp, but it treats functions as magical and special. (Ironically, lisp is probably better-suited toward treating functions as first-class objects if you need to do it seriously, it just makes it awkward for casual use like function callbacks...)
• Native associative, iterative, and list data-structures are great both for clarity and efficiency -- even greater is the ability to override that syntax if you have your own associative, iterative, or listing data-structures.

Unresolved Release-Critical Bugs in Java

From a language-design perspective, the next section won't be interesting; however, it's a very important look at the real-world consequences of choosing this language, unless you plan to write your own virtual machine (or use one of the free ones, like japhar or kaffe... which don't even necessarily have the APIs implemented that these bugs are in).

Don't Use Swing.

Want an arbitrary number of frames in your app? Sorry; you'd better keep track, and set a hard limit. I wouldn't count on re-using components either; add() seems to leak like a bitch too. Widget re-parenting appears to too, but this is small enough that it's livable.

Opening about 100 windows with a decent amount of widgets will crash a VM -- and I don't mean "at once". I mean at all. Open window, close window, open window, close window... repeat 100 times, and boom, your app is *permanently* out of memory, unless you've loaded all the swing classes in a special classloader and you're ballsy enough to go re-loading them all every time that happens.

The AWT does this too, but you could probably write an application that ran for longer than 20 minutes using it.

Don't allocate memory.

Even if you do decide to be brave and diddle the commandline options, the aformentioned problems with GC makes it unfeasable to allocate really large blocks of memory in Java without a ten-processor SPARCstation.

Don't use java.lang.String.intern

Don't expect your app to run

This problem is so bad that even third-party applications that purport to solve this problem, such as Zero-G software's "Install Anywhere" will sometimes fail, simply because it's impossible to determine certain information about the operating environment. (No slight to "Install Anywhere" -- it's a GREAT product, and works very well for their supported platforms!)

Note: Some people have brought it to my attention that the same thing could be said about python; however, I have not found it difficult at all to run my python scripts on Windows or MacOS; the packaging process for Java applications is highly platform-specific and usually requires an intimate knowledge of where you want it to run... well, unless you're not using ANY libraries at all, and your entire app is a single class-file. Java2's -jar option makes this slightly easier to do, but it's still painful (not to mention undocumented) to determine the version and capabilities of the installed VM.

Don't print anything

Don't write large apps

Don't write small apps