Functional - Re: Why stay with lisp when there are python and perl?

Author

Re: Why stay with lisp when there are python and perl?

Xah Lee

2007-05-03, 7:04 pm

Nameless wrote:
=C2=AB
Python has readable syntax, a huge library, and bindings for what
seems like every major in linux. Perl has CPAN. It seems with those
languages if you want to do something all you have to do is import
functionality from a library someone had written and use that.

In lisp you'd have to "roll your own".

Why should I keep on learning lisp when there are python and perl?
=C2=BB

You question is a valid question. Unfortunately, so far in the 14
replies in the thread, vast majority are one-liner drivels from
reactionary lisp XXXXheads, many of which long time dwellers of
comp.lang.lisp. A common scene in any programing newsgroup. They feel
attacked, reasonably by your irrespective and incentive tone, and they
have the need to sputter drivel back, to entertain themselves. (I wish
perl and python programers take a glimpse of that thread to realize
what computing factions are driveling behind each other's back)

Although your message is written in a taunting style, but it has a
valid point, and in fact is a Frequently Ask Question among the vast
majority of programers in the computing industry. Namely, today,
languages like Perl, PHP, and to a lesser degree Python, are so
popular, and ubiquitous, widely deployed and widely demanded in the
job market, and also, that these languages in general and in
comparison to Lisp, have far wide library support and as well as
community support, and also, that these comparatively young languages
are relatively high-level modern languages, that they are at a level
above C, Java, making them ideal for saving programer's time as does
lisp.

So, what are some reasons, if any, should today's programer invest
time into another language lisp (especially it has trivial percentage
in programing job market), while not using the time, to perhaps master
a industrial language they already know, such as Perl, or even venture
into another language like Python, PHP or the new kid on the block
Ruby?

So far, =E2=80=9CD Herring=E2=80=9D and =E2=80=9Cfireblade/bobi=E2=80=9D ha=
s given their personal take
on this question. Lars Rune N=C3=B8stdal, provided a link
http://wiki.alu.org/The_Road_to_Lisp_Survey that details lispers's
stories on why lispers lisp.

Please allow me to give my take, and i believe it is a most important
_technical_ reason, why, Perl, Python, etc languages today simply
cannot replace lisp. And why, if you are a programer with serious
intention of refining your craft, then learning lisp is a good
investment. (one non-technical reason in learning lisp, is that the
widely popular programer's text editor emacs has lisp embedded as its
extension language. As a coder, knowing emacs and lisp, will enpower
you greatly in the long term.)

I think the one most important techincal aspect, that lisp is in fact
superior and cannot be replaced by the current crop of high-level
languages, is the peculiar fact that the language deals with symbols.
Namely, sometimes called symbolic computing.

I have written a exposition on this issue before. It is archived at
this page:
=E2=80=9CWhat is Expressiveness in a Computer Language=E2=80=9D
http://xahlee.org/perl-python/what_...resiveness.html
at the section Symbolic Computation.

There are many =E2=80=9Cpapers=E2=80=9D or articles that address the questi=
on of what
does it mean when someone says lisp is a symbolic language. In my
opnion, they are all fuzzy, or filled with academic jargons that is
practically and most likely theoretically useless. In the following
exposition, you will see what lisp's =E2=80=9Csymbolic computation=E2=80=9D=
in a way
that makes you understand.

I excerpt the section below.

SYMBOLIC COMPUTATION

Lisp differs from most imperative programing languages in that it
deals with symbols. What does this mean?

In imperative languages, a value can be assigned a name, and this name
is called a variable. For example, =E2=80=9Cx=3D3=E2=80=9D, and whenever th=
is =E2=80=9Cname=E2=80=9D is
encountered, it is evaluated to its value. It does not make any sense,
to have variables without a assigned value. That is, the =E2=80=9Cx=E2=80=
=9D is not
useful and cannot be used until you assign something to it.

However, in lisp, there is a concept of Symbols. As a way of
explanation, a =E2=80=9Cvariable=E2=80=9D needs not to be something assigne=
d of a
value. Symbols can stand by themselves in the language. And, when a
symbol is assigned a value, the symbol can retain its symbolic form
without becoming a value.

This means that in lisp, =E2=80=9Cvariables=E2=80=9D can be manipulated in =
its un-
evaluated state. The situation is like the need for the =E2=80=9Cevaluate=
=E2=80=9D
command in many languages, where the programer can built code as
strings and do =E2=80=9Cevaluate(myCodeString)=E2=80=9D
to achieve meta-pro=
graming.

For example, in imperatives languages once you defined =E2=80=9Cx=3D3=E2=80=
=9D, you
cannot manipulate the variable =E2=80=9Cx=E2=80=9D because it gets evaluate=
d to 3
right away. If you want, you have to build a string =E2=80=9C"x"=E2=80=9D a=
nd
manipulate this string, then finally use something like
=E2=80=9Cevaluate(myCodeString)=E2=80=9D
to achieve the effect. If the impe=
rative
language does provide a =E2=80=9Cevaluate()=E2=80=9D function, its use brea=
ks down
quickly because the language is not designed for doing it. It's
extremely slow, and impossible to debug, because there lacks
facilities to deal with such meta programing.

In lisp, variable's unevaluated form are always available. One just
put a apostrophe ' in front of it. In =E2=80=9Cx=3D3=E2=80=9D, the x is a v=
ariable in
the contex of the code logic, x is a name of the variable in the
context of meaning analysis, and x is a symbol in the context of the
programing language. This Symbols concept is foreign to imperative
languages. It is also why lisp are known as symbolic languages. Such
makes meta-programing possible.

The power of symbolic processing comes when, for example, when you
take user input as code, or need to manipulate math formulas, or
writing programs that manipulates the source code, or generate
programs on the fly. These are often needed in advanced programing
called Artificial Intelligence. This is also the reason, why lisp's
=E2=80=9Cmacro=E2=80=9D facility is a powerful feature unlike any so-called=
=E2=80=9Cpre-
processors=E2=80=9D or =E2=80=9Ctemplates=E2=80=9D in imperative languages.

Mathematica for example, is sometimes known as a Computer Algebra
System. It too, works with symbols in the language. They can be
manipulated, transformed, assigned a value, evaluated, hold
unevaluated etc.

One way for a imperative programer to understand symbols, is to think
of computing with strings, such as which Perl and Python are well
known for. With strings, one can join two strings, select sub strings,
use string pattern (regex) to transform strings, split a string into a
list for more powerful manipulation, and use =E2=80=9Cevaluate()=E2=80=9D t=
o make the
string alive. Now imagine all these strings need not be strings but as
symbols in the language, where the entire language works in them and
with them, not just string functions. That is symbolic computation.

Here we see, a expressibility unseen in non-lisp family of languages.

--------------------------
End excerpt.

(if there is some demand, i will add a concrept, little programing
example, that shows, how lisp's symbols and macros concepts, set it
apart from new scripting languages)

This lisp's symbol concept, as far as i know, does not exist in some
other high-level functional programing languages such as Haskell. I'm
not familiar with many functional languages except Lisp and
Mathematica. I'm curious, as to how Haskell, which itself is quite
with capable of symbolic computation i think, deals with it even
though the language doesn't employ the concep of lisp's symbols per
se.

Xah
xah@xahlee.org
=E2=88=91 http://xahlee.org/

Markus E Leypold

2007-05-03, 7:04 pm

Xah Lee <xah@xahlee.org> writes:

> (if there is some demand, i will add a concrept, little programing

No. There ain't.

- M

Jon Harrop

2007-05-03, 10:03 pm

Nameless wrote:
> Why should I keep on learning lisp when there are python and perl?

Lisp compilers are much more advanced, for one thing.

Xah Lee wrote:
> (if there is some demand, i will add a concrept, little programing
> example, that shows, how lisp's symbols and macros concepts, set it
> apart from new scripting languages)

I already did something similar, writing simple programs to simplify
symbolic expressions in different languages:

http://blade.nagaokaut.ac.jp/cgi-bi...uby-talk/239715

Also, here is a symbolic derivative example:

http://codecodex.com/wiki/index.php?title=Derivative

Note that pattern matching (as found in OCaml, F#, Haskell etc.) is very
useful for this kind of term rewriting and is not found in Python, Perl or
Lisp.

> This lisp's symbol concept, as far as i know, does not exist in some
> other high-level functional programing languages such as Haskell.

Correct.

> I'm
> not familiar with many functional languages except Lisp and
> Mathematica. I'm curious, as to how Haskell, which itself is quite
> with capable of symbolic computation i think, deals with it even
> though the language doesn't employ the concep of lisp's symbols per
> se.

In Standard ML, Haskell and F# you must define a sum type that represents a
symbolic expression whereas, in Lisp, you can use the built-in
s-expressions. The sum type that you define typically includes a "Symbol"
that carries its string name. For example, the F# code cited above used:

type expr =
| Int of int
| Add of expr * expr
| Mul of expr * expr
| Var of string with
static member ( + ) (f, g) = Add(f, g)
static member ( * ) (f, g) = Mul(f, g)
end

in this case, "Var" represents a symbol, e.g. the value Var "x" would
represent a variable x.

However, note that the best Lisp implementation of the symbolic simplifier
(by Pascal Constanza) avoids s-expressions, improving performance.

In OCaml, you can rely on the compiler inferring the sum type for you by
using polymorphic variants. However, this is not generally a good idea
because they are slower and harbor some of the di

vantages of dynamic
typing.

It is worth noting that eager, statically-typed languages like OCaml and F#
are many times faster than the other languages at this task. This is
precisely the forte of OCaml and F#, manipulating trees and graphs.

--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/produc...journal/?usenet

Pascal Costanza

2007-05-04, 7:04 pm

Jon Harrop wrote:

> It is worth noting that eager, statically-typed languages like OCaml and F#
> are many times faster than the other languages at this task. This is
> precisely the forte of OCaml and F#, manipulating trees and graphs.

Here is a page that sums up some important observations about
benchmarks: http://www.ccs.neu.edu/home/will/Tw...crock.temp.html

Especially:

- "With modern superscalar architectures, 5-level memory hierarchies,
and wide data paths, changing the alignment of instructions and data can
easily change the performance of a program by 20% or more, and Hans
Boehm has witnessed a spectacular 100% variation in user CPU time while
holding the executable file constant. Since much of this alignment is
determined by the linker, loader, and garbage collector, most individual
compiler optimizations are in the noise. To evaluate a compiler
properly, one must often look at the code that it generates, not the
timings."

- "The execution time of a program is often dominated by the time spent
in very small pieces of code. If an optimizing compiler happens to do a
particularly good job of optimizing these hot spots, then the program
will run quickly. If a compiler happens to do an unusually poor job of
optimizing one or more of these hot spots, then the program will run
slowly."

- "If the hot spots occur within library routines, then a compiler may
not affect the performance of the program very much. Its performance may
be determined by those library routines."

- "The performance of a benchmark, even if it is derived from a real
program, may not help to predict the performance of similar programs
that have different hot spots."

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/

David Formosa (aka ? the Platypus)

2007-05-05, 8:02 am

On 4 May 2007 06:41:20 -0700, Kay Schluehr <kay.schluehr@gmx.net>
wrote:
> On 4 Mai, 14:37, "David Formosa (aka ? the Platypus)"
><dform...@usyd.edu.au> wrote:
[...]
>
> Very doubtfull. When you have not been previously a good programmer
> with your one language it is unlikely that you don't produce
> confusion

I am of the view that programing ability has little to do with
knowlige of language and more to do with the ability to turn solutions
into data-structurs and algorythums.

> and havoc when you know a dozend. I prefer to collaborate with people
> who know one language well over those who know a little bit of
> everything.

Who said that they wouldn't touch a monoligistic programer with a
barge pole?

Sponsored Links