merits of Lisp vs Python

[William James]

André Thieme wrote:
> Paul Rubin schrieb:
>  > André Thieme <address.good.until.2006.dec.22 at justmail.de> writes:
>  >> and the Lisp version has only 9:
>  >> nth, 1+, truncate, signum, num, list, pos, zero, neg
>  >
>  > Oh come on, you have to count the parentheses too.
>
> We could define hundreds of way how to count tokens.
> But see the program as a tree:
>
>                       nth
>                      /   \
>                    /       \
>                  /           \
>                 1+          list
>                 |           / | \
>                 |         /   |   \
>             truncate    pos  zero  neg
>                 |
>                 |
>              signum
>                 |
>                 |
>                num
>
> And I didn't count the indentation level and \n in Python code.
> Why should I? They are editor commands.
>
>
>  > Anyway, token count doesn't mean much, you have to instead go by the
>  > user's cognitive effort in dealing with the prefix notation etc.,
>
> How complicated ss it to say "cmp(a, b)" compared to  "a cmp b"?
> After a few days writing Lisp code your brain specializes on that
> style. Arabian countries write from right to left. They seem to have
> no problem to use what they know.
> I admit that I am used to write +, -, * and / infix, because I were
> trained in that thinking since day 1 in school.
> In our example program there was only 1+ compared to ".. + 1" which
> looks "alien" to untrained people.
> If a program uses extensive math we can get syntax for Lisp that is
> even more pleasant to read than Pythons:
> 17a + x³-x²
>
>
>
>  > which isn't purely a matter of token count.  And if (+ 2 3) were
>  > really as easy to read as 2+3, mathematics would have been written
>  > that way all along.
>
> Mathmaticians invented prefix notation and they use it regularily.
> They inventey operators that wrap around their arguments, as one can
> see here: http://www.mathe-trainer.com/formel/?SN=&t=1
>
> Or think of indices, etc.
>
>
>
>  >> TypeError: 'str' object is not callable
>  >> I don't know how I can fix that. Maybe you could tell me.
>  >
>  >>>> lazy_nif(0, lambda: "p", lambda: "z", lambda: "n")
>
> Yes, that works. And that's why I wanted to make it a macro.
> Now you are essentially doing what I did in my first Lisp version.
> While this works it is farer away from what we think.
>
> (nif 0 "p" "z" "n")
> (nif 0 #'p #'z #'n)
> are exactly what one thinks.
> For this reason "if" is implemented as a keyword in Python.
> It allows you to give code as a block instead of embedding it into
> a lambda or a def (which even needs a name).
>
>
> And we might go further (again with an easy Graham example).
> See this typical pattern:
>
> result = timeConsumingCalculation()
> if result:
>    use(result)
>
> We need this ugly temporary variable result to refer to it.
> If we could use the anaphor[1] "it" that could make situations like
> these more clean.
>
> Imagine Python would have an "anaphoric if", "aif". Then:
>
> aif timeConsumingCalculation():
>    use(it)
>
> Many Lispers might have this as a macro in their toolbox after some
> time of coding or after reading Graham.
> A short three-liner in Lisp and I can really say:
>
> (aif (timeConsumingCalculation)
>       (use it))
>
> How would you solve this in Python?
> You could embed it inside a lambda and must somehow make the
> variable "it" visible in it, because in the context of aif this
> "it" gets bound to the result.

In Ruby:

def aif val
  yield val   if val
end

def complex_calc n
  if n % 2 == 1
    n**n
  else
    nil
  end
end

aif( complex_calc( 9 ) ) {|x| puts "hello, #{x}"}
aif( complex_calc( 8 ) ) {|x| puts "hello, #{x}"}

---  output  -----
hello, 387420489