off-topic: Why is lisp so weird?

[Robert STRANDH]

Finding an algorithm is an analytical exercise that's completely abstract of the
programming environment -- and of programming. Unless one doesn't understand
algorithm analysis, there's no need to "explore" the behavior. In those sadly
too numerous cases where the programmer doesn't understand algorithm analysis,
both time and money would be better spent sending the individual to an
algorithmics class at the local university than they would giving that person a
tool that lets them experiment. Let me repeat this: you do not find better
algorithms more easily with one language than you do with another.

I disagree. Not all (not even most) algorithms are examples of what
is taught in algorithms classes, nor can most algorithms used in a
complex program be easily analyzed in terms of traditional asymptotic
complexity.

In fact, there is a large, gray zone of algorithms that are specific
to a system, and that are best explored by coding them up and
observing their behavior (execution time, memory consumption) on real
data. Such experimentation requires a language that lets you write
such experimental code with very little effort, and that lets you
write code that is not critical in terms of execution time faster, so
as to allow more time to spend on critical parts of the system.

Therefore, a language that forces you to pay attention to low-level
issues in all parts of the system will take time from more important
work on crucial algorithms in a few, critical parts. Think of
assembler, that forces you to pay attention to things like parameter
passing and where you put local variables. It is the same with
higher-level languages. Some languages forces the programmer to pay
attention to low-level aspects of the system that other languages will
handle automatically.

In fact, there is a wonderful example of this phenomenon that was
presented at ILC 2002 (see for instance
http://www.paulgraham.com/carl.html). The predecessor was written in
assembler (for speed) and required a large number of mainframes to
run. Thanks to a programming language that allowed more clever
algorithms to be explored more easily (and less time spent on
unimportant stuff), the new system runs on PCs with GNU/Linux on them,
and it is much faster than the predecessor.

 

[Tayssir John Gabbour]

Finding an algorithm is an analytical exercise that's completely abstract of the
programming environment -- and of programming. Unless one doesn't understand
algorithm analysis, there's no need to "explore" the behavior. In those sadly
too numerous cases where the programmer doesn't understand algorithm analysis,
both time and money would be better spent sending the individual to an
algorithmics class at the local university than they would giving that person a
tool that lets them experiment. Let me repeat this: you do not find better
algorithms more easily with one language than you do with another.

Here, I think you'll find that multiparadigm programmers will disagree
with you. _Multiparadigm Programming in Leda_ by Timothy Budd argues
that different paradigms will make some solutions more obvious and
less painful to conceive.

He mentions the Sapir-Whorf hypothesis; and though he doesn't mention
the Leibniz/Newton notation schism, I think it's apropos. (And I hope
it is not an urban legend.

Also it argues that the software crisis (where Moore's Law kinds of
advances are increasingly eaten up by the need to manage complexity)
http://en.wikipedia.org/wiki/Software_crisis
is due to singlemindedness in paradigms. Iterative programming is
about getting results through the gradual transformation of state. It
is definitely not the most natural solution-space for every problem,
though it does excel at some.

Now, I do think one will find it an uphill battle to argue that a
general purpose language should be singleparadigm when given a
sufficiently reasonable multiparadigm choice.

 

[Matthias Buelow]

Anyway, if speed of execution is the most important thing to
your application, then Lisp may not be the best choice.
Lisp performs okay (or even "well"), but speed is not
what it is optimized for.

From my own experience, CMU CL can generate code that is en par with
gcc-compiled C, if you take some care when programming. IMHO the "Lisp is
too slow" problem is something that has been solved, generally, for at least
10 years, if you take a commercial grade implementation. Of course there
very likely are special cases where this does not hold.