Practical Common Lisp

Gary Cornell of Apress has an interesting blog entry concerning his decision to sponsor a book about Lisp, which is according to Gary a book other publishers give as an example of something they don't want. See http://blogs.apress.com/archives/000492.php?author=gary_cornell

Gary is right. I've never programmed in Lisp but when I started out I read John McCarthy's article on Lisp in Saul Rosen's 1968 collection "Programming Systems and Languages" and its value was apparent.

Basically, what we're doing in OOD is trying to replace big and complex things not by means of the usual nonsense, where the complexity is dumbed-down, but by replacing them with the appropriate simple concept (*begriff*) which we then learn to deal with.

Lisp pioneered this by being unlike Fortran recursive not by accident: a list is a list, and the head of a list is a proto-object, which can encapsulate and UNBOUNDED level of complexity.

Whereas take the usual Fortran program (please). It is a fug of arrays in all too many cases, where those arrays are never what they seem.

Sometimes they are arrays of data, but in many cases they represent through an implicit (that is undocumented) encoding some shadowy reality which the maintenance programmer dimly groks only after much pain.

In ordinary MIS programming we learned to abstract and to form concepts by default because in American business, the boss tells you what to do and you do it. It was only after some time, for example, that creating subroutines not so much to save memory as to purely abstract but to show the structure of the problem in the code became something that wasn't a termination offense.

Many programs want to be Lisp when they grow up. In modifying the original prototype compiler for Build Your Own I realized that I needed to implement not VBA (in which all variables are untyped Variants) but the far more usable structure of Quick Basic which was a prototype for early VB, and in this a variable has a semi-recursive structure...easily serialized by parenthesized expressions strangely Lisp like.

The problem is that major commercial languages refuse to do two things.

They refuse to make all entities of interest to the competent programmer, notably data types, into first-class objects that can be treated just like data. They also fail as I note in my book to make it easy to use the compiler at run time.

They create a class distinction which gets in the way of effective problem solving because in their image, the programmer is the end of the value chain and at the end ideally issues a minimum of high level instructions to the machine.

The answer in macro environments has been E. F. Hobsbawms "anarchy of the lower middle class", in which script kiddies create completely unmaintainable Web sites and Access macros using VBA, where any variable can be anything at any time.

Even in VB.Net, I had to create my own parser for Lisp-like expressions.

At my day job, I've completed an interval object which represents both simple intervals of integer or real numbers and compound sets of intervals which are closed under the concept interval, because it makes sense in all contexts to downsize the compound interval ([3,4],[10,20],[56,57]) into the simple interval ([3,57]) as long as you realize that you have lost "signal" in the form of the non-membership of the gaps ([5,9],[21,55]).

The object supports, in VB.Net, an intervalCalculus which is able to do things like return the interval "between" two intervals and the interval that is the "overlap" between two intervals.

There are fascinating subtleties. Two intervals, considered to be of integer type, can be adjacent such that the end+1 of the left interval is equal to the start-1 of the right interval: but if you change the interval type to real, the possibility of this integer adjacency disappears, to the replaced by the possibility of tangency.

Suppose [1,3] and [3,5] are integers (as is shown in the notation and supported in the object's deserializer by square brackets). They aren't adjacent but instead they overlap. But consider them as real numbers.

Their overlap turns into tangency at a real point in continuous space. That is, you use INTEGERS when you are a "particle physicist" and measuring "quanta" envisioned as having mass, you use REAL when your points are true points in a continuous, Euclidean, Newtonian space.

Lisp could have handled the development of the interval object in a much smaller time, I think, because there would have been no need to develop an (admittedly simple) recursive descent parser for deserializing interval expressions such as between(overlap([1,10],[8,15]), [11,1])

Lisp was probably the first system to make the compiler and data types fully available at run time. About the only problem I have with Lisp is the complete absence of usable implementations for real work and the fact that its inventor, John McCarthy, is today a neocon nutbar.