Introduction

I have worked with many different programming languages throughout the years, and here are some personal comments about them. To me, the feel of each language is important, as it makes a great difference to the interest and enthusiasm I can bring to using them. The most important aspect is expressiveness. I want to be able to implement an idea in as few lines of code as possible, consistent with clarity of expression. There are languages that go too far in one direction or another. As two extremes, COBOL is dreadfully verbose, taking many lines - long ones too - to implement quite simple algorithms. At the other end of the scale comes FORTH, which combines great compactness with a considerable elegance. But is seems to be a "write only" language - other people's code is very difficult to understand, unless they took great care to make it comprehensible.

Several of the languages are called modern "scripting" languages, although I have little idea what is meant by a scripting language these days. It used to be that they were interpreted at execution time, and were thus significantly slower than "real" compiled languages such as C and Fortran. But the distinction has become much weaker now that just-in-time compilation is available for most of the scripting languages.

The major scripting languages (Perl, Python, TCL and Ruby) all provide four very powerful facilities that make it much easier to write complex logic in relatively few lines of code. They are as follows:

I will list the languages roughly in the order which I prefer to use them - with the favourite first, just to be clear which I prefer.

PERL

Perl is a progamming language designed and written by an expert programmer (Larry Wall) for writing programs quickly and efficiently. It can be either criticised or praised for one of its main characteristics; there are many ways to accomplish the same goal, and there are many idiosyncracies - clever ways to do things that normal people probably wouldn't think of.

It is an interpreted language, which means that the performance may not be so good as a compiled language, but any loss in this respect is compensated for by the ability to create and execute code "on the fly".

Perl has an object-oriented extension that was added to it late in its design history.

TCL and TK

For two or three years, TCL was my favourite, as it was the first modern scripting language I made a serious attempt at learning. The TK extension, which makes it very easy to build complex graphical user interfaces for the first time, was a major attraction. This extension was so good that it has now been ported to several other languages, including Perl, Python and Ruby. TCL is slower and more verbose than Perl, and I now use it less frequently. Most of the new code I write at home is in Perl these days. TCL's main advantage is that it is a very simple, regular language, with a syntax that is easy to understand.

TCL has an object-oriented extension called "INCR TCL". The name is clever; it is a play on words with C++. Why? C++, in the C language, means "add one to the variable 'C'". "Incr TCL" means much the same thing in that language.

Python

Python is another modern scripting language, with a "cleaner" design than Perl. It is quite unusual in the way it defines blocks of code. Most other languages use some kind of bracket for marking the beginning and end of a block, but Python uses indentation. Most people either love it or hate it. To some it seems a revelation, a simplification that has been needed for a long while. To others, it is simplistic and juvenile. I am not sure yet which category I fall in to. I haven't written much Python yet, but plan to do so in time.

Ruby

Ruby, to me, has some similarities to Python, but is in fact a lot more sophisticated. It is the only one of the four modern scripting languages above that is fully object-oriented. Python is quite good in this respect, but the object-oriented features in Perl were obviously grafted on when the language was otherwise fairly complete. If you want a fully object-oriented scripting language, Ruby is an excellent choice.

Both Ruby and Python have interfaces to the Tk package, making it easy to build graphical user interfaces quickly.

The more I read about Ruby, the more I think it is much more interesting than it appears at first sight. I will have to try writing something of more substance than I have attempted so far.

C and C++

It is amazing that C has been so successful, considering that it is a very low level and quite primitive language. This is not intended as any criticism of the authors, who implemented on machines which are tiny by today's standards. But its lack of proper string variables has generated an enormous amount of work for countless programmers over the years. There are many features that seem primitive compared to contemporary languages such as Pascal, and it was in some respects a step back from Algol 60. I was amazed to find that it did not permit functions within functions, to an arbitrary depth.

It was successful because a free, or very affordable, compilers appeared before they did for other languages. Now it is thoroughly entrenched as the language of choice for maximising performance, and has thus been used for much critical software, including several major operating systems. Despite its weaknesses, it has easily stood the test of time.

C++ is another story. A kludge designed to strengthen a weak language, and paste object-oriented features on top to satisfy the theoreticians. Stream I/O functions that annoy more than they help. A new, complex, standard template library that is an excellent idea, but that few seem to understand or use.

Despite all my adverse comments, this language (or these languages) are the tool to use for maximum performance. They are immensely helped by the GNU compiler; a superb piece of software which is a great gift to the world, and which is responsible, more than any other thing, for the proliferation of free software.

Visual Basic

This language, unlike all those before, is proprietary to Microsoft. I use it exclusively at work, and find it limited and rather uninteresting. You can build graphical interfaces very quickly and intuitively, and it was a pioneer in this field. A downside is that new versions tend to "break" old code, and it is necessary to continually maintain programs to keep them working with the latest version of Visual Basic. This is in sharp contrast to, for example, C and C++, where code written many years ago will usually work with no problems.

Java

I will break ranks here with political correctness, and say at once that I really dislike Java. It seems to combine the rigour and need for attention to detail of C++ with the performance of scripting languages. In short, the worst of each world. If I am going to take the trouble to write something in Java, I may as well take a little extra time, write it in C++, and get the best possible performance for my effort. If I want to get it done more quickly, and don't care about speed so much, then Perl offers a much better collection of built-in tools (hashes and regular expressions just to start).

Building graphical user interfaces is painful, unless one uses a complex proprietary IDE. The layout managers are hard to use, and TK offers a much more programmer-friendly method of building them.

Smalltalk

I haven't written anything in this language for several years, and doubt I will try it again any time soon. It is the first language to be fully object-oriented, and was the birthplace of many ideas in programming languages.

I find it quite hard to read Smalltalk code. Everything is broken up into short methods that call one another, and the logic seems therefore to be buried in a nest of Russian dolls. You finally open the smallest one, and find it is empty. All the logic is in how the methods call one another.

Pascal

This is another block-structured language that descends directly from Algol 60. I used the UCSD P-system on an Apple 3 many years ago, and later used Borland's excellent Turbo Pascal for several years, in the early days of the IBM PC. This was in the days when the machine I used (a Compaq portable) did not have a hard disk at all; one relied on two 5.25 floppy diskettes.

The language is quite effective, but has some serious deficiencies in handling arrays where the size is not known until run-time.

FORTH

I went through a period in the early days of personal computers where I was completely fascinated by FORTH. It is a stack-based language, not at all unlike the assembler language for the KDF9, which I have described on another page. But it has two disadvantages - it is very low-level, and code is very difficult to read. This is because each defined word in the language can add or remove an arbitrary number of parameters from the stack. So if you don't know what a particular word does, the contents of the stack is impossible to track in your mind.

Bottom line - the idea is great, but it is impractical for real use in these days of free compilers and interpreters for languages where the code can be far more intelligible.

PL/1

This was the most commonly used language for the IBM mainframe at my place of employment for many years. (In fact, it still is, but I don't write mainframe code any longer). It seems a bit primitive now, but it was responsible for bringing many good ideas to the world og programming languages. It is similar to both Pascal and C, and is an obvious descendant of Algol 60, after receiving the attentions of a no-doubt well-meaning committee.

Algol 60

This was my first 'real' computer language, and it introduced many of the ideas we all take for granted in the many languages that are descended from it. These include all the ones listed above, with the exception of FORTH, and the possible exception of Smalltalk. It inherited some ideas from Fortran, but it was the first language with a well-defined block structure, and with local variables, and with a good parameter-passing mechanism for subroutines. It implemented call-by-name and call-by-value parameters properly. It had static variables, and a full complement of control structures. It missed out on character string variables almost entirely. If it had been revised to include these, it would have had a much longer lifetime, and there would have been no real need for Pascal, C, PL/1 and many others. The digression into Algol 68 killed it - a classic example of death by committee design.

I used Algol 60 in 1963-1968, while working for English Electric at Whetstone, just outside Leicester, England. There were two compilers at the time; a fast-to-compile-but-slow-at-runtime version known as the Whetstone compiler, and a slow-to-compile-but-fast-at-runtime version known as the Kidsgrove compiler. One used the former for development and debugging, the latter for production runs.


Last updated : 2004-10-31