January 29, 2012
Comparing programming languages sometimes evokes passionate debate, so I thought that a little perspective would be useful.
If we asked a carpenter what the “best” tool was – a hammer, a screwdriver, or a saw – he would think that this was a meaningless question. It depends upon what task you are trying to accomplish.
Here are three examples of different languages from my own career:
For many years, I worked on mainframe systems that did accounting for insurance companies, pension administration, and payroll services.
In that environment, you do not want change to be “swift and agile”; you want change that is slow and can be easily verified. We had accountants whose role was to read Cobol source code to verify that it accurately reflected the legal language of pension contracts.
When you are dealing with millions of dollars in transactions per day, people take the placement of “decimal points” *very*, *very* seriously. And also, how all of the inevitable rounding errors are accounted for.
Around Christmas time, I often see credit card companies reporting the number of transactions at the busiest time of the year. This is usually in the tens of thousands of *sustained* database transactions per second. I would bet that most of these data processing systems are using Cobol/CICS.
You don’t hear about Cobol much these days, but most of the people reading this have probably used one or more Cobol transactions within the past week.
A few years ago, I was talking to a recently graduated Phd student in nuclear physics. He showed me the code that he had written for his doctorate and it was all in Fortran.
One project that I worked on (over a period of 7 years) used a Smalltalk workstation to plan flight paths for aircraft collecting environmental information. The data collected was then processed on a Cray supercomputer where all of the software was written in Fortran. Fortran has huge libraries for weather forecasting, but equally important, the compilers have been optimized over decades to get the maximum performance for numerical computations.
It is like the Cobol example above — numerical modelling libraries don’t change quickly and any changes that are made have to be validated thoroughly before going into production. What matters is performance. If tomorrow’s weather forecast takes a week to compute, then it is useless.
I worked on a telecom project for high-speed data switches that were programmed in C++. My responsibility was to merge multiple sources of code (from up to 300 programmers) into a final product build. The software was highly flexible and the team used Smalltalk workstations to build the configuration files.
In the telecom world, two things are important:
— speed – microseconds make a huge difference when you process millions of calls
— well defined interface specs – the C++ compiler will enforce 8-bit, 16-bit, 32-bit, 64-bit, 128-bit etc values. Absolutely essential in device drivers.
So, here are three examples – note that in two of the examples, Smalltalk was used in peripheral roles.
The *best* language is the one that meets the critical requirements of the application.
Financial services, weather forecasting, and programmable telecom switches all have different requirements.
And each of them has its own unique *best* language.