What defines the ultimate development language?

The Criterion

The criterion I use to judge a language is, "What will get the results I want in the shortest amount of time". This is one of those forehead-slappingly obvious statements, at least in hindsight.

There are a number of factors involved in getting results quickly that should be considered when choosing a programming language:

• How soon will I be able to make effective use of the language and libraries? (learning curve)
• How much existing code is there that helps me do what what I want? (libraries)
• How expressive is the language itself? (syntax, semantics, and data)

Learning Curve

The Language

Many people would analyse the learning curve of the language itself by asking "How many unfamiliar concepts are present in the programming language" (ie. is it object-oriented; this would be a positive or negative depending on whether you already understood object-oriented programming).

That question has merits, but a better question is "How many unfamiliar concepts am I required to understand to get started with the language". This is where a language like Perl shines; while many of the concepts of functional and object-oriented programming are available as features, as a general rule, you don't need to understand any of these things to get started.

If you were writing something achieveable in a perl one-liner, it might be that you could learn an appropriate amount of Perl and complete the one-liner more quickly than you could write the whole thing in C. On the other hand, there are certainly C programs that can be written in less time than it takes to learn the appropriate Perl and code that. Now imagine trying to go from C to Lisp; you need a lot more new concepts to be able to achieve anything in Lisp.

On the other hand, for a large project, it's worth learning a new language if it will be more effective. This is not in spite of the new concepts, but because of them. A story is told of an FORTRAN student who wrote a program whose runtime was going to be something like 120 years. A student using APL wrote a program that would run much more quickly. This was because APL makes it very easy to sort data, and so he sorted the data before taking the requisite actions on it, which in this case resulted in a much quicker processing speed.

The Libraries

Even a highly expressive language can be a pain if there are no libraries for it. If something much more primitive with thousands or millions of libraries (eg. C) can achieve the results much more quickly, then it's often a better choice.

There are a number of factors in the usefulness of libraries:

• How easy are they to find? (ie. "Where do I find an IMAP library for C)
• How easy are they to choose? (ie. Should I use XML::XPath or XML::LibXML or...)
• How easy are they to install?
• Do they do what I want?

One of Perl's secret weapons is CPAN [9], the website that contains most of the Perl libraries in the world. This solves points 1 and 3 above. Of course, CPAN could be easier to use (if it were more like Sourceforge [10]), but it's a lot better than what previous programming languages had.

PHP takes a different approach. They bundle everything with PHP, all in the one distribution. This solves points 1-3, but is not very scalable; imagine distributing the whole of CPAN with every copy of Perl.

Point 4, of course, depends on the library developers.

The Goals

The Language Goal

Imagine if you could call libraries written in other programming languages? I'm not talking here about someone writing a library interface layer, as often happens now when eg. calling C libraries from Perl, but of any library in another language working seamlessly with yours, out of the box.

Now, imagine that you could write part of your program in one language, and the rest in another language.

These are things that should be more possible with virtual machines. The Parrot virtual machine (which is being written by the Perl6 team) is intended to help both of these to happen, as it's one of the things that Perl 6 is going to want to use.

I can hear some people switching off already. Note that I'm not saying here that everyone (or even most) should use Perl 6 (although I admit I like the idea :) ); I'm saying that any language which in future runs on the Parrot virtual machine will be able to add functionality like this. So if you're programming in PHP-on-Parrot, but feel like doing coroutines, you can embed some Ruby (on Parrot, of course) in your PHP.

Or, if you're feeling really funky, you should be able to embed some XPath [11] in your Perl6. Or evaluate your Python array as though it were a set of spreadsheet cells. Or make some quick changes to a file using the Editfiles [12] language borrowed from Cfengine [13]. You could even write a program in a mix of LISP [14], APL [15], and table-oriented programming [16].

The Library Goal

Of course, the immediate result of all this is that suddenly, there will be many libraries all doing the same thing. For example, there are already 2 Perl libraries for doing IMAP. If everyone were using Parrot, you'd also be able to use the PHP IMAP library, the Python IMAP library, and Ruby's Net::IMAP library. But from a library user's point of view, you don't care much which one it is, as long as it gets the job done.

I would hope that in future CPAN would be the Comprehensive Parrot Archive Network, and that you might be able to use libraries written in two or three different languages in your program, so that people don't have to keep reinventing the wheel in different languages; if the Perl XML modules are inadequate, just use the Python ones.

Also, as there will hopefully be fewer competing options (ie. eventually one IMAP implementation may become the only maintained one), each option will have more people using it, and will thus be more thoroughly bug tested, and hopefully have fewer bugs.

Hopefully also the languages would allow (as Perl6 and Java do) the separation of interface and implementation. When this happens, an ideal which might be interesting is a windowing system which works the same either natively or via AJAX.

Conclusion

Any Ultimate Development Workstation is useless if you can't actually develop stuff on it. The programming language you choose, and the libraries that it can access are crucial parts of the Ultimate Development Workstation. The underlying infrastructure for such an environment is being created by the Parrot Development Team.