[yummyfajitas]

Python is a primarily imperative/OO language. Good python code consists of writing loops and building objects. Syntactic abstraction consists primarily of looking up strings in obj.__dict__. Whenever more complicated metaprogramming is needed, strings are parsed.

    "obj__parent__name_eq"=foo

is django for

    obj.parent.name == foo.

Mathematica is a primarily functional language. The primary abstraction method is patterns (macros), which allow you to modify/build up the parse tree before evaluating it.

http://reference.wolfram.com/mathematica/guide/Patterns.html

I've programmed Python and Lisp, and have begun writing some projects of reasonable size in Mathematica. There are only a couple of major differences between Mathematica and lisp. One is syntax: f[a,b,c] vs (f a b c), as well as some infix syntactic sugar. The other is that arrays are used far more widely in Mathematica than in lisp (but that may be due to the problem domain of mathematica).

[gaius]

But you haven't answered the question. Why Mathematica and not Lisp + some libraries? Or (+ Lisp Libraries). Again, there are many organizations willing to adopt any language that will give them some extra leverage. Lisp just doesn't appear. The explanation that the average programmer just isn't smart enough is easily demolished by pointing out the C++ (and APL, and Haskell) users. So either we're all missing something or the elephant in the corner is that Lisp just isn't that useful for commercially relevant problems. Which is not to say it's a bad language, but that it's not the "secret sauce" everyone's looking for.

[yummyfajitas]

Actually, the question you are asking is "Why mathematica and not Common Lisp or Scheme + some libraries?"

Mathematica is lisp + a bunch of a math libraries + vendor support + slightly different syntax + renamed functions. The syntactic differences:

    {a b c} -> '(a b c)
    f[a,b] -> (f a b)
    a == b -> (Equals a b)
    (* comment *) -> ;;comment

Since there is no advantage to different syntax and renamed functions, people choose mathematica over other lisps (and grumble about the weird syntax).

[andrewcooke]

i agree with your main point (python isn't lisp because it doesn't have macros). but the language nerd in me can't resist commenting on your example from django. that's a very special case. it's hard to think of any other package that uses that approach. rather, the way people solve problems in python that you would solve in lisp with macros is by late binding, introspection, and higher order functions. none of these replace macros entirely, but together they can be hacked into a solution.