Beyond Java?

Python is cool. Having mentioned it I couldn’t resist coming back with a brief and slightly more technical discussion on why I think it’s such a great language.

First of all, I should point out that I’m still recovering from my Java addiction, one that lasted about six or seven years. I’ve come to find that Java addictions are, actually, not that hard to break though. As a language, Java has become bulky and in many regards just doesn’t live up to the promise of a shiny, new, cross platform environment that would be the language of the future. As my disillusionment in Java grew, I found that a much more deeply-seeded addiction was coming to the fore: Objective C. I started working in Objective C back when NeXT Computer was still a gleam in Steve Jobs’ eye — and on and off, have worked with it ever since. As Java lost it’s luster over the past few years, I’ve come back to basics. Objective C remains one of my favorite languages — efficient, object oriented and reliable.

But despite my fascination with the language, Objective C projects are few and far between. This may be one reason why Python has become such a focal point for me lately — I need a new, elegant language on which to build the promise of the future.

So, why Python as opposed to any of a host of other languages? When I first started looking into Python my interest chiefly lay in choosing a good technology for a new enterprise web project — something that allows for any extent of customization, but does it in a reliable, scalable fashion. The requirements include finding a solution that supports very rapid interface development, supports enterprise integration goals and is lightweight enough to get a product out the door quickly. Java and J2EE is just too massive to fulfill rapid, flexible development. Most web oriented technologies (such as PHP) don’t offer the enterprise capabilities and language features I’m looking for.

My first exposure to Python was Sean Kelly’s Better Web App Development screencast, an excellent work still hosted courtesy of NASA. Sean’s presentation compares several technologies, including J2EE, Rails and Plone, a Python based CMS system. During the course of the show, Sean authors a simple time tracking application in J2EE, an activity that took about 500 lines of code spanning JSPs, Java, XML configuration files and other activities. All in all for the work at hand, it’s tedious given the simple goals of the project. But what stuck with me is the Python equivalent implementation in Plone. Sean’s example uses absolutely no source programming, instead relying on a few UML diagrams that were converted to XMI and compiled directly into a Plone application. Instead of hours worth of work the job is finished in minutes.

I was fascinated enough to look at another of Sean’s screencasts. Recovery From Addiction is a fun listen and — perhaps more to the point — gave me my first appreciation for Python’s rich language features and concise structure.

At first glance I disliked Python’s simple development philosophy. A philosophy that seemed too open and lacking structure. Sean’s cast walked through a comparison between a Java and a Python Coordinate class. The results: 21 lines of Java code, and only 3 lines of Python code:

class Coordinate(object):
def __init__(self, latitude=0.0, longitude=0.0):
self.latitude, self.longitude = latitude, longitude

But, more important was the revelation that the Python class, despite being simpler and less protected (the fields are public!) than it’s Java counterpart, was still more flexible. The Python language allows for rapid prototyping by developing a simple class such as the Coordinate shown above, without worrying too much about adding protection and cleanly defined lines of separation. Yet, when a more robust interface is required it can be added without having to change any code that uses the class. So, what happens when someone comes along and tries something illegal, such as this:

location = Coordinate()
location.latitude = -93.9 # Souther than south!

Alright, admittedly this could be a problem. By encapsulating access to the longitude and latitude the problem is easily solved — but, in Java this introduces another problem. Any code that references these internal variables will need to be updated. It turns out that the best way to build good Java code is to build it right the first time.

The solution in Python is more agile. We can encapsulate after the fact, resulting in more rapid code prototyping but not preventing the development of a clean API at a later date:

class Coordinate(object):
def __init__(self, latitude=0.0, longitude=0.0):
self.latitude, self.longitude = latitude, longitude
def getLatitude(self):
return self.__latitude
def setLatitude(self, latitude):
if not -90.0 < = latitude <= 90.0:
raise ValueError('Bad latitude.')
self.__latitude = latitude
latitude = property(getLatitude, setLatitude)

The last line, latitude = property(getLatitude, setLatitude) establishes the latitude variable as a property of the class. As a property, the variable remains exposed but is now transparently managed by its getter and setter calls — this means that external code such as the erroneous example above will no longer allow the impossible:

location = Coordinate()
location.latitude = -93.9 # Souther than south!
Traceback (most recent call last):
File “”, line 1, in ?
File “types.py”, line 32, in __init__
File “types.py”, line 37, in setLatitude
ValueError: Bad latitude.

And yet, the API call itself did not change, so no client code has to be updated. Beforehand, the client code was accessing a latitude variable; after, it’s accessing a latitude property. Could this be done in Java? Well, the steps can be followed to add appropriate getters and setters but — the client code needs to be changed with the API change. This can lead to high-maintenance in comparison to Python’s lightweight, flexible and agile alternative.

I’m also impressed by Python’s very concise, well thought out syntax and library support. J2EE, in comparison, almost always seems to require dramatically more work to achieve the same result. For example, these few lines of code will open a file provided on the command line and read each line into an array, treating the values as floating point numbers, and finally print out the largest number read from the file:

import sys
f = open(sys.argv[1])
fvalues = [float(s) for s in f.readlines()]
f.close()
print “Max is ”, max(fvalues)

These are just a few of Python’s elegant language features — but it was enough to inspire a bit more research. Chiefly concerned that the language be up-to-par for enterprise development my research led to a few interesting Python projects. Google came right to the fore, of course, as did NASA (not to mention an excellent case study that enumerated all of the language features we wanted):

Another aspect of Python that Friedrich found eminently significant is its shallow learning curve. “We are always under the gun on software projects, like everyone else,” he says. “But for any programmer, picking up Python is a one-week deal because things just behave as you expect them to, so there’s less chasing your tail and far more productivity.” He contrasts that with C++ and Java, which he says takes a good programmer weeks to grasp and months to become proficient.

Seeing Python as the language behind Eve Online was certainly intriguing as well. With over 30,000 concurrent users at the time of this writing, EVE effectively demonstrates that Python’s got the chops to develop massively transactional, fault tolerant systems. If you’re looking for similar results take a close look at Python — it’s well worth the time.