Why stay with lisp when there are python and perl?

[Jon Harrop]

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