According to these constraints one can conclude that one should start learning how to program from a high-level, dynamic and practical language such as Perl, Python or Ruby.
Eric Raymond recommends this in his excellent “How to become a Hacker” document. He suggests one should start with XHTML, which while not being a programming language but rather a formatting language will still introduce many programming idioms and disciplines as well as prove useful later on.
After XHTML, Raymond recommends one to learn Python. However, I’m not sure whether Perl 5 or Ruby will not be as suitable as Python, or more. Unfortunately, I cannot reach a conclusion here, but rather give some of my thoughts on each three languages.
(If I need to teach programming, I’ll start with Perl because I know it very well, and like it a lot. However, programmers who are well versed in Python or Ruby, may wish to teach them instead.)
The core Perl language is huge. That may be a good or a bad thing for teaching programming in. The Perl language can be usable by learning only a small subset of the language. However, as budding Perl programmers learn more they tend to diverge in the what they know, and use different subsets, which makes understanding code of peers with different background (much less experts) more problematic. This problem is naturally not limited to Perl 5, and given good, searchable documentation can be made less substantial, but is still a pedagogical hurdle.
Perl is very expressive. I believe programmers will appreciate its “There is more than one way to do it” philosophy. A correspondent once told me he’d prefer to teach beginners Perl instead of C, similarly to the fact that he’d prefer to teach English over Esperanto, because beginners would prefer a language that allows them to express themselves. [Esperanto]
Historically, Perl had a lack of good online documentation for beginners, and other problems with the treatment of newcomers, but this has improved lately.
Perl has a rich (and so far unmatched) collection of re-usable modules that provide functionality called CPAN - the Comprehensive Perl Archive Network. Uploads to CPAN are not moderated (on purpose) and therefore it is sometimes hard to find a suitable CPAN module out of the many bad or unsuitable ones (if there actually is one available). [rethinking-cpan] They may prove useful in teaching programming in Perl.
Perl has a rich and active culture surrounding it, including many diversions as obfuscated code, golf challenges, riddles, many specialised mailing lists, Local Perl Mongers groups, and conferences.
Python has a small core language and it tries to be elegant. It has an excellent online documentation, and many introductory books for it are available online. The online Python community has too much elitism, and tends to deprecate Perl a lot, for some reason. I am not blaming anyone in particular, but this tendency is present to some extent by some of the greatest names in the Python world, and by some Pythoneers I personally know.
People who know Perl very well, can learn Python with fewer mental blocks than the other way around. This is in due to the fact Perl is richer, and supports more paradigms. A Perl programmer told me he was able to start working on a Python program right after starting to edit it using his editor, and it worked, after some research.
Python’s philosophy is “There’s one good way to do it.”. It doesn’t mean that there aren’t other ways, but there is one commonly acceptable way to write most code. Whether this is a good thing or not for an introductory language is debatable.
If PHP is the new Visual Basic, and Java is the new COBOL, then Python is the new Pascal. (Although, all these languages are better than their previous ones). In a way teaching Python as a first language, like teaching Pascal, makes a programmer used to limited paradigms and one strict way of doing things. (like teaching Esperanto instead of English). As a result, trying to learn other diverse languages is becoming more difficult.
If you’ve learned Python as your mother language, you should take the mental leap and learn Perl, which is the Tower of Babel of languages, and also has many DWIMmeries (“Do-What-I-Mean”’s) and other expressiveness. (Of course, a Perl programmer should also learn Python due to its elegance, and the fact it is extensively used and useful.)
Before I discuss Ruby a word of warning: I don’t know it very well. So far all the limited tasks I tried to accomplish using it worked well after some trial and error, but I still did not take the time to thoroughly study it.
Ruby was written after its creator was unhappy to some extent with both Perl (possibly 4 at the time) and Python, and so he created a language that tried to combine the best elements of Smalltalk, Perl and Python. Ruby aims to be elegant and consistent, yet still very expressive and shares Perl’s “There’s more than one way to do it” philosophy.
As of version 1.x, Ruby does not support multi-threaded programming, has poor support for Unicode, and is much slower than Perl or Python. Some of these problems will be addressed in Ruby 2.x.
The worst problem with Ruby, however, is the lack of good documentation. Ruby has one old edition of the “Programming Ruby” book available online, and that’s it. Furthermore, this book is intended for absolute beginners and will be too slow paced for people with extensive experience in similar languages.
All the other books from the Pragmatic Programmer series are not available online (including the new editions of the “Programming Ruby” book). What many people end up doing is downloading them from “warez” sites or from Peer-to-Peer networks, but I wouldn’t encourage professors to tell their students to do that.
I recall trying to find out how to tag methods in Ruby, in a similar way to Perl’s method or variable attributes. Google was no help and no one on Freenode on #ruby-lang told me and I asked several times, and people tried to research it. Eventually, someone I knew on #perl was able to give me the answer. He then claimed that many of the slightly more unconventional, but useful, tricks in Ruby were completely undocumented.
As such, one may still encounter problems teaching Ruby as an introductory language. If these problems are remedied by the Ruby community, with some amount of work and effort, then this may be better.
All things considered, I’d say that Perl is the best choice now, as Python is too strict and unexpressive, and Ruby is documented in an extremely inadequate way. Again, any of the three languages would be a fine choice, and all of them should be learned by any programmer who is worth his weight in salt.
Note that other than the main players in the dynamic language arena, there is the new crop of such languages: Lua, Io, The D Programming Language, and others. These languages may be more suitable in some respects, but on the other hand, may not yet have the brain-share, comprehensiveness (especially as far as APIs are concerned), usability, richness or “sex-appeal” [consistency].
[Esperanto] Several people contacted me saying I have misrepresented Esperanto here. I should note that I’m quoting someone else, and I admit that I don’t know Esperanto well enough to be sure if it indeed suffers from many problems attributed to artificial languages.
The point is not to dismiss Esperanto, but rather to say that many people appreciate expressibility, and some of them also appreciate irregularity (or even inconsistency) in their spoken or programming languages, as it makes life more interesting.
[rethinking-cpan] As of April, 2008, there is an effort under-way to revamp the CPAN experience. The author of these lines is heavily involved with it, so he may be a bit biased. Plus, the effort is still in its infancy.
[consistency] Some people assume that the more consistent a language is the better. However, just as most people prefer expressive and inconsistent natural human languages like English, many of them would prefer their programming language to have some inconsistencies, Do-what-I-mean-erries, gotchas, etc. In Perl 5’s case it is well known that these make the language more expressive and succinct in the hands of a competent programmer.