Practical Common Lisp

Frank Buss writes "Common Lisp is an ANSI standard, which defines a general purpose language and library, and is implemented by free and commercial compilers and IDEs; see *hyper-cliki* for more general information about Common Lisp. The book Practical Common Lisp explains the language with many practical examples and is available in full text online, too." Read on for the rest of Buss' review. Practical Common Lisp author Peter Seibel, Gary Cornell (Editor) pages 500 publisher Apress rating 8 reviewer Frank Buss ISBN 1590592395 summary A book for learning and using Common Lisp

Unlike other good books about Lisp, which are focused on a specific domain, like AI (such as Paradigms of Artificial Intelligence Programming ) or basic computer science (for example Structure and Interpretation of Computer Programs for the Lisp-like language Scheme), this book focuses on solving real-world problems in Common Lisp, like web programming, testing etc., after introducing the language by examples in the first chapters. I started with Lisp half an year ago, and it has helped me a lot in learning it. But even if you already know Lisp, this book may be useful for you, because it has a fresh view on the language and the examples in the later chapters are usable in your day-to-day work as a programmer.

The first chapter tells you something about the author (he was a good Java programmer before starting with Lisp) and the history of Lisp and Lisp dialects like Scheme. The next chapters are a tour through all Lisp features, written in easy-to-understand steps, beginning with the installation of a Lisp system and an introduction to the interactive REPL. You don't need any experience in other languages to understand it.

The general concept throughout is to explain a feature first, then show an example of how to use it, with detailed discussion of what the example does and possible pitfalls. A nice example is the APPEND function, which does not copy the last argument:

The reason most list functions are written functionally is it allows them to return results that share cons cells with their arguments. To take a concrete example, the function APPEND takes any number of list arguments and returns a new list containing the elements of all its arguments. For instance:(append (list 1 2) (list 3 4)) ==> (1 2 3 4)

From a functional point of view, APPEND's job is to return the list (1 2 3 4) without modifying any of the cons cells in the lists (1 2) and (3 4). One obvious way to achieve that goal is to create a completely new list consisting of four new cons cells. However, that's more work than is necessary. Instead, APPEND actually makes only two new cons cells to hold the values 1 and 2, linking them together and pointing the CDR of the second cons cell at the head of the last argument, the list (3 4). It then returns the cons cell containing the 1. None of the original cons cells has been modified, and the result is indeed the list (1 2 3 4). The only wrinkle is that the list returned by APPEND shares some cons cells with the list (3 4). The resulting structure looks like this:

In general, APPEND must copy all but its last argument, but it can always return a result that shares structure with the last argument.

In chapter 9, the first larger practical example is developed, a unit testing framework (like JUnit), which is easy to use and to enhance.

Certain Lisp implementation behaviors can be confusing, such as those for for building pathnames. The pathname concept in Lisp is very abstract, leading to different choices in different implementations. This is no problem if you use only one implementation, but chapter 15 develops a portable pathname library, which works on many implementations. By doing this, it shows you how to write portable Lisp code, using different code for different implementations with reader macros.

After an introduction to the Common Lisp Object System (CLOS) and a few practical FORMAT recipes (the printf for Lisp, but more powerful), chapter 19, "Beyond Exception Handling: Conditions and Restarts", is really useful. The exception handling in Lisp (called "condition system") is more general than other exeption systems: In Lisp you can define restarts where you generate an exception and the exeption handler can call these restarts to continue the program. After reading this chapter, you'll never again want to use the restricted version of Java or C++ exception handling.

Chapters 23 to 31 show real world examples: a spam filter, parsing binary files, an ID3 parser, Web programming with AllegroServe, an MP3 database, a Shoutcast server, an MP3 browser and an HTML generation library with interpreter and compiler. If you ever thought that Lisp is an old language, only used for AI research, these chapters prove you wrong: Especially the binary files parser shows you, how you can extend the language with macros for implementing binary file readers, which looks nearly as clear and compact as the plain text binary file description itself. I'm using some of the ideas for a Macromedia Flash SWF file reader/writer I'm currently writing. Take a look at my Web page for my currently published Lisp projects.

The Web programming chapters demonstrates how to use a dynamic approach for generating web pages. You just start a Web server in your Lisp environment; then you can publish static Web pages or define functions, which are called when the page is requested by a browser. The author demonstrates how to define dynamic pages with formulars in Lisp and Lisp HTML generators.

After reading Practical Common Lisp, you will know most of Common Lisp and how to write real-world programs with it. Some special features, like set-dispatch-macro-character, or using one of the non-standard GUI libraries, are not explained, but it is easy to learn the rest of Common Lisp and to use other Lisp libraries, with the knowledge gained from this book.

You can purchase Practical Common Lisp from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page

Comments

I'm sorry,

[re-Verse]

But since we're practicing it, Isn't that supposed to be lithp

Re:I'm sorry,

[b17bmbr]

thtop. that'th a thtupid potht. you thould be athamed.

My first exposure to list ( and a mirror of book )

[winkydink]

Whenever I think of Lisp, I'm transported back in time to 1975 where I'm trying (unsuccessfully) to learn this as my 2nd programming language after Fortran IV (on a DECsystem-10, no less).

I never revisited Lisp. Perhaps now that I have the book, I'll give it a shot.

You can download a copy here if the main site is too busy.
~

LISP is amazing.

[millennial]

I took a Programming Languages course up at Michigan Tech a couple years back. We wrote our own interpreter using nothing but Common LISP, and it blew my mind. It got me really interested in programming language design.
However, LISP can also be hard to learn. The function names don't make sense to most people who have been raised on higher-level (1980s+) languages. I mean, 'car' to grab the first element of a list, and 'cdr' to grab all the others? It can get downright confusing sometimes.

Re:LISP is amazing.

[millennial]

Oddly enough, they only taught us the nonsense word names. Well, I suppose 'car' isn't a nonsense word... but in this context it's damn close.

Re:LISP is amazing.

[worst_name_ever]

I mean, 'car' to grab the first element of a list, and 'cdr' to grab all the others? It can get downright confusing sometimes.

But it leads to hilarious bumper stickers, such as: "My other car is a cdr"

Re:LISP is amazing.

[Homonymous Howard]

The function names don't make sense to most people who have been raised on higher-level (1980s+) languages. I mean, 'car' to grab the first element of a list, and 'cdr' to grab all the others? It can get downright confusing sometimes.

Common Lisp has first and rest as accessors for lists. Many Lispers consider it good style to use them when treating conses as lists and to use car/cdr when treating conses as binary trees.

Re:LISP is amazing.

[stinerman]

That doesn't make much sense. I prefer a recent .sig I saw:

My other car is first.

Re:LISP is amazing.

[haystor]

If you are a python programmer, there is nothing LISP can do that python can't.

Full blown macros are still beyond the reach of python I believe. I use these all the time and any language without LISP macros feels like I'm back in high school doing endless exercises over things I already know. Other languages talk about patterns and abstraction but their idea of this pales next to what can be done in LISP.

I'd elaborate but people attached to their own languages won't believe.

Re:LISP is amazing.

[Anthracene]

Or the sig of a CS prof at my undergrad school:

Today is the car of the cdr of your life.

Re:LISP is amazing.

[dragondestroyer]

There are FIRST ... TENTH and REST. See http://www-2.cs.cmu.edu/Groups/AI/html/cltl/clm/no de149.html

Re:LISP is amazing.

[sketerpot]

It's much easier to use than assembly. In assembly language, for example, it would be non-trivial to do something like this:

(remove-if-not #'oddp list-of-numbers)

That returns a list of all odd numbers in a list of numbers. With this sort of a difference in ease of use, why are you comparing Lisp to assembly language? My guess is that you're just talking out your ass.

Re:LISP is amazing.

[sketerpot]

Well, try looking at the PCL chapter on making an HTML-generation library that lets you intersperse Lisp code with a weird parenthesesified version of HTML. Here's an example of the code you can write with it:

(html (:ul (dolist (item stuff)) (html (:li item))))

(Sorry I had to put that on one line, but Slashdot doesn't handle code indentation very well.)

This HTML generation stuff is very useful, and it's pretty difficult to make without using macros. Also, this compiles down to efficient code, rather than being interpreted.

There are other examples. For example, the LOOP uber-macro doesn't require any special support from the Lisp implementation, but it's practically a mini-language for expressing common looping idioms.

Re:LISP is amazing.

[sketerpot]

Thats a *disadvantage* as it is encouraging, er, 'wooly thinking'

It can be handy during debugging. I don't recommend using cdaadr (et al) in production code.

They just couldn't write a parser for shit so they took the old adage "If in doubt, bracket" far too seriously and made it compulsory.

Wrong. Lisp has parentheses in specific places, leaving no doubt about where you're supposed to put them. Adding excessive parentheses to Lisp code changes it.

And the parens and the code-data equivalence do have a purpose. They make working with the code programmatically very easy, which allows Lisp macros. The macros that every Lisp fan always mentions. They wouldn't be nearly as useful if Lisp didn't use the parentheses. And the parens are amazingly easy to edit with proper editor support.

Re:LISP is amazing.

[haystor]

Ok, first imagine what it would take to add something to a language like Java. Let's take try/catch/finally as an example. You might have some java code that works like:

try {
methodCall();
} catch (Exception e){ //TODO: we'll clean this up later
} finally {
otherMethodCall();
}

Now let's say I wanted something like try/catch only specifically geared toward database transactions. I want it to look like this:

tran { //db operations go here
} rollback { // code handling rollback
} success { // code specific to a successful transaction
}

You just can't do that. Sure you could get similar functionality through the use of try/catch and a bunch of helper functions, but you can't integrate it straight into the language itself. You can only add to the language's library. In LISP, there is no real difference.

I can implement a "tran" macro so I can do things like:

(tran (withdraw 25.00 from-account)
(deposit 25.00 to-account) :rollback #'rollback))

This particular instance is my favorite example. It may not seem like a big deal, but I have hundreds of these things that aren't a big deal in my code. If I think something can be done a better way in the language I can add it.

The tran macro would be expanded during runtime to something that looks more like:

(begin-tran)
(withdraw...)
(deposit...)
(end- tran) or (rollback) depending on what happened.

A more complicated version of this macro could take into account nested versions of itself.

Someone will say that try/catch can be made to accomplish what I want. Yes it can. Those same people won't admit however that Perl can be bent to do what Java does.

There is a lot of writing about how great it is to have macro expansion at runtime. That was always meaningless to me until I latched on to that "tran" example above. All of a sudden I realized I wasn't bound to passing values (or references to values, essentially the same thing) to a function. Now I could pass whole chunks of code around. This struck me as such a right thing to do. I'd always been bugged that all the Java consultants around me were memorizing patterns. If something is a pattern, shouldn't the computer be doing it? LISP told me that yes, the computer should be doing it, not that I should be writing pages of patterned code.

It took me a year of talking to one of the guys I worked with where I explained macros to him. Six months after I left that place we went to lunch and he told me he finally saw the light as he was cutting and pasting some in one of his J2EE programs.

If you've ever been looking at something in the language (not the library) and wished that it worked just like that, only different, that is one case where you use a macro.

Re:LISP is amazing.

[e40]

OK, then do it. (defmacro left (x) `(car ,x)) and (defmacro right (x) `(cdr ,x)).

Re:LISP is amazing.

[anactofgod]

I love it when people comment on Lisp without learning even most rudimentary aspects of the language. Not to single you out, but it is obvious to when one reads a comment posted by someone who is regurgitating commentary provided elsewhere by other who know nothing about the subject.

I'm not certain what you've learned, but it certainly isn't "a lot". Certainly not about programming language design in general, and Lisp in particular. If you had even taken the time to read about just the history and design of Lisp, which is accessible to even the layman, you'd be able to post a more insightful comment than you just did. Why don't you try that, at minimum, since you are obviously uninterested and/or incapable of learning the technical apsects of the language.

As for Lisp being an experimental language, nothing could be farther than the truth. Lisp is a language that was several decades ahead of its time in design, functionality and capability. Everything else is just now catching up. Evidence all the effort to fold in Lispy features into Python, Perl, Ruby, etc., etc. The thing is, these languages' designers are trying to bolt the features into their language after the fact. While Lisp Just Works.

So, since you raised the topic, what's the answer? What would you have us "move on" to?

Re:LISP is amazing.

[thisgooroo]

What does 'contents of decrement address decrement register' mean? Nothing, thats what it means. It doesn't even refer to the way that the old LISP machine hardware worked. Its a false mnemonic.

the mnemonics describe the implementation of cons cells (the basic elements from which lists are constructed, but which also can be used for other purposes). they actually are the IBM 704 assembler instructions to access the componenets of cons cells. Most (all?) lisp implementations provide other mnemonics tailored for the particular datastructures, but Lisp has a tradition of backwards compatibility, so the car and cdr mnmonics were kept in

Besides which, just look at modern functional languages; its obvious that the excessive parenthisation in LISP is totally uneccesary.

the original spec of lisp (the lisp1.5 manual) used both the current syntax and a more algol like syntax, but the first implementation was done in the parenthesized syntax. as one of the texts on the history of lisp explains, the suitability of the s-expression syntax for mcro processing was discovered quite early and convinced practically all lisp users not to bother with a more traditional surface syntax, even though there were a few attempts (one of the first i remember was something called Lisp2 done at Stanford in the early to mid 1960s. it looke very much like algol.

They just couldn't write a parser for shit so they took the old adage "If in doubt, bracket" far too seriously and made it compulsory.

bull.

Re:LISP is amazing.

[stesch]

See What's with All the Parentheses? and the conclusion In other words, the people who have actually used Lisp over the past 45 years have liked the syntax and have found that it makes the language more powerful.

This is not a troll, but a query...

[Stanistani]

Could someone proficient in LISP give me three cogent reasons to learn the language?

Re:This is not a troll, but a query...

[tenordave]

1) macros will blow your mind. Read Paul Grahams' 'On Lisp'
2) takes bottom-up programming to the extreme. Really does help, but takes a while to get used to.
3) Much better to develop in...interact with the interpreter, compile individual functions and run them, change variables in a running image...

Re:This is not a troll, but a query...

[Neil Blender]

1. You can post on slashdot when ever the topic comes up.

2. You can think of yourself as extra cool.

3. It'll get you laid.

Re:This is not a troll, but a query...

[Lisper]

"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."

- Eric Raymond, "How to Become a Hacker"

Re:This is not a troll, but a query...

[tool462]

cadr(`yes `no `maybe)

Re:This is not a troll, but a query...

[Anonymous Coward]

1. Run-time typed, like Python, with optional compile-time declarations to improve efficiency in cases where compiler can not predict types.

Advantage is much fast code creation, with run-time safety, and option to get efficiency later.

2. Well thought out data structures with nice language support.

For example, ability to inline arrays and lists and symbols very conveniently in code. Ability to read complicated data structures (data files) without writing parsers, that are easier for humans to interpret and write than XML.

3. Ability to run code during compile process.

Enables very fancy compilation strategies, such as turning data structures into compiled code conveniently. Allows efficient, tailored extension languages to be written quickly.

In general, Common Lisp has many features that enable big, interesting programs to be written very, very quickly.

It has many downsides too, primarily the fact that the language spec predates many modern concepts such as concurrent threading and TCPIP. Interaction with other languages is mediocre - most implementations can call system libraries easily, but calling Common Lisp code from other languages is typically quite difficult. CL programs are rarely used as libraries by other languages.

Re:This is not a troll, but a query...

[ajs]

1) macros will blow your mind. Read Paul Grahams' 'On Lisp'
2) takes bottom-up programming to the extreme. Really does help, but takes a while to get used to.
3) Much better to develop in...interact with the interpreter, compile individual functions and run them, change variables in a running image...

Of course, these things are true of most any functional language. IMHO, LISP is a poor choice as a starter language if you're looking for the above wins. I would start with Haskell or Scheme and move on to LISP once you had your bearings.

Common LISP is a very old language (not as old as LISP, of course), full of the same kinds of pitfalls that any language its age or older shows (e.g. C, FORTRAN, etc). It is best to start with younger languages and work your way back.

Re:This is not a troll, but a query...

[haystor]

I got my start using lisp in emacs. I highly recommend this method. There is a lot of code readily available directly in the editor both for inspection and use. There are tons of functions that directly relate to a text editor.

This will get you familiar with some of the concepts of lists, atoms, quoting and order of evaluation. There really isn't much to a language like LISP or Scheme. The basic building blocks are few, it's largely a matter of where the line between language and library is drawn.

The functional languages are different because a language construct can be made indistinguishable from what the user writes himself.

Re:This is not a troll, but a query...

[Tayssir John Gabbour]

Of course, these things are true of most any functional language. IMHO, LISP is a poor choice as a starter language if you're looking for the above wins. I would start with Haskell or Scheme and move on to LISP once you had your bearings.

This is what I did, and it was a mistake for me. Many parts of Lisp are far "newer" than other languages because it is far easier to modernize.

For example, Qi is built on Common Lisp and claims to have "the most powerful type system of any existing functional language." I think it's a fancy academic language, but the win is that you can combine it with the hardened industrial features of Common Lisp.

Re:This is not a troll, but a query...

[tchernobog]

I can just say what it helped for me, so it's subjective, but:

1. Opened my eyes on how recursion should really be used, and improved my software design abilities a lot, since you're encouraged on writing new small functions and then put pieces together. LISP is built on LISP, and I found it a really educative language (and that's the same reason because I dislike Java, with its too-easy-to-become spaghetti-code). Moreover, in LISP it isn't just that a program has to work; it has to do it in an elegant way.

2. It is both a functional and object oriented programming language. Along with SmallTalk, in the '80 it revolutionized the programming language zoo, and some damn big programs started using it as an extension language (Autocad comes to mind). It has left me surprised studying it how much newer languages take from LISP, even something like Java.

3. It is a really high level language! A lot of libraries is already ready to use. Although the learning curve is really slow at first, LISP repays you a lot of your effort. Unfortunately there aren't many books on the subject. I really welcome this book, and I'll read it asap. Me, I've learned it using the wonderful Graham's book.

I also noted that in LISP finally you can "test code as you write", as they teach you in CS courses, but tight schedules and other languages often make that difficult in a real world scenario.
And in a hundred of lines you can write your own ray-tracer (see always Graham's book). :-)

Ah:
4. Extend GNU Emacs. That's the "c00l" factor that makes you geeky, at least for me. ;-)

Re:This is not a troll, but a query...

[joto]

Could someone proficient in LISP give me three cogent reasons to learn the language?

Try here

Re:This is not a troll, but a query...

[fizbin]

While I'm definitely a ruby fan, the ability to easily write self-modifying code (and by that I assume you include the ability to easily write code generators and to mix and match those code generators with the rest of your code - aka common lisp macros) is really something rather unique to lisp. You don't think that this provides a compelling reason to learn lisp? I admit, that's only one reason, but it's a big one.

I've written Perl code that generates more Perl code that is then fed to eval. I've helped people write python code that generates more python code, and that is truly painful (the indentation-based grouping of Python makes this much more difficult than it needs to be). I admit I haven't done that specifically in Ruby, but I can't imagine that the experience would be very different from the same exercise in Perl.

None of these come close to the power and ease of use of Common Lisp macros.

I also question your statement "Lisp implements everything as a binary tree.". While it is true that the cons pair is the most common lisp data structure, and that all code is seen in terms of cons pairs, it's disingenuous to say that Common Lisp doesn't have arrays (vectors), hashtables, or structures with named slots. Often times people will produce a benchmark showing that "lisp is slow", when in fact they've gone and compared lists in lisp (implemented essentially as singly linked lists) to lists implemented with arrays in some other language, or compared assoc. lists with hashtables.

Re:This is not a troll, but a query...

[Anonymous Coward]

That kind of smug comment is more likely to put people off LISP. I mean, yes Eric, I'm sure fetchmail is a lot better for the fact that you once dabbled in LISP, but don't go all Godel Escher Bach on us.

Re:This is not a troll, but a query...

[Tayssir John Gabbour]

Could someone proficient in LISP give me three cogent reasons to learn the language?

Bacon-and-eggs things to help you write more robust code:

• Powerful basic datatypes. Multidimensional extensible arrays with fill pointers. One-way/two-way/synonym streams, strings with fill-pointers, integer/rational/complex/floating-point/big/fixnum numbers, bit vectors, OOP with metaobject-protocol/{before/after/around}-methods/ multiple-inheritance/multiple-dispatch, errors/warnings/conditions. Etc.
• Something like XML, but much more readable, built into the language. So you can perform data-directed programming without switching to XML. And unlike XML, Lisp's sexps support more than just plain text.
• The "Conditions System", which among other things offers something far more powerful than exceptions for error-handling. Imagine exceptions that don't have to just burn up the stack.

For the moment, let's forget pretty stuff like macros.

Re:This is not a troll, but a query...

[smug_lisp_weenie]

There is really only one thing you need to know about lisp- Lisp essentially has NO SYNTAX. What this means is that your program is an abstract syntax tree that goes directly into the compiler.

Compilers in other languages first need to convert the program into an AST before compiling the code. (this is a bit of an oversimplification, but essentially true.) If you want three reasons, I can explain the repercussions of programming directly in an AST:

Elegance: In Lisp, you don't have to worry about idiosyncracies in the head of the language designers like you do in other languages: You don't have to worry about whether AND has precedence over EQUALS (Delphi programmers know this trap) you don't need to worry when a line needs to end in a semicolon, etc. etc.

Macros: By being an AST, Lisp lets you trick the compiler into thinking it sees other code than is actually there. This is COMPLETELY DIFFERENT than so-called "macros" in other languages- In Lisp you can turn your programming language into basically ANY programming language you want, within the language itself. Read Peter's excellent book or check out this site for more info.

Productivity: You can program in the purely-functional style that has been shown to increase programmer productivity by having a property called "referential transparency" and having the easily serializable syntax-expression format. Basically, with Lisp you can analyze/manipulate/automate the bejeezus out of your code very easily, under the mantra "code is data, data is code".

That's what I like about Lisp, anyway...

Re:This is not a troll, but a query...

[anactofgod]

I am an ex-Lisper who strayed from the One True Language and am now in the process of regaining proficiency to rejoin the Lisp Priesthood. My motivation is that I am tired of the limitations I hit due to the deficiencies inherent in all the other supposed "modern" popular programming languages I've encountered. I also remembered really *enjoying* the whole process of rolling Lisp code, a joy I lost long ago when I strayed into the mass market of more socially acceptable programming languages.

The deficiencies of modern languages I speak of above are not necessarily those of capability (though those exist), but are primarily of language design. Most languages are designed with the goal of increasing the productivity of the average programmer. Lisp's design was entirely about elegance, simplicity and power. I can give you lots of reasons why Lisp is better than insert-your-favorite-programming-language-here, but that will just devolve the conversation into a jihad. So, let me tell you what Lisp is fantastic at.

Actually, you know what? I'm not going to reiterate that which others have stated. If you really are interested, let me just point you to a couple of sites to get you started on your journey of discovery. Read Paul Graham's essays/articles, the first two chapters of Peter Siebel's book available on-line, this essay on Lisp's prowess as a rapid prototyping language and this paper on why the future of the (semantic) Web may lie with Lisp. Then, if you appetite is whetted, Google for more info, download a flavor of Common Lisp, work thru Seibel's book, and experience it for yourself.

Or not. If you're perfectly satisfied with whatever flavor you how you do your work, there is absolutely no reason to learn ANYTHING new, is there?

Learning Lisp. It will take you back to the future.

Re:This is not a troll, but a query...

[sketerpot]

I think the parens confuse almost everyone. They gave me a headache until I learned the editor keystrokes for manipulating them easily and learned to look at the indentation instead of the parentheses. Now I have trouble with other languages. It's amazing how anything different from what we're used to (whatever we're used to) seems hard to use, isn't it?

Re:This is not a troll, but a query...

[Ulrich Hobelmann]

Really? Which functional language has macros?

Which functional language lets you redefine stuff in a running image?

Haskell might be good for real functional programming, but in Lisp you don't do that much functional programming.

I learnt Scheme first, actually, and I'm not that impressed, just like Haskell didn't impress me that much. Scheme is a stripped down Common Lisp with nicer syntax, a weird macro system, and an emphasis on functional programming.

And I don't see in what way Common Lisp has old warts, compared to FORTRAN or C...

It was standardized in 1984, with an object system. That's not too bad, IMHO, considering that Java is just a worse smalltalk-80 and that other C dialects similarly seems to be stuck with '70s technology, compared to Common Lisp.

Re:This is not a troll, but a query...

[e40]

If you think that macros in any language are better than the ones in Lisp you are very uninformed... and you clearly never used Lisp. Lisp macros manipulate and transform Lisp expressions. Once you have used them you will be completely amazed at how powerful this is.

As for starting with younger languages... cripes. Common Lisp became an ANSI standard in 1994. It continues to evolve and has two commercial companies behind it, and many open source projects.

Re:This is not a troll, but a query...

[fizbin]

No, that's not what I'm asking for; although I will admit that I like Ruby's ability to pass a following code block into any function, this is really something completely different. (For non-rubyers: the poster is talking about a facility that's similar to being able to pass an anonymous function as an argument with nice, clean syntax that doesn't get in your way - similar to the way that the perl builtin sort and map functions let you pass in a block)

A macro basically allows you to rewrite code completely, reaching into the bowels (if necessary) to rip out and mangle what needs to be done.

A basic example is the setf macro. This macro is used for basic assignments:

(setf captain "Picard")
(setf answer (+ 23 42))

Except, of course, that the first argument can be more than just a simple symbol:

(setf (aref array 0 10) new-value)
(setf (car mypair) mynewcar)

So far... so what, right? After all, this "fancy" syntax is just equivalent to the java code:

array[0][10] = new_value;
mypair.car = mynewcar;

Okay, but how about this - suppose I define some functions dealing with a simple berkeley-style database. Say, (get-from-db dbref keyvalue) and (set-to-db dbref keyvalue newvalue). Now, if I set things up properly, I can make setf work with these functions too, so that the user can do:

(setf myprevval (get-from-db id key))
; some calculations on the previous value here
; do some other stuff here
; some calculations to get the new value
(setf (get-from-db id key) newvalue)

See how I never explicitly call my database setting function? The last line there never actually calls my get-from-db function - instead, it reaches into the parentheses and rewrites the code so that what happens is a call to set-to-db.

That is, the user never has to know about the set function. Essentially, setf means "here, in the code, where I've said setf, instead go ahead and use whatever the appropriate setter function is for a reference of this type". (when I defined my db functions, I would have to call some macros to tell setf about get-from-db and set-to-db)

Now, for this specific case - creating a unifrom set syntax for any "get"-type function you wish - Ruby has specific explicit syntax support. (just name the "set" method the same as the "get" method but add an "=" to the end of the name) Lisp, however, handles setf through the more general macro mechanism. This means that it can be extended in a bunch of different ways. For example, Lisp defines incf to mean roughly what C's "++" operator does, except again without special language support. (And incf will automaticaly take advantage of the setup I've already done for setf)

In order to do its magic, setf has to be able to access the reference (get-from-db id newval) exactly as I typed it, and has to be able to rip apart and inspect the innards. This is something only a macro can do.

Re:This is not a troll, but a query...

[zorander]

While self modifying code in ruby is not practical, macro-like code generation is pretty clean. They're not full read-macros like lisp, but I think they lend themselves to more readable/extensible code. In lisp, if you use a read macro, and it isn't properly documented, then the users of the function will be confused by why things are being quoted until they find the source or read the docs. Lisp macros are also quite difficult to read and modify later if you didn't write them.

Here's an example of method generation in ruby:

CALLBACKS.each do |method|
base.class_eval -"end_eval"
def self.#{method}(*callbacks, &block)
callbacks block if block_given?
write_inheritable_array(#{method.to_sym.inspect}, callbacks)
end
end_eval

This is from the rails source code (which takes metaprogramming in ruby to an extreme I haven't witnessed previously, even in lisp). If you configure your text editor not to parse here documents, then the code you're generating will be highlighted correctly (and with the right %X{} sequence, it will almost always be highlighted).

No, it's not read macros, but I've seen read macros which generate hundreds of lines of lisp in the most horrid fashion. This is no good. I'd rather have a more controlled mechanism (and more object orientation).

That said, Lisp is a lot of fun, and I look forward to the next time I have substantial reason to use it.

Lisp Scheme

[superpulpsicle]

Lisp is essentially the same as scheme. It's the hardest language to write for IMHO just cause it's out of ordinary.

There was a story of a hacker stole one of the A.I code from the government. The code turned out to be the last 100 pages of the program. It was all closing paranthesis. That should sum up how nasty the language is.

Re:Lisp Scheme

[joto]

Let's be accurate. Common LISP is to Scheme as C++ is to, perhaps, C - both dialects of the same basic language, but one far more feature-rich that the other

No. This is false. And it doesn't really matter that you or many other people believe it to be true. It's still false.

Scheme is a block-structured language modeled on Algol. Common Lisp is a natural evolution of LISP 1.5. As part of the evolution, sure, some features from Scheme have been sneaked back into Common Lisp, but they are really very different languages.

LISP is to Scheme as BASIC is to Microsoft BASIC. One is a dialect of the other.

No, it isn't. Scheme and Common Lisp are no more dialects than Pascal or C++ is. And I really mean what I say. C++ is an evolution of C, which itself is an evolution of B. Something similar can be said of Common Lisp.

Pascal is an ivory-tower language written to prove a point, that later, with various extensions, almost got useful, and were actually used for real programming. Something similar can be said of Scheme.

And they are certainly not dialects. They are far too different.

Scheme has tons in common with Common LISP.

Pascal also has tons in common with C++. I.e. they are both block-structured imperative languages.

Sure Scheme has tons in common with Common Lisp. But there are also tons of differences, and many of these differences are important! Such as scheme being block-structered, and Common Lisp not being block-structured.

If you try to look a bit further than superficial syntactic issues, you will find that the languages are quite different.

It's the same story as with Java and Javascript. People without a clue believe them to be similar. People with a clue know they aren't.

Re:Lisp Scheme

[rsheridan6]

It's not C-influenced-language programmer friendly. If you learn Lisp before you're indoctrinated into Algol-descended languages, the opposite is true - the syntax of those languages is too complicated and annoying, with too many things to remember (like 10 levels of operator precedence).

It seems difficult to you for the same reason Japanese seems difficult to native English speakers, and English seems difficult to native Japanese speakers.

practical? common?

[daraf]

(if (or (= lisp practical) (= lisp common)) (monkeys-fly-out 'my-ass) (life-as-normal))

Re:practical? common?

[UnknowingFool]

(if (or (= lisp practical) (= lisp common)) (monkeys-fly-out 'my-ass) (life-as-normal))

I don't know what is sadder: the fact that you wrote it, or the fact that I understand what you wrote.

Re:Good book, questionable language.

[tenordave]

Where the hell have you been? It has better exception handling than most langauges (including java, read the book), and was one of the first languages to use garbage collection. In addition, you'll find all the normal data structures in all the other languages, threading, and so on that you're used to. CL of today is not CL of the past.

Dylan - pretty Lispy

[aCapitalist]

Dylan

seemed to have many of the benefits of Lisp without the prefix notation - macros, CLOS-based object system, multi-methods, multiple returns, optional type declarations, named parameters (I think), etc...

Dylan was started by Apple Research Cambridge in the late 80s, but was laid to rest (at least for Apple) after Jobs came back and the NeXT infusion.

At least Functional Objects opened up their stack and is now being incorporated by the above URL guys.

C++/Java/LISP Side by Side Comparison?

[Anonymous Coward]

Lately there has been a lot of LISP hype mostly thanks to Paul Graham. I keep hearing "Macros are amazing", "totally different way of thinking about programming".

That's great and all but I can't find any concrete examples. I want to see a list of problems that are either difficult or nearly impossible with Java/C++ and see LISP's implementation.

Can anyone help me to get past the hype?

Re:C++/Java/LISP Side by Side Comparison?

[Anonymous Coward]

Here's one:

Add a construct to your language called "with_open_file" that takes three arguments: a filename, a variable name, and a block of code. The construct should open the file, store the open file handle in the variable, and then run the block of code with that variable in its scope. After the code completes or has an exception, the file should be safely closed. Example:

with_open_file("/tmp/flozz", f) {
f.write("Hello, world\n");
if (rand() > 0.5)
throw Exception;
}

Yes I know how to do exception handling and so forth in Java/C++ but I want you to add a *new keyword* to your language.

Another one:

We're working on a timing-sensitive project. I need to you to add another keyword to your language. This one is called "sleep_between" and should take an integer argument N and a block of code. It should insert "sleep(N)" statements between each statement of the code and then run it. For extra credit, create a general keyword that inserts ANY block of code between the statements of another block of code, and use that to implement "sleep_between". Example:

sleep_between(1) {
print("3");
print("2");
print("1");
print("contact");
}

Extra credit: modify your code so that it also inserts the sleep() calls at the end of every *loop* within the block. So if I rewrote my example to say "for n = 3 downto 1 print(n)", it would still sleep between each statement.

Another one:

The junior programmer didn't know about the "with_open_file" statement. His code keeps throwing exceptions and leaving data unsaved. We're shipping tomorrow and we need to have this fixed this afternoon. Write a function that runs his code and rewrites it on the fly to use our safe "with_open_file" keyword. (In Lisp this is *easier* than just doing a search and replace, btw).

Re:C++/Java/LISP Side by Side Comparison?

[hey!]

Simple. Macros turn the simple but boring work of solving a programming problem into the difficult and interesting work of extending the language you are working in.

O'Reilly: Are you listening?

[Glomek]

There IS a place for modern Lisp books!

... programming paradigms

[grumpyman]

When I think of functional (lisp), my head's twisted and then unwinded. When I think of contraint-based (prolog), my head feels like upside-down. When I think of object-oriented, I think of org-chart. When I think of procedural, I think of spagetti.

Re:My first exposure to list ( and a mirror of boo

[ajs]

If you find LISP interesting, Haskell might also be of interest.

Recent interest in Haskell has exploded because of the implementation of Pugs in GHC. Pugs is a compiler / interpreter prototype for Perl 6, which is also a functional language, borrowing many concepts from LISP and smalltalk (as well as just about every other popular research or practical programming language).

Re:Practicle Common Lisp???!!!

[ari_j]

People who can't spell "practical" can't be expected to appreciate the finer things in life.

Learn Lisp Without Installing Anything on Your PC

[smug_lisp_weenie]

I have a tutorial available that teaches lisp in comic-book form. It is geared to quickly ramp up a newbie to some very advanced lisp tool very quickly.

It uses a free online telnet lisp that lets you try Lisp with zero install required.

Re:Learn Lisp Without Installing Anything on Your

[smug_lisp_weenie]

Oops- Here's the link: tutorial

Best Lisp Book: On Lisp

[ari_j]

Paul Graham's book, On Lisp, is the single best book on programming I have ever read. You can get it as a PDF from his website, for free.

You will also want to read his essay, Revenge of the Nerds, for some serious insight into why Lisp is just so darn good.

If you're just starting on Lisp, the best place to start is with GNU CLISP, although you will find yourself wanting to use Emacs with SLIME to interact with your Common Lisp environment. I use SBCL, but CMUCL and CLISP are also acceptable. On my Powerbook, I use SLIME with OpenMCL.

Re:Best Lisp Book: On Lisp

[Phs2501]

On Lisp is certainly a good book about one particular feature of Common Lisp (macros), but it's not a good introduction to the language.

Frankly, I find both Seibel's Practical Common Lisp and Norvig's Paradigms of Artificial Intelligence Programming to be much better books on Common Lisp than anything Graham has written. Seibel has excellent practical examples dealing with current technologies, and Norvig's examples cover a very interesting subject matter not usually used when teaching a language.

Re:Best Lisp Book: On Lisp

[The boojum]

when you choose to abandon LISP in favour of, say, static type checking, his insistence that all great hackers prefer LISP, and if you don't prefer LISP you aren't a great hacker, begins to grate somewhat.

Yes, that's my biggest problem with his writings. I rather like static type checking personally, and will gladly trade the minor benefit in malleabillity for more error checking at compile time. I can't count the times I've made a trivial typo in Perl, for example, taken hours to find it and then thought to myself, "this would have been caught instantly in ML."

While LISP is a cool language, I really like what I've seen of the strongly static-typed functional languages like the ML family (especially OCaml.) I love the pattern matching features for example. The only thing I miss in them is the macro mechanism from LISP or Scheme and the extreme performance optimizations of modern C++ compilers. I do heavy-duty numerical coding in C++ (graphics/ray tracing), but I'd love to be able to write code in a statically-typed functional language, have macros expand out and optimize or inline the low-level, performance critical parts and have the compiler optimizer work it over till it's as fast as I'd be able to do in C++. (or faster!)

So yes, I consider myself a pretty good code-hacker, but I'd still not pick LISP for my graphics code. LISP is not the right tool for every job.

Re:Best Lisp Book: On Lisp

[Tayssir John Gabbour]

While LISP is a cool language, I really like what I've seen of the strongly static-typed functional languages like the ML family (especially OCaml.) I love the pattern matching features for example. The only thing I miss in them is the macro mechanism from LISP

Qi (which is built on Common Lisp) is touted as having "the most powerful type system of any existing functional language, including ML and Haskell." Perhaps you may wish to try it out and see.

Re:Practicle Common Lisp???!!!

[ari_j]

Your assumption that all self-modifying and/or recursive code is spaghetti code belies the fact that you've never actually learned Lisp.

I have always found that spelling and grammar skills are very important to good coding, as well. After all, it helps immensely to be able to spell your variable names correctly. Even if you spell them incorrectly consistently, someone else who is looking for the bugs in your code will probably decide that one of the bugs is your spelling, and will break more things than he fixes, particularly if you used the correct spelling for another variable.

This article has truly inspired me

[Anonymous Coward]

To wonder why there isn't a -99 "Suicidally Boring" option when you're moderating...

Common Lisp and Schem are really different.

[notany]

Comon Lisp and Scheme are as different as programming languages can be.

Scheme can be said to be ontological attack against Lisp. It looks Lisp but is as far from Lispiness as you can and being still Lisplike.

Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
-- Nikodemus

Greenspun's Tenth Rule of Programming:
"Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

Common Lisp people seem to behave in a way that is akin to the Borg: they study the various new things that people do with interest and then find that it was eminently doable in Common Lisp all along and that they can use these new techniques if they think they need them.
-- Erik Nagggum

More than anything else, I think it is the ability of Lisp programs to manipulate Lisp expressions that sets Lisp apart. And so no one who has not written a lot of macros is really in a position to compare Lisp to other languages. When I hear people complain about Lisp's parentheses, it sounds to my ears like someone saying:

"I tried one of those bananas, which you say are so delicious.
The white part was ok, but the yellow part was very tough and tasted awful."
-- Paul Graham

Lisp is about rising above implementation to saying something of lasting
value. -- Kent Pitman

Pascal is for building pyramids -- imposing, breathtaking, static structures
built by armies pushing heavy blocks into place. Lisp is for building
organisms -- imposing, breathtaking, dynamic structures built by squads
fitting fluctuating myriads of simpler organisms into place.
- Alan J. Perils

Puns are pricey to have in the language becuase they lead to ambiguity
but they are also a source of great expressional power, so we live
withthem. People who don't like them should probably seek out Scheme,
which tends to eschew puns, for better or worse.
-- Kent M Pitman @ comp.lang.lisp

Q: How can you tell when you've reached Lisp Enlightenment?
A: The parentheses disappear.
LISP has survived for 21 years because it is an approximate local
optimum in the space of programming languages.
-- John McCarthy (1980)

``Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of our
most gifted fellow humans in thinking previously impossible thoughts.''
-- "The Humble Programmer", E. Dijkstra, CACM, vol. 15, n. 10, 1972

Lisp is like a ball of mud--you can throw anything you want into it, and
it's still Lisp".

Java was, as Gosling says in the first Java white paper,
designed for average programmers. It's a perfectly
legitimate goal to design a language for average
programmers. (Or for that matter for small children, like
Logo.) But is is also a legitimate, and very different, goal
to design a language for good programmers.
-- Paul Graham

> The continuing holier-than-thou attitude the average lisp programmer...

There are no average Lisp programmers. We are the Priesthood. Offerings
of incense or cash will do.

-- Kenny Tilton at c.l.l

Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp
fueled by LSD. Java evokes a vision of a stereotypical nerd, with no
life or social skills.

In the Algol family, parentehses
signal pain. In the Lisp family, they signal comfort. Since most people are
highly emotional believers, even programmers, it is very hard for them to
relinquish their beliefs in their associations of parentheses with pain and
suffering. This has nothing to do with aesthetics, design rationales, ease
of u

Lisp might be good but..

[glogic]

It's a pity, but lets face it: Lisp could never be adpoted for widespread use - there's only a finite number of parenthesis in the universe.

Re:Tcl/Tk RULES!!!

[nizo]

I swear I would rather chop off my left hand then program in Tcl ever again. But I won't hold your love of Tcl against you :-) My favorite behaviour when using Tcl was seeing a syntax error in code that had been running in production for years. Since Tcl isn't preprocessed god only knew how many syntax errors where in that code. Granted the programmer should have written test cases to exercise all of the code, but that is a whole other ball of stupidity.

The advantages of functional languages

[doc modulo]

- C++ is more readable than assembler
- C# and Java are more readable than C++ ...
- At the end of this list are functional programming languages.

If you can read source more easily, then maintainability will be better. Most projects maintain code, they write new code less often.

This article will tell you why you should be interested in functional programming languages (this link is about Lisp). If you're smart and open minded, you will be convinced.

The best functional languages are Haskell and Erlang (click "next" at the bottom of the page). But like the review and link indicate, there's actual value to learning Lisp.

However, the book review is much too in-depth and has jargon.

A simpler example: with Java you prevent bugs by static typing variables, example:

int numberOfTries = 3;

If you later try to fill "numberOfTries" with a string, the compiler will warn you of a bug and you'll have prevented it. The Java compiler makes it a rule that you have to give a type to your variable so your code quality will be higher (fewer bugs).

With Haskell, you don't have to type int. Haskell will figure out the type for you, you get the benefit of preventing bugs with the convenience of not having to type variables. There are other good features like that in functional programming languages.

You could say that every language puts restrictions on what the programmer can do. I mean writing the source code is bottlenecked by the rules of the language (every variable should have a type. You can't do this/that etc.) so that the resulting code AUTOMATICALLY has fewer bugs. Well the amount of source "laws" in functional languages is much lower than in C++ and Java. This means that there is less to remember for a programmer and there is less chance for rules to conflict/interact with each other (in Java you can't use certain variable types in static classes = another meta rule to remember).

Besides having less rules to remember and take into consideration. The functional languages have also chosen the best "laws" to follow. I mean that if you follow the source laws of Java, it's still relatively easy to produce buggy programs, with functional languages it's harder to produce implementation bugs (thinking bugs are always possible but that's your problem).

The only problems with functional programming languages is that the rules which govern source code are very good, but also very different from the rules in traditional programming languages. It might seem like thinking upside down/backwards for people already familiar with procedural languages. Another problem is that because of humans sticking to what they know, the libraries of the functional languages aren't as extensive as those of Java for example. This means that you'll have to program more parts of your program yourself instead of just using a ready made library which fits the task. This problem is limited by the fact that you can program 10 times faster than in Java and, as I said, maintenance takes up most of the time anyway.

The reason I chose Erlang is because with functional purely functional programming languages like Erlang, you can automatically multitask your program over several CPU's (or this will take minimal effort). Nice feature to have in the future because every CPU manufacturer is going multi-core chip now. The future is in multiprocessor machines, not higher clockspeeds (unless diamond wafers become viable) (Lisp is not purely functional by the way).

Also, you can easily make a server that never goes down with Erlang because your server is automatically clustered. Just plonk down a couple networked PC's and if one dies, the server cluster will just keep on going (a bit slower) until you replaced the power supply of the broken PC.

There are tons of other advantages but, as I said,

Re:The advantages of functional languages

[master_p]

Oh man, your post has so many things wrong, I don't know where to start! And I am not trolling, this is serious: dissinformation should be stopped. Read on, please.

C# and Java are more readable than C++

C# and Java are not more readable than C++. If I write C++ code without templates, C++ code is 99% similar to C#/Java.

At the end of this list are functional programming languages

Functional languages are not more readable than C++/C#/Java. ML is bareable, but a long Haskell/Erlang/O'Caml program is unreadable, no matter how you approach it. Examples: Haskell's operator ++ that has nothing to do with addition? O'caml's '#' for membership? The double ';' at the end of declarations? LISP's 'car', 'cdr' and 'cons' instead of 'head', 'tail' and 'pair'? and the list goes on...

LISP is not a functional language. It has developed to be one, but it did not start as one. In fact, it has destructive update, i.e. the SETQ operation (if I recall correctly)...

A simpler example: with Java you prevent bugs by static typing variables, example:

Having to explicitely declare the type of a variable is not static typing. Static typing is when the types of values are determined at compile-time.

With Haskell, you don't have to type int. Haskell will figure out the type for you, you get the benefit of preventing bugs with the convenience of not having to type variables. There are other good features like that in functional programming languages.

Bullshit. Having not to declare the type of a variable is not a primary characteristic of functional languages. The primary characteristic of functional languages is the non-destructive update of the state of the application. There are imperative languages that also have type deduction. And by not declaring types, one makes the program really unreadable, and very difficult for Intellisense editors. In fact, with Intellisense, it's just as easy.

In fact, the only difference of functional languages with imperative ones are the lack of assignment. All other capabilities of functional languages can also be found in imperative languages. There is nothing of functional languages, except lack of assignment, that can not exist in imperative languages.

so that the resulting code AUTOMATICALLY has fewer bugs. Well the amount of source "laws" in functional languages is much lower than in C++ and Java. This means that there is less to remember for a programmer and there is less chance for rules to conflict/interact with each other (in Java you can't use certain variable types in static classes = another meta rule to remember).

The only reason FP programs have fewer bugs is because assignment is not allowed. Other than that, logical bugs creep in in the usual way. All FP languages are not purely functional, and they hide state update in strange places, because otherwise it would be impossible to program. And no functional language has its primary APIs directly in that language! all the serious work (networking, DB, GUI etc) are done from C, C++ and/or Java libraries!

There are tons of other advantages but, as I said, the above links will convince you if you're smart.

Bullshit. Functional languages are glorified calculators. I can do with C++ the exact same programming, using operator overloading and list copying. Show me how to sort a 100,000 records recordset with functional programming style and then we can talk.

It was invented by Ericsson to create ultra reliable realtime servers.

Well, Linux is programmed in C and it is ultra-reliable. So is Solaris and BSD. And WinNT. And VAX. And MacOS X.

Functional languages are a waste of time. It's time to have an imperative language with the close-to-the-hardware C mentality, LISP syntax, type deduction etc that also provides facilities for proof-carrying code. That's where the money is. Functional languages are an evolutionary dead-end.

The reason that I say the

Re:My first exposure to list ( and a mirror of boo

[behindthewall]

FYI, the download-able files contain the book examples' source code. They do not contain the book itself.

Re:Tcl/Tk RULES!!!

[js7a]

Delayed compilation is a feature!

Which would you rather have, a syntax error where indicating the code is faulty, or a silent semantics error?

Although (ahem) uh, the possibility of the former doesn't preclude the latter, but, uh, please observe the authoratative manner in which I wave my hands!

Re:Good book, questionable language.

[e40]

As everyone else that's replied to you has pointed out you are talking out your ass. Lisp had exceptions and GC long before Java or C# were even an idea. GC in Common Lisp is far ahead of GC in Java and .Net, for just this reason. An industrial strength GC isn't made over night, it's made by having applications beat the hell out of the GC and the implementors spending huge amounts of time handling huge programs. This is exactly what's happened for Lisp over the last 20 years. For example, Allegro CL hosts industrial applications the likes that have never even been dreamt of in Java or C#--programs that use GBs of memory and runs for months. Try that in Java or C#.

If you are still unconvinced, Orbitz wouldn't even be possible (according to the authors of the software that run the site) without Common Lisp.

That's not what car and cdr are for...

[jtdubs]

That's probably not the right way to think about it. A cons cell is a data structure that holds a pair of items. The first is the car; the second is the cdr. The accessors for those parts of a cons cell also have the names car and cdr.

Linked lists are just one data structure that you can implement with cons cells. You can also implement a stack, queue, binary-tree, association-list, etc...

If your are using "cons cells" in your program, use car and cdr.
If you are using lists that are implemented via cons cells use first and rest.
If you are using a stack use push and pop.
And so on...

In other words:

CL-USER> (car (cons 1 2))
1
CL-USER> (cdr (cons 1 2))
2
CL-USER> (first (list 1 2 3))
1
CL-USER> (rest (list 1 2 3))
(2 3)

Justin Dubs

An ideal world would run on LISP...

[Florian]

It's amazing and somwhat sad that programming languages and runtime environments from Smalltalk to Java to Python to C#/.NET keep reinventing the wheel while a language from the 1950s has it all and does it even better - the most elegant syntax thinkable, powerful paradigms for code reuse, dynamic typing, modern memory management with no buffer overflows, and, with Common Lisp, one robust, industrial-strength language with a rich standard library that can both interpreted and compile code, obsoleting the difference between "programming" and "scripting" languages.

The initial vision of the GNU system - remember "GNU's not Unix" - was to combine a kernel written in C for performance reasons with a userland written largely in LISP. Emacs is the only remnant of that idea, isn't even LISP in its program core, and uses its own LISP dialect instead of CLISP or Scheme. [The climacs project, a CLISP reimplementation of Emacs, tries to fix that.]

Two years ago, I saw a practical demonstration of a Symbolics LISP Machine from 1987. It was like seeing the light of the holy hacker grail - the first system whose userland was superior to commandline Unix in every aspect [Plan9 has superior kernel design to Unix/BSD/Linux, but its mouse-centric userland sucks IMHO]. Everything was in one language, syntax and namespace. You could hack and debug the kernel (written in LISP, too) while it was running [!], the commandline userland hooked into every aspect of the system, and could be endlessly and seamlessly extended it just through custom LISP functions and eval-ing them.

Let's dream and hope that perhaps in one or two decades, when insight into the limitations of the Unix paradigm has become common sense, we will have a free Lisp OS as the next iteration of Free Software computing...

Re:An ideal world would run on LISP...

[noahm]

Two years ago, I saw a practical demonstration of a Symbolics LISP Machine from 1987

The frightening thing is, lispms from the 80's enjoy quite some popularity among certain people where I work. They really are amazing machines, and those who use them regularly feel strongly that there hasn't been a more usable environment in all the time since they were created.

Let me tell you, though, as a sysadmin, these things can be a royal PITA. Not because there's anything wrong with them (well, except maybe for their complete lack of security) but they're just so different.

There are still many copies of The Lisp Machine Manual lying around, including an early rant by RMS against the recent trend of software hoarding. It makes for an interesting read...

noah

Re:My first exposure to list ( and a mirror of boo

[sketerpot]

Some of the key differences between Haskell and Lisp are:

• Haskell has a strong typing system, similar to that of ML. Lisp's type system is optional, and while many Lisp implementations can do type inference and checking, it isn't required, nor is it as big a part of the language.
• Haskell is purely functional, and it fakes side-effects with the Monad design pattern. Lisp has side-effects, with all the advantages and disadvantages that entails.
• Haskell uses lazy evaluation. Lisp uses strict evaluation unless you explicitly ask for lazy evaluation.
• Lisp, thanks to all those parentheses, has very powerful macros. I know every Lisp fan says this, but they're really cool. Haskell relies more on higher-order functions and infix syntax for that sort of thing, which isn't as powerful but which you may find to be a decent tradeoff.
• Haskell has significant whitespace, like Python. Lisp doesn't.
• I find that editing Lisp code is easier than editing Haskell code, due to the excellent Lisp editing modes available for various text editors. OTOH, maybe that's partly because haskell-mode for emacs is pretty rough.
• Lisp can generally be made faster than Haskell, which is very nice in bottlenecks. For the rest of the program, though, this isn't so major.

Re:How about OS interaction

[dragondestroyer]

This website may help http://www.podval.org/~sds/clisp/impnotes/syscalls .html, but be careful as it is not always completely clear which functions work on which platforms.

Things might have been different

[amightywind]

It is such a shame that C-based languages took over the computer world in the 1980's. If we had followed the Lisp path instead things might be so much better. C++ with all of the template, RTTI, and STL grunge is such a half-assed imitation of powerful Lisp constructs that have been perfected for 15 years. I won't even go into Java, Python, C#, PHP. What a waste. I suggest you non-Lisp programmers grab a copy of SICP and start over.

Re:Things might have been different

[Anonymous Coward]

I would agree, but Lisp is a fragemented platform. The good Lisp environments are expensive and have proprietary GUI add-ons. Is there even a common POSIX layer?

Sun did one thing right with Java: Microsoft dicked around with it and got swarmed by an army of lawyers. Lisp never had this benefit.

You claim that other languages are a waste, but what about the evolution of Lisp itself? It seems all the infighting and money grubbing were the waste, IMO. It's sad, though, because Lisp is so nice.

Re:Things might have been different

[Anonymous Coward]

If we had followed the Lisp path instead things might be so much better. C++ with all of the template, RTTI, and STL grunge is such a half-assed imitation of powerful Lisp constructs that have been perfected for 15 years. I won't even go into Java, Python, C#, PHP. What a waste. I suggest you non-Lisp programmers grab a copy of SICP and start over.

What a waste indeed - that Lisp programmers are blind to the real possibilities of real modern languages. I'm not talking about C++, Java, and PHP. I'm talking about ML, Haskell, Ruby. Languages that can do all the useful things Lisp can do, and many things Lisp makes incredibly difficult. And do them faster, or more conveniently, or with a syntax that even programmers whose brains have been poisoned by exposure to C are able to accept.

I suggest you Lisp programmers open your eyes to what's happening in the interesting parts of the modern language community. You'll find a lot that looks just like the Lisp you love - and a lot of new things you would never have believed were possible.

Re:My first exposure to list ( and a mirror of boo

[omnirealm]

Whenever I think of Lisp, I'm transported back in time to 1975 where I'm trying (unsuccessfully) to learn this as my 2nd programming language after Fortran IV (on a DECsystem-10, no less).

I've heard it said that someone just learning how to program can pick up Lisp in a day. If you happen to already know Fortran, it will take two days.

Re:Good book, questionable language.

[Ulrich Hobelmann]

You are clueless.

Common Lisp is lexically scoped, in fact it has closures (unlike Java). 1984 it was standardized with a really powerful CLOS (CL object system), in comparison to the puny Java object system 10 years later.

Lisp also *invented* garbage collection! Without it you'd still be using FORTRAN, not Java.

And the AI comment is simply stupid. Any language can be used to do AI; Lisp is simply used for it, because it's way more powerful than Java and other crap.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Practical Lisp?

[Zangief]

I have yet to find a lisp implementation that:

1-it is open sourced.
2-it has some GUI support (tk or gtk).
3-it is cross platform (including the GUI support).
4-it is estable, not in some estate of eternal beta.
5-it is embeddable in a web server (yes, I know Mod_lisp exists. But, yet it doesn't comply with 2 or 3)

If a young language, like Ruby or Python, can do this, why the hell Lisp, one of the oldest languages around, can't?!

Until I find something like that, I can't say Lisp is practical, no matter how theoretically cool it is.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:My first exposure to list ( and a mirror of boo

[Anonymous Coward]

Haskell has significant whitespace,

Optional significant whitespace, but everyone uses it. IM(anonymous)O it works a lot better in a functional language than imperitive.

Haskell syntax is really amazingly beautiful. Usually. Even if you don't find Lisp interesting, have look at Haskell.

Re:My first exposure to list ( and a mirror of boo

[Anonymous Coward]

Wrong. The entire text of the book is on-line.

Arc would probably get widely taken up

[Szplug]

Paul Graham's Arc is the great hope (there's a lot of interest in it at least). If it is elegant as promised I think Lispers would take it up. But, it's pretty ambitious and he appears stuck for the time being; the most recent I've heard on the subject is this comment (2nd down) at lemonodor. He's said he intends it to be a hundred-year language and that he'll take his time, so, everyone'll have to make do with CL for the while.

Re:Libraries...

[circusboy]

this is a good set to start with, and look up asdf and asdf install for further libraries that are cross platform/implementation for lisp. saves a lot of trouble, and evens out the differences between the various lithpssssssss

My 2 cents on Lisp and FP

[Tablizer]

I have had long debates with Lisp fans and FP fans. In the end I concluded:

1. FP simplifies bad practices. If you avoid certain poor programming practices of coupling things that shouldn't be coupled, then FP's advantages are only incrimental at best. My opponents kept saying, "See what I can do with FP!", and I kept countering, "But that is not a good design" or "I don't need that feature that often", which is the truth.

2. Lisp's uniformity of syntax makes it powerful, but also very difficult to read. Other languages have syntax that acts like landmarks. Lisp is like having every house be the same such that it's power comes from the arrangement of the houses, but other languages mix in houses, stores, trailers, etc. to give visual landmarks to lock onto. Lisp is just too damned monotonous. Somewhat ugly syntax is more memorable. I tried to get "into" Lisp, but just found it too hard to visually process.

Re:My 2 cents on Lisp and FP

[Tiny Elvis]

#2: most languages are difficult to read until your eyes are 'tuned' to it. Lisp is no different. When I started I agree it was hard to see the program flow. It did not take long before the ()'s disappeared from my attention and the program structure became more accessible. I love that everything in Lisp is an expression, there is not statement/experession distinction. This make the code incredibly flexible. Also, CL macros are extremely powerful, they are made possible by the simple syntax.

Re:My first exposure to list ( and a mirror of boo

[Myolp]

I had a similar experience with Common Lisp a couple of years ago. Fortunately I found Scheme, which made the whole functional programming paradigm a whole lot more enjoyable.

http://www.plt-scheme.org/

Re:My first exposure to list ( and a mirror of boo

[ajs]

First off, let me say that I'm new to Haskell, and learning it, Python and (as of last night) Fortress at the same time, so I'm far from an expert.

"Lisp can generally be made faster than Haskell"

Certainly, and I'm not saying Haskell makes a good language for day-to-day coding. I'm just saying that it's a good place to learn functional programming.

"Haskell uses lazy evaluation. Lisp uses strict evaluation unless you explicitly ask for lazy evaluation."

For those who do not understand this point, it's worth going into. In C, when you say:

c = foo() + bar();

you call functioan foo and bar, add their results, and store that result in c. In Haskell a similar construct would store in c the information required to call foo and bar at a later time when/if you needed the value of c, but of course, if you just add c to another value, you just create a more complex result, you still don't invoke foo or bar.

This is a very powerful concept, but can also lead to surprising results if you are used to programming in non-lazy languages.

engineering tradeoffs

[cahiha]

Everything else is just now catching up. Evidence all the effort to fold in Lispy features into Python, Perl, Ruby, etc., etc.

Engineering is about making tradeoffs--something that the designers of Lisp did not understand. If you try to create a completely general language with completely general language constructs, you try to standardize it, and you try to also make it fast, something has to give. And the thing that gives is development time.

Python, Perl, and Ruby can afford to implement lots of Lispy things because they aren't also trying to create a language standard and efficient, natively compiled implementations. Java is also implementing lots of Lisp things, but it makes other tradeoffs (which result in it being more cumbersome in some ways).

While Lisp Just Works.

That's a stupid statement: nothing "just works" for everybody. And CommonLisp had lots of problems: scoping, naming, reflection, and code generation are all pretty shaky in CommonLisp. Its standard library also had lots of important omissions. If CommonLisp "just works" for you, consider yourself lucky. Frankly, I think the number of people for whom, say, Python "just works" is considerably larger than the number of people for whom CommonLisp "just works".

Re:engineering tradeoffs

[Pete]

Engineering is about making tradeoffs--something that the designers of Lisp did not understand.

Yeah, it's a terrible shame that all those incredibly intelligent mathematicians and engineers behind Lisp didn't have cahiha to advise them about the concept of engineering tradeoffs.

Java is also implementing lots of Lisp things, [...]

Lots of Lisp things??? Tell you what. How about you tell me just two. And you can use "garbage collection" if you can't think of anything else, but I'll think it pretty lame :).

The things I generally think of when I think of Lisp (Common Lisp or Scheme or other forms) includes REPLs, macros, functional-style programming, macros, incremental/optional compilation, macros, optional/dynamic typing, macros, closures and macros. Oh, and (occasionally) continuations. Java doesn't come close to having any of those, last I looked.

And CommonLisp had lots of problems: scoping, naming, reflection, and code generation are all pretty shaky in CommonLisp.

Okay, try to name (or point to an article online that names) something wrong (or suboptimal, etc.) with the Common Lisp implementation of scoping, naming, reflection and code generation. Seriously, I'm really interested. I'm not an expert on Common Lisp myself, and all I'd read suggested that Common Lisp was actually far superior to any other programming language re: reflection and code generation (and I'd never heard of any problems in the way it handles scoping or naming).

Re: the standard library having some important omissions, well, you have more of a point there. Lacking a semi-standard free implementation of a GUI has been a bit of a problem for a while, but it's debateable whether such a thing belongs in a standard library in any case. Same with other practical issues like database connectivity.

Some languages (eg. Java, Python) define rather a lot of stuff in their "standard" library. Some (eg. Scheme) define very little. Common Lisp is somewhere between the two extremes. There are usually libraries to do most things you might want (especially for the more popular implementations), but they're not necessarily standardised.

Frankly, I think the number of people for whom, say, Python "just works" is considerably larger than the number of people for whom CommonLisp "just works".

Quite likely. No argument there. But I'd probably suggest that the average (serious) Common Lisp application is significantly more sophisticated and powerful than the average (serious) Python program - mainly because Common Lisp just has a lot more raw power than Python.

To borrow an apt quote from Kenny Tilton, one of the denizens of comp.lang.lisp: "Lisp supports meta-solutions which not only pay off more and more in the long run, but which also require greater design effort up front. If anything a Lisper tortoise seems to be going slower than the hare because the tortoise is still at the starting line building a rocket sled."

Re:engineering tradeoffs

[sketerpot]

Okay, try to name (or point to an article online that names) something wrong (or suboptimal, etc.) with the Common Lisp implementation of scoping, naming, reflection and code generation. Seriously, I'm really interested. I'm not an expert on Common Lisp myself, and all I'd read suggested that Common Lisp was actually far superior to any other programming language re: reflection and code generation (and I'd never heard of any problems in the way it handles scoping or naming).

CL has some problems with the Meta Object Protocol (MOP), which is used for reflection and to modify the object system. It's not standard, but it's supported by all major Lisp implementations---and they usually have small differences, most prominently what package they put it in. Is it in the MOP package? Or perhaps the SB-PCL package? In order to make portable code that uses the MOP, you need a compatibility layer like Closer or MOPP or CLIM-MOP.

That said, once you have all the compatibility code in place you can do amazing things with the MOP. I co-wrote a graphical object inspector that made heavy use of Lisp's introspection abilities, and Pascal Costanza added Aspect-oriented programming to Common Lisp with AspectL.

Re:engineering tradeoffs

[cahiha]

Yeah, it's a terrible shame that all those incredibly intelligent mathematicians and engineers behind Lisp didn't have cahiha to advise them about the concept of engineering tradeoffs.

They did, actually. I told them (as did lots of other people) even back when Lisp was more hyped up than Java has ever been and people were dropping $100k for a single Lisp-based workstation. They just weren't listening. The result of their lack of good engineering sense and arrogance was the demise of Lisp and the predictable (and predicted) 20 years of dark ages of C/C++ programming. It just boggles the mind that 20 years later, people like you still don't get it. I guess hindsight isn't 20/20 after all.

I won't even say anything more about Java, since I don't like the language, other than that you seem to know very little about its actual capabilities. For Python vs. Lisp, read Norvig's article.

Re:Static code verifications, anyone?

[Tiny Elvis]

You are complaining about dynamic programming in general. The compiler cannot always detect that a function is missing because the function does not even have to exist until runtime. I can build up functions in the program and call them. I could load a compiled file which contains the function at runtime. I could call a function by name, and that name may not be known until runtime.

You claim to love Lisp, but I don't think you have really ever sunk your teeth into it, otherwise you would understand that what you gain with Common Lisp's dynamic nature makes up for what you lose in compile time error checking. I'm a big boy, I don't need the compiler holding my hand and telling me that function x is not found or that argument y is the wrong type. My code runs correctly because it is written correctly. I just use tools besides compiler type checking to get it to this state.

Lisp's problem

[GCP]

If you are going to use Lisp for anything practical, you have to deal with the fact than any programming platform you choose is a combination of base language, libraries, dev tools, documentation, implementations (at several levels), other programmers, etc.

The Lisp aspect that Lisp lovers (like me) tend to like most is in the most fundamental notions of the "idea of Lisp". A very small toolbox of ideas that are combinable in an amazingly flexible way, allowing a layering of totally customizable abstractions. The power of such an approach is intoxicating, leading to a real love of the language for so many people.

The basic ideas aren't the problem. They are so pure and simple that they are almost timeless, like a branch of mathematics.

Lisp's problem is that those ideas don't exist in a vacuum. When you need to use Lisp for practical purposes, you have to deal with all the other aspects that come along with a platform, and those are stuck in a time warp.

While the fundamental ideas of Lisp are as fresh today as ever, fresher than the ideas of more mainstream languages as any Lisper will tell you (endlessly), the non-fundamental aspects of Lisp, such as the myriad design decisions in the Common Lisp version of Lisp, reflect design decisions optimized for the constraints of the computing industry of the Apollo Space Program era.

The fresh, powerful, timeless, amazing ideas of Lisp are inseparably intertwined with obsolete baggage (technical and marketing) that users of mainstream languages don't want to, and don't have to, deal with.

A New Lisp, where the timeless aspects are retained, but the other design and marketing decisions reflected today's circumstances could be terrific. Paul Graham has been talking about that for years now, essentially preempting anybody else by increasing their risk of irrelevance while refusing to deliver so much as an annual status report.

Any mention of a New Lisp to Common Lispers is like throwing water on a cat. They hiss and shriek that Common Lisp is so close to perfection that nothing needs to be changed beyond "a few libraries". It seems they have to convince themselves of that because there is so little life in the Lisp community that no one CAN produce a new Lisp. They're stuck with the old one, so they elevate it to almost the status of a religion. Those who require a more modern complete system leave Lisp (for inferior languages in superior systems), and only the True Believers remain to console one another and hiss at outsiders who ask the natural questions about the emperor's wardrobe.

What a mess....

Re:Static code verifications, anyone?

[NetSettler]

There is quite a lot I could say about this, but I'm going to focus here on just one point:

Managers would care a lot less about handling runtime errors if static languages didn't just plain segfault when they get them. Error handling in non-Lisp languages is so bad that of course people outside of Lisp are obsessed with handling errors. Even Java, which drew from Lisp in its design, failed to pick up the notion of "restarts" and so only has the throw-style environment=wrecking error handling. That is severe and it's no wonder managers think it matters.

Also, the number of NULL problems you get in many static languages all by itself makes me distrust the confidence factor that managers put in static compilation. The number of wrong-type-data problems I've seen in Lisp pales by comparison to this one unchecked "detail" in these static languages.

And besides, there are other kinds of errors you can get that are just as severe but not as easily seen as type errors, and that lots of times people in static languages don't check for because they're so relieved their program runs at all. While Lisp programmers, not having this safety net, write much better tests. Tests for things other than just type match and nullness, I mean. Tests to do things like see whether the answer is right--because it's so much more easy in Lisp to represent and manipulate data that it's much easier to write GOOD test cases.

I think the process of managing Lisp projects is simply different than managing C++ projects There are a lot of details that they should account for quite differently if they want a successful outcome. This is only one of them. The paradigm shift is noticeable, I'll grant you that. But I'm not sure fixing it by making Lisp just do what other langauges do is the right fix.

Re:Tcl/Tk RULES!!!

[OOGG_THE_CAVEMAN]

Tcl however lack the "robust abstraction" nature of Lisp. Instead, has "everything a string" nature.

Personally, OOGG feel any language where "value of variable" needs $ notation is severely brain-damaged. Absolute opposite of abstraction.

Re:Oh things would have different alright...

[brpr]

No, what's given rise to the sluggish crap is implemeting everything in C. Take Gtk, which would be much faster if it was written in a language which actually supported its object model. As it is, the code's clogged up with kludges to string together some kind of OO support and it's slower than it would be if it had been written in C++.

And, although I don't expect you'll listen, Lisp is an efficient language. It compiles to fast machine code.

Re:Static code verifications, anyone?

[Fahrenheit 450]

Well, it appears to be worth next to nothing. What we have there is some guy looking at a few of his projects and deciding he doesn't need static type checking. And it's not completely clear if he makes this claim because he's not making type errors, or because his type errors are being caught by his unit tests.

He also makes a somewhat odd set of claims that:
a) He doesn't make type errors.
b) Dynamically typed code is easier to develop because he doesn't have to deal with build time type issues.

But... if he wasn't making type errors, then why would he have build time issues with static type-checking? I suppose I might be missing something, but what?

In any case this isn't even up to the fuzzy quality of Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity (PDF) or the less fuzzy Are Ours Really Smaller Than Theirs? (PDF). It's just some guy and his hunch...

Re:How about OS interaction

[cstacy]

"clisp" is the name of one implementation of ANSI Common Lisp. There are many implementations of ANSI Common Lisp, and each of them has its own proprietary extensions. "clisp" is unusual in that it is an interpreter (rather than a compiler).

If you're asking how to manipulate OS processes in Common Lisp in general, the answer is that it is not defined by the ANSI standard. (The reason for this is that each operating system has a different idea what a "process" is, what you can do with them and how you do it, some operating systems don't have processes at all, etc. Processes are beyond the scope of the ANSI standard.) So each implementation does it slightly differently. The leading commercial implementations, in particular, have all these kinds of facilities, and they are portable across operating systems (Mac, Unix, Windows). So if you write your program to those APIs, your program will run on all operating systems.

If you really meant "clisp", and you want to use their proprietary interface for this, then refer to the documentation entitled, "Implementation Notes". These notes are not about the internals of how clisp is implemented, but rather about the implementation-specific extensions to the language. (That label on their documentation confused me!) These notes come with your clisp distribution.

If that's not acceptable, because you didn't mean "clisp", or you really need portability not just across operating systems, but also across different vendors' implementations of Common Lisp, people have written libraries which give you portable APIs to things like process manipulation (and network sockets, multiprocessing, and so on).

These kinds of libraries are much easier to write in Lisp than in other languages. However, I don't know where to get the particular portability library (process manipulation) that you are seeking. I wrote my own. Maybe they are harder to find because it's so easy for people to write their own, but then people don't want to publish them for free. (Or maybe most people are just not writing programs that do a lot of process manipulation. Or they're happy with the non-portability of their programs and consider whatever solution they're using to be "practical" enough.) Anyway, here are some links to places I'd recommend exploring. I don't know if they've got what you want burried in there or not.

• Common-Lisp-POSIX
• ACL Compat (various interfaces)
• CLOCC PORT (shell/pipe interfaces)

A third solution to your problem, and maybe this is what you're looking for, is that you can just make Unix (or other C-language compatible) calls yourself directly from Common Lisp. The portability library for this is UFFI, the "Universal Foreign Function Interface". You will have to write a function-prototype for the function that you want to call. There might be issues with Unix signals or something. Your code will run in pretty much any ANSI Common Lisp implementation, on any operating system. (The not-yet-identified-maybe-hypothetical portability library for doing process/pid manipulation would itself be written using UFFI library. Not sure if anyone bothered. Extensive libraries for things like SQL database access has been written using UFFI, also.)

Not having a comprehensive one-stop shopping place for libraries and OS interfaces is one of the things lacking in Common Lisp. Java and Perl have done a somewhat better job in that area, so far.

Some other good places to look around for libraries and solutions are:

• Your vendor's proprietary portable interfaces
• CLiki, The Common Lisp wiki
• The Common Lisp Cookbook

Re:Talking to the OS

[be-fan]

It depends on the compiler. Nearly all Lisp systems have what's called an FFI, to access native libraries. Interpreters like Clisp have the runtime intercept ffi calls, and call the shared library. Compilers that compile to native code just use whatever ABI is specified by the platform. The system just sees machine code, it has no idea whether that code comes from cmucl or gcc.

Re:Static code verifications, anyone?

[be-fan]

It's not an odd claim to say that he doesn't make type errors. Generally, if you're rigorous about the design of your system, the types fall out naturally. It's also important to note that Lisp code generally uses far fewer types than Java code. Java code makes a new type for everything, because that's the only real expressive mechanism Java has --- classes. Lisp is far more expressive, so types are generally created when the problem domain requires it. Thus, it's much more clear and obvious what the types of an expression are at any given point, which minimizes errors.

Ask a Python programmer how often he makes type errors. After the first few weeks of using Python, I realized I very rarely made type errors. That's partly because my code was much simpler, shorter, and more logical than the equivalent C++ or Java code.

As for (b), the insight your missing is type checking is fundementally a way of declaring a contract. The problem is that C++ and Java force you to declare that contract whenever you use a variable, instead of just when it makes sense. Consider a producer/consumer problem where the product is passed between some number of intermediaries. Logically, type contracts only need to be enforced between the producer and the consumer --- the intermediaries don't care what the types are. In C++/Java, you can't do that. You're either forced to pick a type, and then forced to change all the intermediaries when the producer/consumer changes, or you're forced to create yet another class heierarchy, just to insulate the intermediaries from those changes. That's why Java code tends to have such overengineered heierarchies --- the language prevents the programmer from making more rational ones. Think of why every popular Java IDE has a tool to automatically 'refactor' the code when a type changes. If you think about it, it's an enormous hack. It's just an automated way to do grunt-work that is only necessary because the language is too limited to express what the code really needs to say.