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

Discussion in 'Python' started by Xah Lee, May 3, 2007.

  1. Xah Lee

    Xah Lee Guest

    Nameless wrote:
    «
    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?
    »

    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 fuckheads, 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, “D Herring†and “fireblade/bobi†has given their personal take
    on this question. Lars Rune Nøstdal, 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:
    “What is Expressiveness in a Computer Languageâ€
    http://xahlee.org/perl-python/what_is_expresiveness.html
    at the section Symbolic Computation.

    There are many “papers†or articles that address the question 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 “symbolic computation†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, “x=3â€, and whenever this “name†is
    encountered, it is evaluated to its value. It does not make any sense,
    to have variables without a assigned value. That is, the “x†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 “variable†needs not to be something assigned 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, “variables†can be manipulated in its un-
    evaluated state. The situation is like the need for the “evaluateâ€
    command in many languages, where the programer can built code as
    strings and do “evaluate(myCodeString)†to achieve meta-programing.

    For example, in imperatives languages once you defined “x=3â€, you
    cannot manipulate the variable “x†because it gets evaluated to 3
    right away. If you want, you have to build a string “"x"†and
    manipulate this string, then finally use something like
    “evaluate(myCodeString)†to achieve the effect. If the imperative
    language does provide a “evaluate()†function, its use breaks 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 “x=3â€, the x is a variable 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
    “macro†facility is a powerful feature unlike any so-called “pre-
    processors†or “templates†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 “evaluate()†to 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

    ∑ http://xahlee.org/
     
    Xah Lee, May 3, 2007
    #1
    1. Advertising

  2. Xah Lee <> writes:

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


    No. There ain't.

    - M
     
    Markus E Leypold, May 3, 2007
    #2
    1. Advertising

  3. Xah Lee

    Jon Harrop Guest

    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-bin/scat.rb/ruby/ruby-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 disadvantages 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/products/fsharp_journal/?usenet
     
    Jon Harrop, May 4, 2007
    #3
  4. Xah Lee

    Mark Tarver Guest

    Lisp for the C21

    QUOTE
    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?
    UNQUOTE

    I can see where this guy is coming from (though I can't find the
    original post any more (?)).

    See my remarks on the Lisp for the Twenty First Century

    http://www.lambdassociates.org/lC21.htm

    for our take on this one.

    Mark
     
    Mark Tarver, May 4, 2007
    #4
  5. Xah Lee

    Tim Bradshaw Guest

    On May 4, 3:06 am, Jon Harrop <> wrote:
    >
    > Lisp compilers are much more advanced, for one thing.


    Though I hesitate to respond in this thread (and I didn't actually
    read the rest of the article) there's actually a valid point here.

    The last programming job I did involved doing some search stuff in
    Python. I think Python had been chosen for almost (but actually not)
    good reasons - people really wanted to use Lisp but it would have been
    too hard (politically and technically), and the same people had recent
    first-hand experience of some of the worse horrors of J2EE programming
    so were negative about Java. Finally Python actually had the required
    stuff (the ability to mmap files was critical to the proposed
    technique for doing the search). (The reasons were actually not good
    because Java could have done it as well, and if we'd had the courage
    we could have done a POJO-style Java thing which would have been fine
    and set a good example to other people, which as it was we failed
    dismally to do. On the other hand they'd not have hired me - despite
    the fact that even by then I didn't care about language choice with a
    few exceptions (C++), I didn't look enough like a Java person (and
    still don't of course).)

    Anyway the experience of writing in Python was kind of interesting.
    It had the usual single-implementation issues common to such things
    which meant we depended on the right version (and I think a later
    version than the one shipped with the OS since they'd decided to
    change semantics in some quite major way at some point). But apart
    from that writing programs that performed well (for us - we actually
    had performance issues since we wanted to look at a lot of data)
    turned out to be a matter of making sure that all the performance-
    critical bits were done in libraries (in C) with Python merely a kind
    of elaborate glue to get in the way. It was a bit like writing code
    for an array processor or a DSP or something, except without any good
    hardware reason for it. So one of the things I learned was "use a
    language with a decent compiler"[*] I think.

    --tim

    [*] No glib comments about Java not having a decent compiler: actually
    typical implementations do now (or did in 2004/5 and I bet they are
    better now).
     
    Tim Bradshaw, May 4, 2007
    #5
  6. Xah Lee

    Tim Bradshaw Guest

    On May 4, 10:13 am, Tim Bradshaw <> wrote:

    > Anyway the experience of writing in Python was kind of interesting.
    > [...] So one of the things I learned was "use a
    > language with a decent compiler"[*] I think.


    Bugger, I did not realise until too late that this was going to
    comp.lang.python as well. I should therefore add a caveat: Use a
    language with a high-performance (this is what I meant by "decent")
    compiler if that kind of performance matters to you. It did to us,
    but there are very many cases where it does not. In other words,
    despite appearances I'm not particularly trying to slag off Python.
     
    Tim Bradshaw, May 4, 2007
    #6
  7. 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/Twobit/bmcrock.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/
     
    Pascal Costanza, May 4, 2007
    #7
  8. Nameless wrote:
    > Why should I keep on learning lisp when there are python and perl?


    The more programing languages you know the better programer you will
    be. Lisp can teach you a number of key things that are required to
    be a good programmer in any of the P* lanuages.
     
    David Formosa (aka ? the Platypus), May 4, 2007
    #8
  9. Xah Lee

    Paul Rubin Guest

    Re: Lisp for the C21

    Mark Tarver <> writes:
    > See my remarks on the Lisp for the Twenty First Century
    > http://www.lambdassociates.org/lC21.htm


    Anyone who didn't love lisp in the 20th century has no heart.
    Anyone who still loves it in the 21st, has no head.
     
    Paul Rubin, May 4, 2007
    #9
  10. Xah Lee

    kaens Guest

    kaens, May 5, 2007
    #10
  11. Re: Lisp for the C21

    On 2007-05-04 11:32:14 -0400, Paul Rubin <http://> said:

    > Anyone who didn't love lisp in the 20th century has no heart.
    > Anyone who still loves it in the 21st, has no head.


    By the same logic we should all be conservative Republicans. Given this
    implication, I'll stick with lisp, thanks.
     
    Raffael Cavallaro, May 5, 2007
    #11
  12. Xah Lee

    Bart Willems Guest

    Xah Lee wrote:
    > blah blah blah blah blah lisp blah blah blah
    > blah blah lisp blah blah. Blah blah? Blah blah!
    > blah blah blah blah blah;
    > 1) Blah lisp.
    > 2) Blah blah.
    > 3) Blah lisp blah.
    > blah blah blah blah blah. Blah blah lisp! Blah lisp!
    > Blah lisp! Blah! Blah blah blah! Lisp blah blah!


    Ok. I give up. WTF is this being cross-posted in the Python forum?
     
    Bart Willems, May 8, 2007
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rocky Moore

    Bottom bar needs to stay there!

    Rocky Moore, Oct 8, 2003, in forum: HTML
    Replies:
    7
    Views:
    512
    Rocky Moore
    Oct 10, 2003
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,071
    Smokey Grindel
    Dec 2, 2006
  3. ekzept
    Replies:
    0
    Views:
    386
    ekzept
    Aug 10, 2007
  4. nanothermite911fbibustards
    Replies:
    0
    Views:
    387
    nanothermite911fbibustards
    Jun 16, 2010
  5. nanothermite911fbibustards
    Replies:
    0
    Views:
    328
    nanothermite911fbibustards
    Jun 16, 2010
Loading...

Share This Page