Classic Computer Magazine Archive START VOL. 1 NO. 3 / WINTER 1986


Tower of Babel
Pick a Language, Any Language...


Bill Wilkinson, renowned Atari guru and computer language maven, opines over ADA, BASIC, COBAL, Forth, Fortran, assembly and much much more. Looking for a language? Ask the man who speaks in tongues.

For those of us who have been accustomed to the Atari 8-bit world, the array of computer languages already available for the Atari ST computers is staggering. With promises of even more languages soon, how can you decide which one to use?

In this article I will tell you what I think are the advantages and disadvantages of some of the available ST languages. Note carefully that I said"... what I think..." Almost every programmer has a favorite language, and thinks that every other language is either fascist, anarchistic, unstructured, strait-jacketed, backwards, sluggish, or stupid, depending on which language is being described by which fanatic.

When the editors of START asked me to write this article I hesitated. After all, I am associated with Optimized Systems Software (OSS), producers of one of the more prominent languages for the ST (Personal Pascal), and soon to offer perhaps the most esoteric language (Personal Prolog). I feared that any effort I might make would be viewed by some as a conflict of interest.

Another telling point-I have not used all the languages available, so how can I judge them? Truthfully, I can't. So some of what you read here will be the result of many, many conversations with other programmers or of my own experiences with similar languages on other computers.

Through all of this, then, remember that I am trying to be fair and impartial. If you aren't convinced by the time I'm done that you should try our OSS products, I will know that I have managed to hide their true perfection well enough.


In the chart accompanying this article (see Figure 1), I have listed fifteen computer languages and rated them in several categories (the best rating is a "1"). As I wrote this, some of the languages were not yet available for Atari ST computers, but at least one or two versions of each should make its appearance within the next year or so. I rated each language based on my estimates, and I must warn you that sometimes these are very subjective judgments. I have at least a minimal knowledge of the syntax and workings of each of these languages, but I certainly cannot claim to be a proficient programmer in each.

Some thoughts on the rankings themselves: My ratings are designed for beginner to intermediate programmers (six months to two or three years experience in a given language). In the hands of an expert any of these products might score higher, but expert programmers usually have their own favorite language, so this chart is not for them. Also, after I made this chart, I showed it to some other programmers. They convinced me to change a handful of rankings, but by and large they agreed that my rankings are all within one (1) of theirs. Plus or minus one, then, may be considered as my acceptable margin of error in this table.

Every language received a ranking for its relative speed, flexibility, and maintainability. Although these are based on my own personal subjective criteria, I would like to think that most professional programmers-except for the one-language fanatics-will accept them as reasonable (within my "acceptable margin of error").

 * Speed-This does not refer to speed of compilation or program development; it is an estimate of the typical running time of a program written in that language. Languages with roughly equal run times get the same score. Generally, a language needs to be three or four times as fast as its competitors to get a better ranking. This is because variations in the efficiencies of the compilers (or interpreters) among manufacturers can often produce differences as great as this. Unlike the other categories, Speed refers only to language implementations for ST computers.

 * Flexibility- Some languages clearly have one main purpose. COBOL is an excellent example; it really is not much good for anything other than business applications. Other languages are touted as general purpose. Obviously assembly language is the most flexible. Since all other languages eventually get reduced to its level, you can do anything with assembly that any other language can do. Watch out for the trap: Just because something is possible doesn't mean it is easy. I couldn't even begin to want to write typical LISP programs in assembly.

 * Maintainability-If you are the typical home hacker, this category may not be important to you. In a commercial environment, though, there is often nothing more important. After all, when your programming guru decides to chuck it all to grow grass in Mendocino, how do you fix his programs when you find bugs? (And I guarantee you will find bugs.) To me, even as an individual, maintainability is a consideration. I have often had the horrible experience of trying to figure out what a particular BASIC program does, three or four years after I wrote it.

A final note on maintainability: Any language can be written in a maintainable fashion. If nothing else, you can write a book to go along with the program, detailing line by line what each statement is doing. But some languages encourage self-documenting code and others discourage it. My rankings are based on my observations of code actually written and in use. If you do a better job, congratulations.

Sidelight: I strongly considered including an ease-of-use category, but I reluctantly left it out. The problem is that ease-of-use is often not a feature of a language but rather of a particular implementation (i.e., brand name) of that language. For example, I rate Atari 8-hit BASIC very easy to use, but ST BASIC gets only moderate marks. Caveat emptor, then, on this category. Take a good look at the actual product before buying, if possible. Read reviews, and don't be afraid to ask questions.


After those three universal categories, I have rated each language for its appropriateness in each of seven categories. If a given language has no number in one of these columns, then I think it is totally unsuitable for the purposes of this category. Note that all these categories are somewhat an extension of the "flexibility" criterion. Presumably a flexible language should be usable for all seven tasks. But remember my caveat about assembly language: Just because you can do something in a particular language does not mean you would want to. Again, a brief description of each category follows:

No one
language is good for
all purposes.

 * Beginners-This almost substitutes for the missing "ease-of-use" category, but to rank high here a language must be both easy to use and easy to understand. I surprised even myself by giving Prolog almost a top rating here, considering how much I struggled when I first encountered it. I now blame that on the lack of appropriate tutorial material. So let that serve as a warning. My ratings here assume that you are either taking a class from a competent instructor or you are learning from a good, available tutorial hook.

 * Fun-A most subjective category it produced the greatest arguments from my fellow programmers. Sometimes I like to try out programming concepts just for the heck of it. How many of you remember my writing a BASIC interpreter in-of all things-BASIC? When I experiment I usually want an instant-response environment, so BASIC often wins. But for some more specialized concepts, I find it better to hack around in other languages. Hence this category and these rankings. The only way I'd consider an assembler or macro assembler fun is if their environment is good (e.g., integral editor and debugger). My personal choice for an ideal fun language would be a really good Pascal interpreter with a compatible optimizing compiler.

 * Business-Is the language suitable for typical business applications, such as inventory control, general ledger, etc.? Can it be used for general-purpose database programming? I am constantly amazed at the number of business programs written in BASIC, even though it lacks most of the rudimentary tools I would want for such a purpose (indexed file access, user-definable variable types, highly structured I/O, just for starters).

 * Scientific-Could I design a bridge with this language? Fortran has been the leader in this field for a long time, but there are signs that other languages may actually have more to offer. I think the reason Fortran is so accepted for scientific work is the incredible library of scientific functions that always accompanies it. But those functions are being written for other languages as well, especially those showing an asterisk in this column.

 * Action Games-This is a catch-all category. Among other things, it implies the ability to do superior graphics. On the ST, a good rating here means that the language has structures to access the system's built-in graphics as well as high speed operations to move things around fast. Note that I have not allowed the use of assembly language subroutines in languages such as BASIC! If you constantly must resort to things outside a language, the language is deficient. Try another language. I do not preclude the use of libraries written in assembly language, but they should be included in the language package. The individual programmer should not have to write them. The asterisk on Forth in this column indicates that a compiled version of the language will rank at least one place higher.

 * Artificial Intelligence-Once a very specialized category, it is becoming more and more popular. How easily can you tell your computer to "MOVE the blue pyramid on top of the red box"? The current crop of artificial intelligence languages are often rated as very slow, but this may be an illusion. How many lines of C code would it take you to make your computer perform that "MOVE" of a couple of sentences back? Maybe 10 or 20 times as many as a LISP or Prolog program, I would bet. Note that the "AI" languages are also good for some programs traditionally thought of as business applications, such as modeling and simulations. But this part of the AI field is in its infancy so I haven't counted it too heavily.

 * Systems Software-This is a pretty broad category. Operating systems, DOS utilities, computer languages, and more all fall here. Some languages perform adequately in all systems areas; others are limited to two or three tasks. Then, too, there is systems-software theory, where we investigate new ways of writing these products. Generally the artificial-intelligence languages (denoted by an asterisk in this column) do well here. LISP, for example, has been used to write many more specialized languages, most of which you've never heard of. And the Japanese are using variations of Prolog to test operating system design theory in their multi-processor computers. (These languages fall down sharply though, when we are talking about working systems-they are just too slow.) Anyway I would bet that more practical, working systems software has been written in assembly C, and Pascal then all other languages put together.

Don't expect me to try to justify each of the rankings I have given. Instead, I intend to concentrate on the best strengths (or worst weaknesses) of each language. Again, remember that I am not a professional in each of these languages, so expect more discussion of my favorites than of the others. But I promise to be opinionated even where I am ignorant.



As a computer professional I am supposed to sneer and make nasty remarks about this language, but I must confess, BASIC has always been one of my favorites. Truthfully it is not the language itself that is so appealing; rather, it is the BASIC environment that is fun to use. The whole idea of "instant programming" appeals to me. Imagine being able to modify a program almost as it runs! Got an error? Fix it and continue the operation. I also like to perform many programming quickies without writing a program at all! This is thanks to BASIC's ability to accept statements in "direct" mode, i.e., without line numbers as in conventional BASICs.

While I do not intend to comment on the quality of most available languages, I feel I must make a few statements about BASIC. Alas! The original ST BASIC from Atari is almost a joke. Imagine a language that can't even do five-digit arithmetic correctly (Don't believe me? Try PRINT 257*257 sometime.) There are a few BASIC compilers available, but I view a BASIC compiler almost as an anachronism. If I want a compiled language, I will use a good one-not one as limited as BASIC! And BASIC is limited, despite what the diehards may tell you. Even though some BASICs have managed to add procedures with local variables, record-oriented I/O, etc., none of them has overcome the fundamental limitation of BASIC: lack of user-definable variable types.

Anyway what I really want for the ST is a reasonably fast, interpreted BASIC with at least a reasonable complement of structured programming statements. It must both work within and program for the GEM environment. Atari has stated that they will be producing a new BASIC "real soon," and other companies are announcing interpreters even as I write this. So maybe, just maybe, I will be satisfied in the next few months, at the most. (Editor's note: See tbe sidebar to David Plotkin's article this issue for news of a new interpreted BASIC.)

And what about you? Well, the majority of computer owners never learn to program. And if they do dabble at it, they tend to try the languages which come free with the computer. If you fit in this category, I suggest you use Logo instead of the original ST BASIC. I may change this recommendation if and when Atari produces their new BASIC, but the current version is too buggy too inaccurate, and too clumsy to bother with.

If you intend to spend some serious time learning to program, think hard before investing too much time in ST BASIC. If you already know some BASIC, then dabble away. But a serious application in ST BASIC? Anything business related? Forget it. Do remember, though, that these remarks are directed towards ST BASIC. Other BASICs may be more than adequate for many many applications.


This language was provided free with early units of the ST computers, so you may already be familiar with it. My 9-year-old can claim two years of experience with Atari Logo for the 8-bit machines. It's a fun language. You can make things move across the screen, draw pictures, and do most everything a 7-year-old would want to do. At 9, he's beginning to get bored with it.

Is that a commentary on Logo's capabilities? Not at all. A full-blown Logo can even be a reasonable artificial intelligence tool, and Logo for the ST is close to being full-blown (8-bit Logo is not). But to use these advanced capabilities requires advanced concepts, which are generally beyond the scope of Logo tutorials. Catch-22, right?

Still, learning the fundamentals of Logo may be one of the easiest and best introductions to computer programming possible. Don't expect to write many serious applications using Logo, but using the advanced functions will make the language useful for what I called "fun" programming.


When I first encountered Prolog, I thought it was bizarre and almost impossible to learn. Now that I have written a tutorial on the language, I have completely changed my mind. I have been able to teach Prolog to people who find BASIC cryptic! It is remarkably easy to learn the concepts of Prolog- perhaps even easier than learning Logo.

The neat part about Prolog is that it is also very powerful. True, finding the source of its real power takes experimentation and work, just as with Logo. But the end results are almost always worth it. Programs tend to be much simpler and much shorter than their equivalents written in a more "standard" language. See the discussions of the rankings for "Systems" and "Artificial Intelligence" for some pertinent comments.

Just a fair warning: If you already know an "algorithmic" language (e.g., C, Pascal, Fortran, BASIC, etc.), you may need to readjust your thinking before tackling Prolog. Generally things that are easy in Prolog are difficult in those languages, and vice versa. Don't fall into the trap I did, be sure to learn from a good tutorial book. I am just egotistical and proud enough to say that the one by Mike Fitch and me is very good. But I will tell you of other good ones if you insist.


What can anyone say about LISP? It has been the darling of the artificial intelligence community for so long that it is required for computer science majors. Unfortunately, there is more than one de facto standard for the language itself. Xlisp, C-Lisp. InterLisp, and more all compete in this market. This isn't as bad as it sounds, though. Look how many dialects of BASIC there are; the various LISPs are no more different from each other.

What about a LISP for a beginner? Only in a classroom situation, I think. Already have some experience with other languages? Then you might try tackling it with a good tutorial. LISP can even be a good "fun" environment, especially if you like to investigate languages and systems processes of several kinds. And a LISP in a real GEM environment could be quite powerful.


As the footnote to the rankings table shows, these are my appelations for various languages which are more or less compatible with Ashton-Tate's dBase II and dBase III. Until something better comes along for the ST, if you want to write database applications, these are the ones to use. DB3 is the successor to DB2, and it answers many of my objections to the latter, such as lack of subroutines, limited number of variables, only two files accessible simultaneously and more.

You can
do anything with assembly
language that any other
language can do.

In a class environment with the right instructor, DB3 might even be a viable first computer language, though I think one really needs to have learned a more conventional language first. The DB2 environment was designed for machines which are tiny by ST standards, so it suffers in comparison. I would choose DB2 only if I had several dBase II programs that I wanted to move over to the ST.


Perhaps the greatest advantage of Pascal is that it is so standardized. Consider the fact that the programmers at Omnitrend managed to take over 1.5 million bytes of Pascal source code from an IBM PC, transport it to a certain Pascal on the ST and get the game Universe II translated in a few weeks. To me, that is incredible portability.

There is a vast body of literature written about Pascal. Almost all schools, from junior college to the most prestigious universities, teach Pascal as a standard language. It is the only language that high school students may use to qualify for advanced college placement via the college board exams. The list goes on. (Besides, almost a half million Turbo Pascal owners can't be completely wrong, can they? And Turbo Pascal isn't even particularly powerful as Pascals go.)

Does this mean that Pascal is perfect? Of course not. No language is. Many C programmers sneer at Pascal as being too limiting- they claim that it restricts their freedom of programming. Pascal, like BASIC, does such nice things for you as checking to be sure you didn't try to store something into the 233rd element of a 40-element array. (In C, and indeed in many loose languages, no such checks are performed. If you want to wipe out memory go do it. Most modern Pascals will allow you to turn off the checks if you really must, so you can wipe yourself out with Pascal, as well.)

I maintain that Pascal can be an ideal beginner's language. lt may even be better to learn Pascal before BASIC, especially if you have access to a local class or a good tutorial book. Does this mean that Pascal is not for professionals? Ask the ones who wrote Universe II about that. Overall, Pascal is a nice, safe choice for many many people. Including me of course.


Almost everything I said about Pascal applies equally well to Modula-2. Since both owe their existence in part to a single person (Niklaus Wirth), this is not surprising. Wirth designed Modula-2 to alleviate some of the problems associated with the original Pascal. In particular, Modula-2 is designed to be written in "modules" and then linked together. Since the original Pascal compilers insisted on compiling an entire program at once, this should give Modula-2 an enormous advantage, especially on memory-limited microcomputers.

Unfortunately for Modula-2, by the time it appeared, most Pascal compilers already supported many of its features, including (you guessed it) modular compilation. The result is that my rankings show it virtually dead even with Pascal. It loses a bit for beginners for just one reason: It is newer, so fewer tutorials are available and fewer schools teach it. Feel just a little bit adventuresome? This might be a reasonable choice.


If Pascal and Modula-2 are too limiting, then C is an anarchist's dream. There are no holds barred when using C. Want to twiddle the bits in a hardware register? C makes it easy Want to chuck the system I/O library and write your own? Since C has no built-in I/O, it is a natural choice for this!

I used to be a C hacker I still like the language, but I think that I have grown out of the hacker stage and am ready to admit that the most important aspect of a program is not how fast it runs. Thanks to a unique macro preprocessor, C source code can be as maintainable as any other language. And when I write some C code, I like to think that any competent programmer could maintain it. Unfortunately this same flexibility can lead to totally unreadable code. If you use C, it is your choice.

Some C fanatics claim that C compilers inherently generate better code than other languages (usually they are pointing the finger at Pascal or Modula-2). This is nonsense. What is really happening is that almost none of the compilers for microcomputers do very good code optimization. There is economic justification for this: Would you pay three to ten times the price for a compiler which generated 50 percent better code? Probably not. Yet a good optimizing compiler is much, much more expensive to write. A really good optimizing compiler replaces the need for writing torturous C code. Even with this help, C compilers aren't necessarily much (if any) faster than other languages, as my table reflects. (As a specific example, the highly touted Megamax C runs the "Dhrystone" benchmark only a couple of percent faster than does Personal Pascal.)

Bickering aside, C is a good, general purpose language. Since it was used to write major portions of the ST's operating system, it already has an "in" of sorts. But for beginners? I don't think so. The lack of bounds checking (see the Pascal discussion) is so often disastrous, that it can be pure frustration. On the IBM PC, several interactive C interpreters (with bounds checking) have become available. When one appears for the ST, consider learning C with it.


What can I say about a language that isn't even available? Well, if you want to win government contracts, learn Pascal or Modula-2 or C and wait for the first Ada compilers. But don't hold your breath. Ada is a fantastically complicated language, and it takes a while to certify a compiler to government standards. When the first full compilers appear, expect them to cost about as much as your computer. Also expect a 20-megabyte hard disk to be a minimum storage requirement.

Ada is undeniably powerful. You can not only define your own variable types, you can even define your own operators to work on those types. Want to find the number of days between two dates where you have specified the record format of a date? Just define the proper kind of "-" (minus) operator. No way is this a beginner's language!


COBOL is an acronym for COmmon Business Oriented Language. And if you want to write industry-standard business applications, if you want portability between your ST and your mainframe at work, and if you love to write self-documenting code, buy COBOL! What other language lets you write code that is as readable as this: "Add Price of Object to Sales-tax Giving Subtotal."

And, since COBOL is taught in virtually every vocational school and junior college in the country, it's even a pretty good choice for beginners. (Look how many companies advertise on TV that they can turn any high school graduate into a programmer. Guess what language they teach?) More commercially successful programs have been, and still are, written in COBOL than in any other language; so, if you are looking for a job in programming, you have to at least think about this language. Just be forewarned that thousands of others have got the same idea.


Forth is an enigma of sorts. The language itself is a little strange to those of us who think algebraically but it is fairly consistent and not too difficult to learn. The reason that I am hesitant to recommend Forth any more strongly is because of its environment. It was originally designed to be both language and operating system on 8,000 byte computers, and the Fig Forth standard shows this. ("Fig" should be "FIG" since it as an acronym for "Forth Interest Group." but the Fig'rs want it this way.)

Programs edited by "screens," with each screen limited to 1024 bytes? Come on now! I've got 520,000 bytes to play with here. Why should I be limited to this kind of obsolete environment? Worse, disk I/O is supposed to take place via screens, also. Forget the operating system, just give me 20,000 numbered screens on my hard disk. Ludicrous! I think the Forth Interest Group has done more to hinder the development of this language than anyone has done to enhance it.

Now that I have all the Forth fanatics up in arms, let me retreat just a little. Luckily the better Forths don't stick to the Fig standard. Most of them use the Fig version as a kind of internal starting place and then build better structures on top of that. Such things as file I/O, GEM-based program editing, and much more contribute to make Forth a more viable language.

As to capabilities, Forth is no slouch. Thanks to its unique "threaded" design, it interprets Forth as fast as compiled programs in some other languages run (COBOL, as a specific example). And Forth compilers are sometimes available to improve performance even more.

Unfortunately I don't think that Forth can be said to be the best at anything of importance. It used to win on compactness of code, but advanced processors and large memory sizes have dulled that issue. It gets fair marks for beginners because of its semi-interactive nature. Some versions of it might even get a better mark here. Perhaps the most telling point is the paucity of commercial products written in Forth. If Forth is as good as the fanatics claim, why don't more developers use it? (Yes, yes, I know of some significant exceptions-H&D's dBase II clone, for example-but the statement still stands.) I think I could like the right version of Forth. Let me know if you find one.


When it comes right down to it, there are some things that you just can't do as well in any higher-level language as you can do in assembler. Let's face it, no matter how good a compiler is, it can't possibly produce code which runs faster than assembler (equal to, perhaps, but not faster-by definition). But on the ST, about the only applications which I think can justify the extra work of assembly language are high-speed graphics programs. In other words, games. (Okay, okay. . .maybe 3-D drawing programs and the like.. but how many of you are going to write one of those? How many want to write a game? I rest my case.)

Now I happen to really like assembler. If I had to be confined to two languages, I might choose a really good BASIC (for all my quick and dirty stuff) and a good macro assembler (for everything else). It's gotta be a macro assembler, though. As complex as the interface to GEM is, I would get tired awfully quickly if I had to code each call in "longhand." A powerful macro assembler can make writing some programs almost as easy as using a high-level language. (What the heck. . . one more dig: I'll bet I could write a set of macros to duplicate 90 percent of the common Forth functions.) Besides, a program written using lots of macros can be very self-documenting.

Sigh. Unfortunately so far; I haven't seen the macro assembler for the ST If you are familiar with MAC/65 for the 8-bit Ataris, you will begin to see what I want. I need more powerful macros than MAC/65 gives (because of the complex GEM interface) and a GEM-based editor, and. . . but the idea is right. Editor, macro assembler, debugger which doesn't affect my program's screen or keyboard I/O, DOS commands-it's just not there yet. And my "fun" rankings reflect that. I would move a system such as I have described up at least one place in this category.

A warning: Beginners, stay away from assembly language! On the 8-bit machines, you could possibly start with assembler if you had a good tutorial (of which there were none for Atari, unfortunately). On the ST? I don't think so, unless you are willing to limit yourself to piddly little programs. You have to understand GEM as it is practiced in one of the higher level languages before you tackle it at the assembly language level.


Am I really done? Hard to believe! If you are thoroughly confused, maybe I have succeeded. If nothing else, I would like you to read reviews, check with your local users group, and get better educated generally. Try to stay away from the fanatics. If a person doesn't program regularly in at least two languages, be suspicious of any advice. No one language is good for all purposes.