Parlez vous Fortran?

When I first started programming, the only language available to me was Fortran. I punched cards with my code and later received back a print-out with [mostly] error messages. I was always intrigued by being able to program a computer in such a straightforward way. I understood what assembly language or even machine code was all about, but felt that high level languages had a mystique. In due course, while still at university, I tried out any other languages that were available: BASIC, BCPL, Simula, SNOBOL 4, Algol W and I am sure there were others.

When I graduated and found myself in the “real world”, moving towards embedded programming, I found that a selection of languages was still on offer …

In my first job, I was doing real time programming on a mini-computer using a variant of Fortran and some assembler. I was then assigned to an embedded project [not that we used that term then] and I was programming mainly in Forth, which was interesting. My next job saw me become much more specialized in embedded using mainly assembly language on 8-bit devices. Later on I began to use high level languages like Pascal and C. We even had a Fortran compiler for embedded applications, but I do not recall anyone ever buying one.

Of all the different high level languages I have encountered, not one of them was designed for embedded use. PL/M from Intel is probably the only one that I can identify; Forth may also qualify. C has become the standard because it is a reasonable compromise – not ideal, but good enough. Ironically, I have often felt that one of its ancestors, BCPL, might have made a good embedded programming language.

In recent years, many programmers have migrated from C to C++, which has the potential to be a better language. But the take up has been slower than anticipated. This is a topic I have discussed from time to time – in this Web seminar, for example.

I am frequently asked to speculate on what language will be used in coming years and I do not have a firm view, as there are a number of possibilities:

1. It is often observed that the power that C offers as a language is also a problem, as this power is dangerous. One way to mitigate this danger is to use the language in a specific style. For example, MISRA have published a detailed set of guidelines on how to use C safely. It seems to me that, even if you are not programming a safety critical system, using such techniques will lead to more bug-free code, which is always advantageous.
2. I believe the C++ usage will increase, as engineers’ confidence in modern tools increases. MISRA have also published guidelines for C++, which may be useful. There is a language dialect called Embedded C++, which is espoused by certain vendors. It is a subset of the language, but, as far as I can tell, some language elements have been eliminated for no obvious reason.
3. Java will play a greater part in embedded programming, particularly at the application level. However, writing a complete system in Java is not an option. It lacks a number of necessary language features [notably pointers], so some coding in C, C++ or assembler will be needed.

In looking at programming languages, I have a strong sense of a continuing history. Maybe I will draw up a “family tree” sometime. It is entertaining to realise that there is nothing new. I first encountered object oriented programming in the Simula language, which was defined in the late 1960s. Fortran, which has been in use for over 50 years, introduced the idea of function overloading.

I often have the urge to program in Forth again, as the language has an amazing economy in style. Critics say that it is the only write-only programming language. I settle for insisting on an RPN calculator. Maybe I should look at Lisp …