When reading programs in today's popular programming languages, I often find myself wondering if all this code is really needed. Is is still so combersome to tell the computer what to do? Do we have to code thousands of lines just to explain the system how to get some data from there, transform it a little bit, and present it to user in a nice way? You may answer that modern development environments take a lot of this burden of the programmer by generating the code (MDA being the culmination of this idea), but doesn't this mean that we could express the instructions in a better way to begin with?
These thoughts spurred my interest in programming languages. It looks like there are plenty of ideas which could help to improve the way we talk to a computer. But most of this knowledge stays within the academic circles where these languages have been developed. If you want to learn multiple programming languages, you have to read a lot of books, since most of them focus on a single language. For popular languages such as Java and C#, you can actually buy dozens if not hundreds of books covering the different aspects of these languages.
This book tries to explain a number of programming languages, covering a wide range from currently popular ones such as Java, Perl, Python, and C# to less known languages such as ML, Haskell. There is one key requirement: the language has to be available for free (or otherwise I could not afford writing this book). We don't expect a full blown IDE; a good set of command line tools is just as fine. Fortunately, this requirement is fulfilled by most languages these days, since they don't stand a chance otherwise. In many cases, even a free IDE is available (e.g., Eclipse for Java or Smalltalk/X).
When describing the languages, I want to find out what they have in common, and what distinguished them from each over. The presentation shows my own programming language background: I started with Pascal and Modula 2 before switching to C/C++ and finally moving to Java web development. In parallel to C++, I started using Python for scripting and some small applications. If you have a similar background, you will probably find it very easy to follow the text. Otherwise, you might want to read some of the references in parallel.
As a programmer, I find small examples more instructive than lengthy explanations. As as result, you find many small code examples -- there may be more code than explaining text in this book -- each covering a small piece of the language. Most of the languages in this book offer an interactive environment where you can enter expressions and directly see the results. This way you can type the examples, compare the outcome, and experiment yourself.
Another choice I had to make was the kind of development environment for each language. All of them provide a set of command line tools, and most of them also offer an integrated development environment which nice features such as syntax highlighting, code/class browser, debugger, and so forth. I decided to stick to the command line (or a general purpose text editor such as Emacs), because it is a lot more efficient (in terms of time an space) to paste code examples into the text than to deal with a multitude of screenshots.
The book focuses on the languages themselves rather than their libraries, history, or different versions. For the curious, I will add a few notes about the origin of the language, but mostly refer to other resources for more detailed information.
After trying multiple ways to organize the chapters I decided to order the languages more or less chronologically using the year when a language first appeared "in public". However, I do not guarantee correctness, since this year is sometimes not easy to determine.
As a result of the chronological order, you will find completely different programming paradigms right next to each other. The 1970s, for example, saw the parallel rise of object-oriented (Smalltalk), logical (Prolog), functional (Scheme), data-driven (SQL) languages.
There are many ways to read this book. I believe that it is short enough to be read cover to cover, let's say, one language per subway trip. Just reading the quick tours is probably enough to make intelligent remarks to your collegues ("If we were coding it in XXX, we could do it in two lines"). Most chapters can be read independently of each other. Even for languages that have a lot in common (in particular Lisp/Scheme and SML/Ocaml), it turned out to be easier to start from scratch than to describe one in terms of the other. The main exception is the C family which is best understood as a progression from C to C++ (and Objective C) to Java to C#.
Being an amateur for most of the languages covered in this book, I rely on the help of others to correct the most blatant mistakes. Fortunately, many of my collegues at AMS and Vodafone read individual chapters and provided me with valuable feedback. Our Perl master Alexander Brueck helped to get the Perl chapter in shape. Carten Bucker reviewed to Smalltalk chapter (neither of us is a Smalltalk expert, but hopefully two one-eyed can get around the worst pitfalls). Volker Garske carefully reviewed the C chapter.