Re: Is Lisp a Blub?

Don Geddis wrote:
Pascal Costanza <pc@xxxxxxxxx> wrote on Mon, 02 Jul 2007:
This is one of Paul Graham's worst text fragments, IMHO (the rest of "Beating
the Averages is quite good, though). You can only relate to it when you think
that you're "up in the power continuum." However, you may simply not know
that others are even "higher" in the "power continuum." There are essentially
two possibilities: Either another language is worse than the one you prefer,
or you simply don't understand it, in which case it simply _appears_ to be
worse to you. This effectively means that, if you think that another language
is worse than the one you prefer, you simply cannot draw any
conclusions.

I understand this perspective, and to a large extent, agree with it.

Let me try to express it a different way. If you talk to somebody that has
only programmed in C, and try to explain the benefits of having a built-in
garbage collector, they often just "don't get it".

It seems to be the case that for ultra-large-scale programs, garbage collection is not feasible anymore. (That was also the message in Jans Aasman's talk at ILC'07.)

Don't understand how it
would aid programmer productivity. Similarly, a Java-only programmer might
not get the power of macros.

Gregor Kiczales most certainly knows about the power of macros and argues against them: http://www.ddj.com/dept/windows/184415142 (Note that I disagree with his position, it's just to note that views may differ even when knowing about the benefits.)

In both cases, most Lispers respond with a "higher power" argument: these are
tools that are useful in almost EVERY domain (not just one limited
application), and if you can't appreciate it, it probably means you don't
understand it.

The problem here is that you seem to confuse "higher power" with "better". Not every increase in expressive power makes a language better. For example, Common Lisp forbids changing source code by way of side effects (a practice that was apparently common in previous Lisp dialects). That's clearly a decrease in expressive power, but generally considered an improvement of the language.

If it were that simple, that more expressive power equals better language, then we could just look for the most expressive language and be done with it. Unfortunately, this is not so.

This ultimately means that the decision for or against a language is ultimately a subjective one, and depends highly on personal preferences. For example, some of my colleagues definitely have a very good idea about the expressive power of Lisp and Scheme dialects, but prefer to work in Smalltalk because of its minimal set of basic language constructs and _because_ there is no straightforward way to extend the language (not in spite of that fact). They have good reasons for that (to which I don't agree, but this doesn't prevent me from acknowledging their reasons).

So, I'm interested in avoiding this C/Java limited vision, but coming from
a Lisp background instead. I agree completely with you that Graham provides
no constructive way to tell the difference. He doesn't aid you at all in
understanding where you are in the middle of the power spectrum of programming
languages.

Yes, and it's important to understand that this is a dangerous position to take. You should be able to explain your preferences, and not just say "I know better than thou", without giving any good reasons. The latter is just condescending.

We all made the experience that we were wrong about some of our choices in the past. It is not so unlikely that we are still wrong, at least in some regards.

Computer science is only a couple of decades old. It would be a great surprise if we already know everything there is to know about it.

Lispers often believe themselves to be "at the top", or at least nearby.
I'm looking for pointers to generic programming language concepts that might
possibly indicate a higher-power language, but which are missing from Lisp.
Pattern-matching programming is at least a valid candidate. Prolog-style
unification and inference probably is too.

Is it so absurd to try to look beyond Lisp at programming in the abstract?

No, many of us are doing this all the time.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
.

Relevant Pages

  • Re: Computer Algebra Algorithms
    ... If you want to learn CAS, learn lisp because that is what the ... The parser could be written in C or any other language. ... I would consider that such a minor aspect of a programming ... generally prefer righting there numeric algorithms in Maple and MATLAB ...
    (sci.math.symbolic)
  • Why should I care about Lisp and Scheme?
    ... Foreword to the book "Essentials of Programming Languages". ... It's an imaginary conversation between a newbie and a hacker. ... Why should I care about Lisp and Scheme? ... language, the result would be a Lisp interpreter. ...
    (comp.lang.scheme)
  • Re: F#
    ... Why did they take Lisp? ... properties of the language are only a part of the picture. ... If the favored programming style of a certain language ... Knowing a success story only tells me that other people ...
    (comp.lang.functional)
  • Re: Opinions on intro lisp books
    ... But Lisp is a little different, ... Some languages support one style of programming better than they ... Even if that weren't the case, I'm not sure that a language being a ... I don't believe that learning to program in CL requires more theory ...
    (comp.lang.lisp)
  • [ANN] 2nd European Lisp & Scheme Workshop
    ... Pascal Costanza, Programming Technology Lab, Vrije Universiteit Brussel ... Lisp has a tradition of providing a fruitful basis for language design ... and suggestions for breakout groups that discuss the opportunities Lisp ...
    (comp.lang.lisp)