Wednesday, March 30, 2005

A problem with Python

Ian Bicking wrote a passionate post where he encourages community to put more efforts into Python-for-web-application domain.

I have another complain about the Python (both for language itself and tools and libraries around it). Here it is: Python cannot fully utilize hardware resources. You see, I have several [web] programs running on my machine, some in Java and some in Python. Some of these are the apps I'm writing and debugging myself, some are third-party.

When I'm working on Java app, I have some serious stuff loaded: Eclipse IDE, Tomcat web server, database server, Firefox with API documentation opened, etc. Basically, you need 1Gb of RAM to have it all work smoothly. And even then it takes 12 seconds to redeploy an application. And we all know Java technology has sophisticated JIT compilers which means execution speed is much higher compared to Python.

What do we see in Python? Instance of Vim editor, WebKit/Apache server, may be a Firefox running and a database. That's all. How much resources does it take? Nothing. How long does it take to redeploy a WebKit application? Nothing again. In fact, you could develop Python app on some archaic Celeron-666/256 Mb box and notice little difference with modern Athlon 2800+/1Gb. At least, that was my experience.

What the heck?

If the language can't make a serious load out of modern hardware it can't be nothing else then a toy language, right? Programming is hard and it must feel that way.

Therefore, I ask the community to put more efforts to "grow" both the language and the tools. The day I see my python application deployed in a 12 seconds to a WSGI-backed WebKit I know: we have a serious, mature language. No, not a "language" - it'd be called a "platform" by then. Definitely.

A problem with Python

Ian Bicking wrote a passionate post where he encourages community to put more efforts into Python-for-web-application domain.

I have another complain about the Python (both for language itself and tools and libraries around it). Here it is: Python cannot fully utilize hardware resources. You see, I have several [web] programs running on my machine, some in Java and some in Python. Some of these are the apps I'm writing and debugging myself, some are third-party.

When I'm working on Java app, I have some serious stuff loaded: Eclipse IDE, Tomcat web server, database server, Firefox with API documentation opened, etc. Basically, you need 1Gb of RAM to have it all work smoothly. And even then it takes 12 seconds to redeploy an application. And we all know Java technology has sophisticated JIT compilers which means execution speed is much higher compared to Python.

What do we see in Python? Instance of Vim editor, WebKit/Apache server, may be a Firefox running, a shell. That's all. How much resources does it take? Nothing. How long does it take to redeploy a WebKit application? Nothing again. In fact, you could develop Python app on some archaic Celeron-666/256 Mb box and notice little difference with modern Athlon 2800+/1Gb. At least, that was my experience.

What the heck?

If the language can't make a serious load out of modern hardware it can't be nothing else then a toy language, right? Programming is hard and it must feel that way.

Therefore, I ask the community to put more efforts to "grow" both the language and the tools. The day I see my python application deployed in a 12 seconds to a WSGI-backed WebKit I know: we have a serious, mature language. No, not a "language" - it'd be called a "platform" by then. Definitely.

Friday, March 25, 2005

webfixture revised

There was some interested in my webfixture project so I decided to bite the bullet and pulled it online. See repository and project page.

Tuesday, March 15, 2005

Software, process and people

A recent article on FastCompany site tells a story about software engineers at NASA that write software for space modules and other such stuff. The story is entertaining and instructive but what I find naive is the idea that engineering approach used for this kind of projects at NASA could (and should!) be transferred to other kind of projects.

First, who writes it?
That's the culture: the on-board shuttle group produces grown-up software, and the way they do it is by being grown-ups. It may not be sexy, it may not be a coding ego- trip -- but it is the future of software.
It's a bit of a stretch, but I mostly agree here. To create a good software you need professionals. Software production is a complex activity and experience is a key. It doesn't really matter whether you look "sexy" or not and whether you have a spouse and kids. Of course, experience takes time and thus experienced programmers tend to be older and as such, may no longer care much about the "cool outfit" but care more about the family.

Next question: "how do they write the right stuff"?
The answer is, it's the process. The group's most important creation is not the perfect software they write -- it's the process they invented that writes the perfect software.
Yeah, I agree on this but I suspect for a different reason than original authors. Here is another quote which clarifies their reasoning:
The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering.
I think they are putting the cart before the horse. They succeed not because of the process per se but because the process was a good fit and probably was invented to match the kind of projects they are working on. And of course, no process would help if the execution is flawed. Attempting to copy the process to different project may lead to Cargo Cult Engineering, masterfully described by Steve McConnell in his Professional Software Development book.

Even more important and fundamental point - "expensiveness" of this kind of approach. The hard truth is that process above is not viable for a mainstream world of the software development. For a one, you can't really fix the requirements. And those who think they can often find themselves out of business. And another one - the process must be cost-effective which means finite resources and trade-offs and compromises.

I do believe we (industry) have a long way toward skillful software development and I'm looking for improvements that advances SWEBOK, but thinking that following NASA processes may give that to us is lame.

Well, this post is probably somewhat lame itself, as I'm not an expert either. ;-)