SPCL – 1) Formen, S-Expressions, Funktionen

SPCL – 1) Formen, S-Expressions, Funktionen

Hier noch ein etwas anekdotischer, nichtsdestotrotz interessanter Text aus P. Graham’s Buch „On Lisp“ (1.5):

Why LISP? (or When)

These new possibilities do not stem from a single magic ingredient. In this respect, Lisp is like an arch. Which of the wedge-shaped stones (voussoirs) is the one that holds up the arch? The question itself is mistaken; they all do. Like an arch, Lisp is a collection of interlocking features. We can list some of these features— dynamic storage allocation and garbage collection, runtime typing, functions as objects, a built-in parser which generates lists, a compiler which accepts programs expressed as lists, an interactive environment, and so on—but the power of Lisp cannot be traced to any single one of them. It is the combination which makes Lisp programming what it is.

Over the past twenty years, the way people program has changed. Many of these changes—interactive environments, dynamic linking, even object-oriented programming—have been piecemeal attempts to give other languages some of the flexibility of Lisp. The metaphor of the arch suggests how well they have succeeded.

It is widely known that Lisp and Fortran are the two oldest languages still in use. What is perhaps more significant is that they represent opposite poles in the philosophy of language design. Fortran was invented as a step up from assembly language. Lisp was invented as a language for expressing algorithms. Such different intentions yielded vastly different languages. Fortran makes life easy for the compiler writer; Lisp makes life easy for the programmer. Most programming languages since have fallen somewhere between the two poles. Fortran and Lisp have themselves moved closer to the center. Fortran now looks more like Algol, and Lisp has given up some of the wasteful habits of its youth.

The original Fortran and Lisp defined a sort of battlefield. On one side the battle cry is “Efficiency! (And besides, it would be too hard to implement.)” On the other side, the battle cry is “Abstraction! (And anyway, this isn’t production software.)” As the gods determined from afar the outcomes of battles among the ancient Greeks, the outcome of this battle is being determined by hardware. Every year, things look better for Lisp. The arguments against Lisp are now starting to sound very much like the arguments that assembly language programmers gave against high-level languages in the early 1970s. The question is now becoming not Why Lisp?, but When?

Auch sehr empfehlenswert ist das Vorwort von P. Norvig zu seinem Buch „Paradigms of artificial intelligence programming: case studies in Common LISP„.

 

Seiten: 1 2

Über den Autor

Marlon Schumacher administrator

Professor für Musikinformatik am Institut für Musikinformatik und Musikwissenschaft der Hochschule für Musik in Karlsruhe.