What Perl, Python, and Java need to learn from C

Perl sucks. I love writing Perl code, but I can't even begin to contemplate shipping a production application based on it, because I can't rely on anybody else in the world having the same Perl environment as the one on my particular machine. The Perl module system needs to be seriously rethought. No, I don't want to upgrade to a newer version of a particular module because I don't know what other code I might have on my system that could be dependent on it, and could break. And damn, now I have been forced to upgraded the module, I find that the breakage wasn't even caused by a bug. The interface has changed, some other module I used to use doesn't work any longer, and nobody has even written a replacement.

No, I don't want to upgrade to a newer release of Python, to run your app, unless before doing so you are willing to sign something promising me that there isn't any way that any of my other applications could possibly break.

No, I don't want to install a Java runtime. My system already has one installed, thank you. Use it. If it is broken, file a bug, and work with the distributor to come up with a patch, or minor version upgrade, that I can apply. They can't do that? You have to install a whole new runtime? Why?

I hate C. Programming in C is so tedious, but it is still the best choice for writing robust portable software. I can rely on a program I write in C today, still running on my Linux box in 10 years, even without needing to be recompiled. This isn't a property of the C language. This is a property of C implementations, in particular the dynamic library system. If other language implementations copied this, we could get rid of C, and I am sure there would be a lot more reliable robust software getting written Python, Perl, and Java.

The more the industry changes, the more it stays the same. I remember back when dynamic libraries where first starting to become in vogue on Unix. At first there were all sorts of reliability problems, and vendors would ship static binaries to try and avoid them. Eventually people figured out a common framework, and some pretty strict rules to make the system work.

These are the consensus rules that evolved around C application and run time library development, but which Perl, Python, and Java are still missing:

• multiple versions of libraries/modules/packages:
  • different versions of libraries/modules/packages need to be able to coexist on a system, not replace each other
  • libraries/modules/packages have a major and a minor version number: major version numbers are allowed to introduce interface changes; minor version numbers must not change the interface; minor version numbers are conservative changes only used for fixing bugs and additional functionality
  • anything that uses a library/module/package specifies the major version number it requires and the minimum minor version number it was built and tested against
• developing, building, and testing:
  • developers should not always be running on the latest and greatest; a mixture of old and new systems is probably best
  • build and package functionality must take place on the oldest platform any of your potential customers are using; otherwise you are potentially forcing them to have to upgrade
  • the library version that should be used becomes bound to the application at build time
  • testing should take place on both old and new platforms; you should test the shit out of every minor library/module/package version upgrade; both by running comprehensive test suites and by running every application you know of that uses your library/module/package
• slow things down:
  • upgrades introduce bugs so if it isn't broken don't fix it
  • stabilize and freeze interfaces as quickly as feasible; interfaces are not a place for innovation or making things better
  • stabilize libraries/modules/packages; primarily see them as places to fix bugs; innovation should be pushed to applications
  • an application should not provide third party interfaces unless they are willing to conform to the slower innovation and development goals applied to libraries/modules/packages
  • support any major version shipped for a minimum of 10 years

Following these rules is the reason all of the system software on your machine that was written in C some 10 or more years ago still works today, and why you can still count on it to work in the future, long after any of the more recent code has stopped running, or needs upgrading.

This isn't sexy stuff, but it is key to making languages useful. Implementation matters far more than innovation. C gets this. Current Perl, Python, and Java implementations do not. A pity, since it doesn't seem very difficult to provide, and would make a big difference in usability. Perl allows applications to specify which module versions they require at build time, but then screws up by not allowing multiple module versions to co-exist at run time.

This isn't even something C implementations invented with their dynamic libraries in the late 1980's. Dynamic binding was considered a bad idea probably as far back as the 1960's, so why do Perl, Python, and Java still rely on it for their runtimes?

Towards a solution:

• only.pm - allows multiple versions of Perl modules to be concurrently installed and for applications to specify the minimum version number they require
• PAR (Perl Archive Toolkit) - makes it possible for developers to combine multiple Perl libraries down to a single simple stand alone binary for distribution