Thoughts about the Best Introductory Language

Linda McIver published along with Damian Conway a paper titled "Seven Deadly Sins of Introductory Programming Language Design" that explains the problems they found with most popular introductory programming languages. The article makes a very good read.

Later on, her Ph.D. thesis introduced her idea of a good introductory programming language.

Now, if I had to summarise this language in one word it would be this: sexless. It's incredibly limited, not flexible, and not fun. It has no pointers or references and instead relies on nested structures and arrays. There are two basic data types - a number and a string. The language does not have functions as first-order objects, closures, or objects and classes in the Object Oriented Programming sense. Furthermore, it has very few ways for one to express oneself. As a result implementing many algorithms would be very difficult in it.

When I program, I'm using every tool in my arsenal, and expect the language to be powerful enough to be able to translate my thoughts into code. McIver's language is too limited and limiting, to be effective for programming in, and being planned exclusively for beginners, lacks the richness and interesting idioms that make programmers like or even love their languages.

This is a language that I won't enjoy programming in. And I don't believe a professor who doesn't enjoy programming in a certain language can effectively convey it to his students, while lacking the enthusiasm and love for the tool he chose.

McIver's approach is flawed in the sense that she is trying too hard to save the students from all possible problems they may encounter in trying to understand their introductory language. However, programming is hard to learn, and learning the first language is always difficult. Creating a "flawless" language that lacks any sex-appeal is not going to make it better, but much worse as both the professors and programmers will detest it.

"Structure and Interpretation of Computer Programs" (or SICP for short) is a classic text and course material on programming, taught at MIT and many other universities around the world. SICP uses Scheme (a minimalistic dialect of Lisp) as its exclusive language to cover many important programming and meta-programming concepts.

I have read the book in my third semester of the Technion (without doing the exercises) and later took both of the SICP courses that were given by my department. I learned a lot from the book, and while the courses did not renew too much, I did like working on the exercises.

However, there are several problems with teaching Scheme as an introductory language. The first is that it is too impractical. Scheme does not have system primitives that more modern languages take for granted like ones for random file and directory I/O, sockets, graphics primitives, Graphical User Interface (GUI), etc. Moreover, the core language is limited and most practical code tends to become very verbose in it. For example, whereas in Perl one would write $myarray[$i]++ to increment an array element by one, in Scheme it would be: (vector-set! myarray i (1+ (vector-ref myarray i))).

Most of the SICP exercises are about number theory, recursion, and a lot of other relatively abstract stuff, and too few are about real world and exciting tasks: writing games and other demos, working with files, writing scripts and utilities, networking and working with the WWW, etc. In fact, the Scheme standards define too few useful things. Most of the dazzling number of different Scheme implementations all extend the language in several ways, but all have their own idea of how to do it. Compare it to Perl, Python and friends which have one main C-based implementation, or to C where the standard library is actually quite useful.

I believe an introductory language has to grow with you. When I studied BASIC, I was able to use it for programming games, graphical demonstrations and animations, scripts, and other uses. I continued to use BASIC on DOS and Windows, until I learned the much-superior Perl, which I'm using today.

In his "Back to Basics" essay, Joel Spolsky gave a case for teaching ANSI C as an introductory language instead of more high level languages. His argument is that programmers will end up writing sub-optimal code because some low-level elements of dealing with strings and arrays are abstracted away in higher-level language.

ANSI C and C++ have been popular introductory languages for teaching programming for many years now. While some schools have switched to teaching Java or a different language, C and C++ are still very popular.

However, C has one major deficiency: it's too close to the processor to be useful. In order to perform an operation on two objects, one should allocate them first, perform the operation, and then take care of freeing both objects and the result (to say nothing of edge cases where allocating or freeing may fail.).

All this work to do something that in high level, garbage collected, languages is as simple as $result = $object1 OP $object2;. From my experience with Technion students, they are often get so bogged up in the technicalities of working with C instead of getting quick, dirty and useful code running.

A good introductory programming language should allow you to write a lot of useful code quickly, and not slow you down with many low-level constraints. Beginning programmers have a hard enough time learning how to translate their thoughts and intentions into working code, and solving bugs and the last thing they need is to deal with too many idiosyncrasies of the language only because it is too low-level.

Spolsky's argument about the efficiency of some operations is wrong, because programmers who learn such languages won't often notice the difference from such inefficient operations, due to the incredible speed of contemporary computers and the fact that their data sets are generally too small. Moreover, many instructors and exercise checkers won't penalise for the presence of such issues in their homework.

While the efficiency of algorithms and the underlying implementation of language primitives should be stressed at a certian point, the first task of an introductory course is to make sure a programmer can learn to write code, not necessarily the most efficient one. (Not even according to asymptotic complexity). Learning how to write quick and dirty code is a mental leap that is large enough as it is.

You many times hear people saying that beginning programmers should be taught using a programming language that restricts them and forces them to write good code. Languages like Pascal, Ada, Java, and many others were designed to try to save programmers from themselves. And indeed many people believe that programmers should start learning from such a language.

What's wrong with this approach? Several things:

Many education institutions reject many languages as introductory languages because they don't have a decent integrated development environment (or IDE for short). An IDE as useful and convenient as it is, however, is not an absolute requirement.

Programming does not happen in the IDE - it happens in the mind. Programmers should learn to write code that does something. By using the text editor (of the IDE or a standalone one) and writing text that does something, they can best learn to program for the real world.

There is a myth that programming using a text editor and a command line is too difficult for mortals. This is false because, as late as the 1980's or 1990's, almost all personal computers used a command-line interface (often a BASIC interpreter or DOS), and required programming using non-graphical editors, and it was still adequate for most people. (To say nothing of earlier interfaces such as Teleprinters (TTYs) or punched cards). Plus, it is hard for a programmer to avoid typing code entirely.

C should not be taught as a first programming language from the reasons I have mentioned above. By all means, one should use a more high level languages which supports Managed programming, and other nice high level constructs. Languages like Perl, Python, Ruby and to a lesser extent Java and .NET are much better than C as introductory languages.

Some people believe that PHP is a suitable introductory language. However, PHP has several major problems: lack of good abstraction mechanisms, many inconsistencies, many functions to do the same thing, and many nuances to its use. People who learn PHP right away, tend to write very bad (and sometimes very dangerous) code in it, and are not well-aware of its pitfalls.

PHP is a fine language for the web and for other uses, especially because its implementation makes deployment of some large-scale web applications easier. However, the other languages in the so-called "dynamic", "agile", or "scripting" class of languages are not harder to learn, and less problematic. So they should be taught first instead.

Some people believe that the first language a UNIX user should learn is a good shell (such as GNU Bash or zsh). However, Shell has some issues. The first is that the mentality of the UNIX Shell is different from the mentality of conventional programming languages, and causes native shell programmers to be less capable of adapting to a different language, as well as writing sub-optimal code in shell.

The second is that in traditional shell, some operations are not as efficient as they should be. While more modern variants have introduced arrays and string-wise dictionaries, they are still an afterthought. For these reasons, shell is not recommended to learn before a dynamic language.

It is certainly a good idea to learn Assembly language, preferably of several different processor architectures. However, C should be learnt first.

The reason for that is that people who dive right into Assembly, tend to write sub-optimal code because they don't understand well how this code is executed by the processor and how to compile it. This is while programmers who've learned C are better equipped to understand how Assembly code works, because it is somewhat more convenient yet still very close to Assembly.

A friend of mine reported that in his workplace, where they write Assembly code for various Digital Signal Processors (DSPs) some of the native Assembly programmers order their instructions in ways that are executed inefficiently because of the special processor pipeline. He then told me that C programmers who learn Assembly make better Assembly programmers.

A good first programming language should be practical and should grow up with you. I can tell from my experiences with the various BASICs, which were the first languages I learnd, that BASIC was fun because it was useful. Using BASIC on the old Intel-based computers, one could write games, graphical demos, text processing and command execution scripts, and even serious applications. While BASIC is in today's standards a very limited language that should no longer be taught as a first language, I still fondly remember it as being a lot of fun. I even continued using BASIC after I learned ANSI C and what was then C++, because it was quicker and more convenient. (I no longer do, because I now feel that Perl is superior to BASIC in every way, and that's what I'm using now.)

On the other hand, Scheme as in SICP is an awful choice for an introductory programming language, because it feels very impractical. Writing quick and dirty code to do a lot of things in Scheme is very verbose, and plus, the core standard lacks many primitives for common POSIX operations (like random file I/O, directories, sockets, etc.) much less useful APIs. While some Scheme implementations provide extensions to the language, they do so in different incompatible ways.

Different people I talked to, agreed with me that "You cannot do anything with Scheme". Compare it to languages such as C and C++, Perl/Python/Tcl/Ruby/PHP, Java/.NET, etc. that feel very practical, and you'll see why hardly any industrial-strength code is written in Scheme.

Teaching a language just for teaching programming with, is sub-optimal because the students cannot take this language with them and perform real-world tasks with it. They will have less motivation to experiment on their own, and to remember it for long.

The Wikipedia has an (incomplete) list of non-English based programming languages, that were created at some time. What these languages try to do is make sure young children or other people who did not master the English Alphabet and vocabulary well can start learning programming without knowing English first.

I see several problems with this approach. One is that it is important that children will be taught English starting from an early age - as early as possible. This is because English, being the international language, is becoming more and more important for every one to learn. Tender children who are talked to in severel languages, will quickly master them, without confusing them. This will save them a lot of frustration later. (By all means if one happens to know other languages, he should talk to his children using them too, but that is beside the main point.)

Knowledge of English is more important than knowing how to program. So it is a good idea that when teaching programming to teach English first as a necessary pre-requisite.

The other problem I see is that such localised programming languages feel unnatural and wrong. English has the richest technical vocabulary of any other language, and some terms in English are impossible to translate to other languages. And yet another is that such languages tend to be very ad-hoc and incomplete. Finally, code that is written in them cannot be understood by programmers who don't know this language.

So, to sum up, instead of starting with a localised programming language, teach your students some basic English first. It might take longer, but will save more time and frustation later on. Plus, programming is a great way to expand one's mastery of English, especially today when the Internet is so prevalent.^{[globalisation]}

Joel Spolsky wrote an essay titled "The Perils of JavaSchools" where he argued that teaching Java in Computer Science curriculums is inferior to teaching ANSI C and Scheme, which was what he learned. The article is wrong on many points, but it highlights some of the problems with Java.

Java is too verbose. Some people may argue that this can be solved by using a proper IDE, but as Paul Graham explains, verbose code also has the "the cost of reading it, and the cost of the space it takes up on your screen.".

Moreover, Java code tend to be very monotonous. Almost all Java code looks the same, and feels boring.

Steve Yegge's very funny article "Execution in the Kingdom of Nouns" illustrates another problem with Java. Everything has to be a noun, with no verbs or even the many keywords which Perl 5 is infamous for but which Perl programmers love. And instead of having some Perl 5-like operators for converting between data structures, you have a hideously long casting lines.

Java was supposed to be kept simple, and many important concepts like closures, multiple-inheritance, defining methods at runtime (a la Smalltalk), runtime code evalutation (the Lisp-derived "eval" operator, which is now common in most dynamic languages), operator overloading, and many other elements had been kept out of it. As such it turned out to be very unusable. Java 1.5/5.0 introduced many drastic enhancements, but not enough proper abstractions. As a result, Java is now bloated, but talented programmers still normally find writing code in Perl, Python and friends more natural.

Paul Graham's essay Java's Cover, which he wrote to explain why he decided not to learn Java is very instructive. I read Graham's article, some time after it has been written and felt it reflected my feelings about the language. Back when Java started to become hyped , I had ended up learning Java to see what the hype was about and to write some browser applets. While having felt that I have truly understood what the essence of references in Perl 5 was, only after learning Java, I still felt that Java was too over-rated.

Perhaps I'm getting too carried away in criticising Java. My point is that, as Joel Spolsky indicated in his "JavaSchools" essay, teaching Java as the first language, makes many of the people who have learned it airheads, who cannot think outside the limited constraints that it imposes on the programmer. Teaching an expressive and rich dynamic language such as Perl or Ruby instead, will not exhibit this problem, regardless of what Joel says, as these languages constantly require a programmer to think outside the box, and introduce the programmer to many different (often built-in) patterns and paradigms.

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 besides 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]}.

This is a quote attributed to Gandhi. The "Learn like you were going to live forever" part is not widely understood by many workers. Many programmers believe that their knowledge of a few programming languages is enough, and that it is not necessary that they learn completely different ones.

It is well known that learning a new and different programming language will make you a better programmer also in the original languages you know. Programmers who don't learn new programming languages eventually stagnate. They are bounded by their limited knowledge, and cannot think outside their box. They deserve the stagnation they receive due to this bad attitude, and mental laziness.

If you want to grow as a programmer, make sure you keep studying new languages and technologies. Not only they may turn out to be useful, but they'll also make you think in completely different ways.

Rabbi Hanina used to say "I learned a lot from my teachers, and from my friends more than my teachers, and from my pupils the most." I believe this means that there are in fact three levels of learning:

Perhaps there's a fourth level - Science in which the knowledge is expanded. However, this implies that to truly understand the material, one needs to experiment with it (preferably in production) and better yet teach it to someone else.

The old adage "He who can - does. He who cannot - teaches." which was said by George Bernard Shaw is amusing, but simply not true, as I've demonstrated here. Being a great teacher is much more difficult than being a great doer, and is much more enlightening. ^{[those_who_can]}

Learning one computer language is not enough. Knowledge of only one computer language or a few cripples the mind and causes the brain to run in circles. Different programming languages introduce different insights: various easier ways to do certain things, different restrictions , different syntax, different APIs, different ways of doing things, different high-level mechanisms (or lack of them). All of this gives different understandings of how to program in any language.

Many people believe that their limited knowledge is adequate. Java programmers are especially notorious for being opposed to the ideas of them having to learn different languages. The Pragmatic Programmer book says a programmer should learn a new computer language at least every year, and I tend to agree with it. I compiled a tenative list of the technologies I found the most enlightening, and I recommend programmers to learn at least all of them.

At present, universities and other spend most time teaching programmers how to write code. However, most of what programmers have to do for work or for pro-bono work (like open source projects) is to read code, and to enhance existing code.

Joel Spolsky ("Joel on Software") gave the following "cardinal rule of programming" in his famous "Things you must never do, part I" essay:

My friends and I later discussed this topic in the Hackers-IL mailing list. Even if code is given for reading in university, it is usually extremely well-written, highly organised, highly legible, code, rather than the real code that programmers are likely to encounter in the wild.

It's a shame most of the code students write as part of their curriculum is only for themselves, and ends up being of little value to the world at large. Even if some code ends up as an open source project, it is usually too incomplete and lacks essential functionality or correctness to be of any use in the real world.

As Joel points out in the article, most programmers end up saying that the code they are working on is horrible and that they wish to completely rewrite it if they have the chance, instead of refactoring it to make it better.

Furthermore, since reading code is harder than writing it, then it makes sense that programmers who are good at reading (or refactoring code or enhancing it) are much better programmers, than programmers who are only good at writing new code. I wish I had a dollar for everytime I heard of someone trying to rewrite an existing functional and relativley bug-free codebase from scratch, just because this codebase was deemed of too little quality, and that afterwards this rewrite ended up at nothing. These cases practically dwarf the number of successful rewrites I recall.

To sum up, it will be a good idea to teach first-time programmers how to read real-world code, or the code written by their co-students, and how to enhance it by extending it, and cleaning it up.