Tower of Babel

And he made them to speak a different language...

When I was a mere lad of 23, I got my first real programming job at a company called Tracor, in Austin. I worked in the Aerospace accounting department, and worked on programs that did updates to sequential tape masterfiles. On-line database transactions were relatively new. My total arsenal of tools was: COBOL, Job Control Language, and training for hierarchical and relational databases. When I moved to Dallas two years later, in 1983, there were many mainframe IBM shops where I could shop my skills: Frito Lay, J.C. Penny's, TI, American Airlines, EDS, etc. The fairly narrow knowledge base availed me of much employment potential at that time. I settled on a job with TI, and happily coded away. Back then, other companies might have done some work in ALGOL, PL/1 or Fortran but COBOL had established itself as the dominant business application language for America's Fortune 500. COBOL was flexible enough to be used for on-line apps, batch and virtually any other processing mode.

By the late 80's, companies started doing the "paradigm" shift to newer platforms and languages. My company made some coy attempts at "Client/Server" computing using languages such as C, Smalltalk and Visual Basic. At the same time, CASE tools such as IEF were making competitive inroads on mainframe applications. These efforts flopped frequently, but some persevered and the systems are alive to this day. They may be small, disjointed or infrequently updated but are still alive -- maintained by a small cadre of "arcane" language experts. Pull forward to 2000, and you have more things thrown into the mix. I could elaborate on browsers and database systems but will keep the focus on languages themselves. We had Java, javascript, ABAP, HTML, DHTML, C++, C #, Power Builder, perl, UNIX shell scripting -- and multiple flavors and releases of most of the preceding. It was and still is a veritable Tower of Babel.

An unsubtle change of the last two decades is the shifting away from code that reads like English or algebraic syntax and over to a highly abbreviated "postfix" syntax used by object oriented languages. Thus,
ADD +1 to total morphs into
total = total + 1 morphs into
total++;

Economy of space, as well as ease of machine translation is sometimes given as a reason for this. But the point of higher level languages was never to make things easier for the machine so much as to make them easier for humans. Unless sub-second response time is critical (as in some type of real-time gaming app) the machine cycles shouldn't figure as importantly as the time it takes a human programmer to read the source code and comprehend what it does.

Some assumptions to make for your next business application:
1) The people coming after you to maintain it will probably be of average not expert abilities
2) They will be very time-limited in fixing bugs or making enhancements
3) Any high-level advantages to the original code (e.g., normalization, abstraction, object reuse) must be readily obvious and well documented or
the advantage will be lost on time-stressed support programmers.

Even for programs which permit cryptic, abrupt syntax, meaningful variable names and plentiful comments will ease the problem of readability. One could ask, in 2005, is there any move toward 'consensus' languages or programming styles? As I write this, I'm looking at an article of yet another new language called AJAX. The IT community will muddle thru, we can be sure. In all cases, people should say, "Is newer better?". "Is different better?" Not wanting to come across as Amish, I'd say frequently the answer is "yes". But if the answer is "no", you may have yourself a kludgy system in a niche setting -- nice work for a soon-to-retire contractor. But not very nice for the long haul. Better to build a system with readability and maintainability in mind. What language to use? My conservative nature would steer me away from "flavor of the month" unless it has big momentum --- I'll hold off on AJAX for now.