Of course, Common Lisp has the same problem: macros must precede their use points, or it looks like function calls to nowhere. And functions the macros use at expansion time need to have been loaded. And I remember headaches with symbols interning into the wrong packages, but I’m already blissfully forgetting the details — I think that was load-order dependent too?

Saying that having a read-eval-print loop is “a function of the development environment, not of the language”, while almost right in theory, is a lot less relevant in practice.

First, as you say, there really are features in languages that are problematic for the whole REPL concept, such as the distinction between expressions and statements. Lisp also has some features that are mainly there to help with interactive development, such as the print-object method in CLOS. Good introspection features also help support this kind of environment; Java actually does have good introspection but Haskell does not. (Alan Bawden says there is something called “Template Haskell” which is the closest you get to introspection, and is Haskell’s answer to Lisp macros, but it’s not part of the standard.)

Haskell has a more serious problem: the semantics of the program depends on the order in which the top level forms are written, because there is an implicit “if-then-else” structure, and if you change the ordering of the clauses, the semantics of the program can change.

If you are at a Haskell REPL and you type “23″, what happens? It is the job of the Haskell type inferencer to decide whether that’s an Int, an Integer, a Double, or a Float, based on what type the program is expecting. But in a REPL, there isn’t any expectation.

Any one of these things could presumably be addressed, but my point is that there really is a link between the language definition and its suitability for a REPL-Lisp-style development environment.

Furthermore, Alan says that the semantics of a REPL in Haskell is up to the implementation. I guess there’s an interesting question of whether REPL semantics should be considered “part of the language definition” or not. In Lisp, because of the way we heavily use interactive development, it really ought to be, and mostly is (although the spec could be improved). eval-when, for all its faults, at least shows that the language designers were making some attempt to deal those kind of semantic issues.

But Haskell aside, I don’t think it’s just happenstance that nearly all users of the Java language and the C++ langauage do not use development environments that are oriented around REPL’s and Lisp-style interactive development.

In the early Java days, there was a product, whose name I no longer remember, that had a pretty interesting programming environment of this sort. There also was once “Saber C”, a C implementation that provided that kind of programming environment. But you don’t see a lot of use of things like this, and I don’t know of products that you can currently get of this kind for Java nor C.

About two weeks later, I asked some bearded guy (Alan Bawden) about this programming language called lisp. He stopped what he was doing, and gave me a 2 hour lesson, at the end of which, I understood more about programming than I had ever understood before.

For those of you that remember me as “the suspicious looking guy hanging around a CADDR on the 4th floor”, I thank you for an incredible experience in innovation and imagination, and I thank you for the attitude that allowed me to learn at a rapid pace in a rich environment.

It worked out well for me and others – I worked with Patrick Sobolvarro and Leigh Klotz at Terrapin, writing the Apple //gs version of Logo, wrote an Emacs clone for the Apple with M-x completion and dynamically loadable libraries, and then worked with rms as his first employee, where I wrote Bash, TeXInfo, and other stuff.

But my favorite experience in the Lab was using Danny Hillis’ AAA60 while he wasn’t around, and asking Hal for help with Emacs. “Emacs is very helpful,” he told me. Just type “M-x apropos”. Unable to find the “meta” key, and unaware of how “apropos” was spelled caused me frustration – but I know those things now!

Well, that settles it, worse really is better! Or perhaps Tom is saying that the best philosophy is no philosophy.

I am not bigoted, I have used Perl successfully. I can write it, I just can’t read it.

Let’s not hijack the thread into a Perl discussion. Probably the important lesson for Lisp from Perl is that making it easy and concise to do the things a particular community wants to do a lot is much more important for success with that community than having a beautiful language design. The technical characteristics of Lisp ought to be very consistent with making it easy and concise to do things, and should not require making programs unreadable to accomplish that. I admit keeping concise programs readable is very hard.

Getting back to worse is better, it’s all about worse in what specific dimension and better in what specific dimension, isn’t it? It’s not a paradox if something is worse in one dimension and better in a different dimension. Abstracted of details Gabriel’s argument is that if a system designer only looks at one of the many dimensions of goodness, and optimizes that at the expense of other essential dimensions, then the result will not be successful overall. At a slightly less abstract level he is saying you can’t be successful if you overengineer and undermarket. Can’t argue with that. (Here by “market” I mean everything connected with who will use your thing and how and why they will use it. This isn’t necessarily just the things marketing professionals say they do.)

Would love to read this, though I’m also curious how Scheme compares as well.

Doesn’t it stand to reason that block comments should nest, so you can comment out a chunk of code without having to tweak the delimiters for block comments within said chunk? It’s clearly TRT. But the WIB design of C said no, we’re not going to bother, and C/C++ users have gotten so used to that that I can’t even persuade my colleagues that it’s an unfortunate choice that should not be copied in new languages.

So, while I understand Moon’s point that a lot of what became Common Lisp was “just hacked up”, I still think it was hacked up from a different design philosophy than that from which C and Unix were hacked up; and I think that block comment nesting is a nice, clear, albeit small, example of that.