|Volume 1: No. 14|
C and C++ seem to the hottest languages at the moment. I think the win with C is that it is small enough to comprehend, close enough to machine language to get maximum performance (with, perhaps, a few tight loops recoded in assembler), similar enough to traditional algorithmic languages that programmers can transfer their skills, and structured enough so that modern programming principles can be implemented. Plus it is relatively portable, which is absolutely critical.
A major disadvantage of LISP has been that it comes with 10,000 "self-documenting" routines already defined. This doesn't bother a hacker who reads LISP fluently, knows how to use code inspectors, and investigates routines only when necessary, but it's a total barrier to those of us who have to understand ("grok") an environment before we can be productive in it.
C, on the other hand, is so primitive that it doesn't even come with string libraries. But hackers are comfortable writing their own little utility routines, and other programmers seem happier starting with a few dozen in-house subroutines than with 10,000 from outside. C takes care of the not-invented-here syndrome by forcing you to code from scratch. A good manager would insist upon use of supported libraries, but it seldom happens in the academic world. (One reason for changing to a hot new language is to have an excuse for rewriting all the old applications. It's easier for inexperienced programmers than maintaining old code. Applications tend to get better with each port, so recoding does advance the state of the art.)
There are a few corporate projects that use LISP as an embedded language, to be run on a separate board or linked in with a non-LISP driver. LISP is also selling well at second-tier schools, I'm told. But LISP as the order-of-magnitude productivity tool seems to have died. (I recently saw MUMPS touted in that role. And Greg Jirak is still pushing MAINSAIL, with some justification if an application must run on several platforms. As with Poplog, only a "back end" is needed for each platform.)
PROLOG is still popular in Europe and Japan, but most of the inferencing work in the U.S. is now done with expert system shells. I expect that to continue, although the shells need to improve. N.E.T.'s Expert Fault Management System, for instance, migrated from rules to LISP functions in order to get real-time response. (Mark Sutter says that he would now select C instead of a LISP-based tool such as KEE. LISP is a great development environment, but real-time code shouldn't throw you into a debugger when problems arise. Nexpert Object is attractive, but can't handle the number of objects in N.E.T.'s application.)
Ada is alive and well, along with COBOL, FORTRAN, FORTH, SmallTalk, etc., but I'd put my money on C/C++. (As always, I will disavow any of these opinions if someone with more knowledge speaks up. Have at me!)