Programming Languages: where I've been and where they are going

My purpose in giving this brief history of my personal programming language experience is to show I know what I am talking about when you get to the argument at the bottom about the future of programming languages.

• APL (array processing) was my first programming language, in 1972, on an IBM 1130. Made me appreciate the power of concise notation. Too much power! I wrote a chess-playing program (using alpha-beta-style searching) in a couple pages of undecipherable code. Later, as an undergrad RA, I installed a large statistics package, large for APL anyway.

• SNOBAL (string processing, pattern matching) was fascinating in its sharp contrast to other more procedural languages. It got me thinking about AI more than LISP ever did. I wrote a fairly nice proof checker that had potential.

• I mostly avoided FORTRAN, but I wrote a 2D contour plotter. Years later, I wrote another one in Pascal, and a 3D contour plotter (aka "marching cubes") in C.

• I worked on the early Pascal compiler and runtime, added mathematical functions in assembly language, and added an Include section (which ended up not being used). Pascal was my favorite language for many years - maybe because I was still in the formative stage of my programming childhood. I was most pleased with a rather elegant string manipulation library I wrote, in which strings were linked segments referenced by their last segment.

• I wrote computer aided instruction programs and helped design a CAI language, the Minnesota Instructional Language. It was used for a few years, but has probably long since died. While at this CAI job, PLATO came out, with its Tutor language which resembled a high-level assembly language. Nice uniform, graphical environment, but the most I could manage was a chess program that checked your moves. PLATO notes were an eye-opener, however.

• I wrote optimized string copy and search routines in CDC assembly language. Keep in mind that CDC words were 60 bits long, which hold 10 6-bit characters. The algorithm for shifting words in a tight loop was implemented first in Pascal.

• Forth is a curious language, kind of like P-code with macros. Painful to write in, and painful to read. I was excited about its potential, but the most I accomplished was a string concatenation routine. Years later, I created a Forth-Lisp-like language for Genetic Programming.

• As a system administrator for the CS department at UIUC, I did some signifcant tricks using csh, awk, sed, etc. I never got into ksh and other modern shells - they never seemed quite worth the bother. Perl was another matter.

• Lisp became my preferred language mostly because of Emacs. I volunteered to edit and write large parts of the Emacs Lisp Reference Manual over a three year period. I wrote several packages, most relevant to this languages list. My first Elisp project was an interface to an incremental parser (written in C by another grad student). I modified Emacs internals to trap all text changes, accumulated consecutive changes in Lisp code, where they were lazily sent to an incremental parser that checked the syntax of what you were editing. My largest project was Edebug, a symbolic debugger for Emacs Lisp, which required mastery of almost every aspect of the language and the editor environment. This is my all-but-submitted Masters project.

• Other language-related Elisp work. I wrote a compiler in Elisp for a compiler class; it was for a pascal-like langauge. I wrote an interface to Mathematica with formatting commands for the bizarre language and notebook structure. I significantly augmented the C-preprocessor mode called hideif which included a small recursive decent parser.

• I was fortunate to be able to use Macintosh Common Lisp for an object-oriented chemistry project. I implemented some general DAG classes for modelling chemical structures, a 3D geometric objects library from Graphic Gems for representing their geometry, and a simplified OpenGL for drawing them. During this time, I extended Edebug to work with the macros of the Elisp Common Lisp package, and had designs on integrating Edebug into MCL and other CLs - no Lisp vendors seemed particularly interested, but by that time there were focused on survival.

• I used Python for the early work on that OO chemistry project. But the weird indentation-based block structuring, lack of complete garbage collection, and general immaturity of the tools forced me to look elsewhere. Tcl was another language being developed at the same time that maybe I should have looked into more seriously. I also considered various embeddable Schemes.

• My only use of Smalltalk was to implement the core of an Actor language for a concurrent languages course project. That was mostly done (except for some difficult bugs) when I decided to combine it with a visual languages course project and reimplemented it in Prograph, a visual OO language. Factorial of 6 took about 30 seconds to compute!

• My only use of C++ was attempts to write classes for programming language semantics, and geometric/topologic modelling for an OO Geographic Information System. C++ is hopeless in its complexity, and lack of garbage collection and clean exception handling. These are finally being recognized as worthwhile goals, but the evolution of C++ is a recapitulation of what Lisp has had since the 70s, with a different syntax. With self-restraint and a significantly limited application, C++ can be reasonable, but as OO consultant Ralph Johnson (and my neighbor) says, most sufficiently large C++ programs have a mini language inside of them to get around its limitations.

• I have read lots on various OO languages, including Eiffel, Self, Dylan, and on OO patterns. Important as OO is as a design philosophy, curiously enough, it is becoming incidental - what really matters is how objects interrelate as defined by their interfaces, especially when distributed across languages, processes, and processors. It is also the libraries and patterns on top of whatever language one uses that are important for building higher levels of complexity. I started creating a new language to combine the important language-level patterns. It was going to be called Escher, and be OO, concurrent, reflective, persistent/distributed, constraint-based, and optionally text-based or visual, but this never went beyond the idea stage.
• When the web was still young (1994), I reluctantly learned Perl, to implement HyperNews. I did this fairly soon after CGI came out, when things like CGI.pm and libwww-perl5 were not yet available. It is in dire need of a rewrite/redesign

• I built HyperNews forums for listing programming languages and for visual languagees based on the FAQ, but I am sure these are very obsolete by now.
• I was probably the first pusher of Java here at NCSA, even when it was still called 'Oak', though I never had the opportunity (or need) to use it myself. I recognized it as a likely winner because it had all the right ingredients for success: a familiar syntax and the essential semantics for clean, reliable, safe computing.

We have a long way to go before we get to the level of declarative abstraction in Prolog, and in fact, we are likely to never reach pure declarative programs as a general practice. Consider how Prolog itself is not purely declarative since it includes a few imperative constructs. This is similar to the non-purity of practical, functional programming languages. It is certainly possible to program in a pure (declarative, functional, ) language but it tends to be impractical except for very constrained applications.

Another trend is that highly specialized langauges for specific domains will continue to be created. Similarly, libraries for specific domains are written with function calls as the main interface; these libraries effectively extend the languages they may be used with. Lisp macros are more obviously extensions of the language, and whole new languages have been written with macros. But note that all these specialized languages, with their specialized runtime system or libraries, are essentially declarative in that the programmer simply calls a routine and the implementation of the routine can carry out the request however it wants.

One thing that we need more of is declarative semantics to specify what a routine is expected to do. The types of the arguments and results returned, supported by most typed languages, are a form of declaration. Some languages support pre and post conditions for routines, which is a large step further. Sufficiently complete pre and post conditions could be executable in the Prolog sense, or compilable to executable code.

But in general, there may be a large gap between the statement of a goal (a declaration) and the starting point. A path to reach a goal may be difficult to find, and thus the creative intelligence of human programmers steps in to help the system out with some explicit pointers. A sufficiently smart compiler for a purely declarative language must be artificially intelligent (and creative). Not an easy goal itself.