My Search for the Perfect Programming Language

(c) 2008 by Barton Paul Levenson

Those who know me know I spend an inordinate amount of time developing or trying to develop radiative-convective models of planetary atmospheres. This serves my interests in planetary astronomy and climatology (see the Climatology pages on this site). To write such a model you need a good programming language. I'm writing a book on how to write these models, so the language needed to be one I could explain to a reader without writing a whole programming book.

I had several criteria for which programming language to use. The most important one, considering my perpetually terrible finances, was that the compiler be free. I specify a compiler because I didn't want to touch interpreters, due to their slow speed. If you don't know the difference between a compiler and an interpreter, it's not too important, but please be aware that this page is full of such techie terms. For the record, a compiler produces "native code" on a computer so the program can run as fast as possible. An interpreter runs the program through another program which then carries out the instructions. The difference in speed can be substantial.

I'll list the criteria I used here. Some I started out with; some I developed as I tried various candidates and found roadblocks to what I wanted to do.

Here are the criteria the language I wanted had to meet:

1. It had to be free. This one was non-negotiable.
2. It had to be able to manipulate double-precision real-number variables.
3. It had to be able to produce "console routines" -- applications which just run in one window and rely on text printed out by the program and typed in by the user. I.e., not a program which required a complicated Graphical User Interface. Scientific simulations don't need bells and whistles; they need to produce accurate answers.
4. Because of the nature of the programs, the language had to provide ways to clear the console screen and to position text anywhere on that screen.
5. The language had to have a Windows IDE -- Integrated Development Environment -- or to come packaged with one. Working at the command prompt is too long and tedious for good development results.
6. It would be nice -- not essential, but nice -- if the language was one human beings found easy to learn.
7. The language had to produce neat numeric output, amenable to detailed formatting.
8. The language had to be able to read mixed numeric and string data from files.
9. A meta-requirement -- if a language was lacking in one of the above, there had to be some way to fix it, perhaps by linking to routines in another language.

After investigating several dozen free compilers available through the internet, I settled on a mere four final candidates:

• Free Basic, and its associated FBIde development environment.
• Free Pascal, with the Bloodshed Dev-Pas IDE.
• The MingW C compiler, with the Bloodshed Dev-Cpp IDE.
• Salford Fortran-95 personal edition, with its associated Plato IDE.

Here is how they all stacked up on requirements 1-8:

As you can see, they all had a few problems. Some were solvable with a lot of effort. Others were easier to handle. I review here, briefly, what I found by testing each one.

Free Basic was easy to use, easy to learn, and easy to debug. It was also a powerful language, with commands to do all kinds of interesting things. But both the functions it provided for neat numeric output -- PRINT USING and FORMAT -- were buggy. I tried to write my own routines and developed something that appeared to work against all testing after several days of patient debugging. But the point is, I shouldn't have had to.

I tried alerting the Free Basic community to the problem, and some other folks confirmed that it was there, but I was unable to make a bug report because I hadn't joined something called the SourceForge network, and even if I had, it would be some time before the fixes were incorporated in a new version of the language. Since my lifespan is limited and my time valuable, I decided to kiss off Free Basic.

Free Pascal was also both powerful and easy to learn. But I found error trapping difficult to make work right, and as a result, programs that blew up showed me nothing readable before killing the console window. I ran into a bug where the language could not read both string and numeric output on the same record. I couldn't find out what the problem was on my own. I posted the problem in the user forums. No one ever replied. So screw Free Pascal.

MingW C was powerful, but being a dialect of the C programming language, was a total pain in the rear to learn. No matter, I had trained on the old DOS Power C and on Borland's Turbo C, and I thought I could explain C to an audience of readers easily enough, if I went slowly enough. But this version of C turned out to lack the clrscr (clear screen) and gotoXY (position text cursor) functions found in other C dialects. And when I asked the user community about it, I was told that I should be developing Windows applications and not console apps, and that there was no good reason to provide console functions. So I kissed off MingW C and its hostile, supercilious user community.

Salford Fortran-95, Personal Edition was powerful, had an immensely helpful IDE, and could produce console apps -- but like MingW C, had no routines to clear the screen or move the text cursor. Here, however, the forums were very helpful (perhaps because many of the posters were polite UK citizens and not hostile, touchy Americans). By calling the Windows API ("Application Programming Interface," a part of Windows which provides various functions for programmers), I was able to produce reliable screen-clearing and text-positioning subroutines in less than one day. Criterion 9 saved the day for the problem with Criterion 4.

Fortran also has the advantage that it was the first compiled language, having gotten its first compiler in 1957 (three years before I was born, for those who are interested). It had had nearly fifty years to get thoroughly debugged, and was still the language of choice for scientific applications, due to its rich suite of mathematical functions. Fortran it was. I had trained on Fortran IV (the 1966 standard) and Fortran-77 (the 1977 standard, obviously), so the 1995 standard wasn't too hard to learn. Especially since Salford Fortran retained some F77 features for backwards compatibility with old apps.

Thus my choice of Fortran for my research, and for the book. If you have some other compiler which meets the criteria I list, or if you're a good enough programmer to go around the problems, there's no reason you can't use your own language to write RCMs. The algorithms are basically the same whatever the language.

Page created:	12/25/2008
Last modified:	02/13/2011
Author:	BPL