Re: merits of Lisp vs Python

Jon Harrop schrieb:
David Steuber wrote:
Well the editor does the matching. It certainly didn't take too long
for me to stop paying much attention to the parentheses. In fact, I
bet $1 that you are more likely to find superfluous parenthesis in a C
or C like program than in a Lisp program.

That brings me onto another criticism of Lispers: they have a different
definition of "superfluous" to me. Consider the following OCaml/F#:

let a, b = 2, 3 in a + b

and the Lisp equivalent:

(let ((a 2) (b 3)) (+ a b))

The OCaml has no parentheses. That doesn't mean the Lisp's are all
superfluous because OCaml has traded some of those parentheses (e.g.
for "let" and "in") but we need to do a token count. OCaml 12 vs Lisp 18.
So Lisp has 6 "unnecessary" or superfluous tokens. That isn't so important
because the byte count is virtually the same.

I count 12 for both versions. I see the number of elements in the tree:

/ \
/ \
/ \
elements expressions
/ | |
/ | |
/ | |
list list +
/ \ / \ / \
a 2 b 3 a b


/ \
/ \
/ \
= in
/ | |
/ | |
/ | |
, , +
/ \ / \ / \
a b 2 3 a b

But this gets a lot worse when expressions written with conventional syntax
exploit precedence. For example, F# vs Lisp token count:

You are right, math can look messy when a lot of two digit functions
like + or / are involved.
It depends on what one is programming.

Or the sources of AllegroServe (a Common Lisp application server) to see
how much math is involved.
I admit that

a*x*x + b*x + c

looks a bit better than

(+ (* a x x) (* b x) c)

But if I use this 4 times in a program I can accept it.
You know that there are infix macros for Lisp that allow me to write
code as you did in ocaml.

One could even get something that looks better than ocaml:
#i(ax² + bx + c)

There are infix packages, ready for download. The 0,4% of applications
that do a lot of math should maybe really look into them.

So the "Lisp has no superfluous parentheses" doesn't wash with me.

Lisp has on parens at all. The graphical representation of code has.
But in the program tree there are no parens anymore, in opposit to
other languages, like ML or Java.
You editor could support a tree-view-mode, where the program is shown
and written with trees. In a few years one could use modern hardware,
like seen in the Tom Cruise movie "Minority Report" to move code around
with hand moves and views. It could already be done today this way, but
it is too expensive to be done.

clearly sacrifices associativity and precedence for superfluous
parentheses. The only time this pays off is when you've got an operator
applied to lots of elements (e.g. a * x * x vs (* a x x))

The token syntax tree is not longer in Lisp. I showed you several

The usual rebuttal to this is "homogeneous syntax is necessary for
metaprogramming" yet Mathematica, MetaOCaml etc. manage to do
metaprogramming with conventional syntax.

There is a Lisp with a syntax as you know it: Dylan, and it also
supports macros. Other people already explained differences between
Lisp macros and those of Mathematica in earlier posts from you.


Relevant Pages

  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... Still requires explicit deconstruction in Lisp but not in OCaml. ... Only if you ignore the superfluous parentheses that make up most of the ... expression in some language. ... around comma-separated lists, when those lists are to be treated as a ...
  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... (labels ((aux (lam normal scene) ... Note that the Lisp was written by Juho Snellman, one of the authors of SBCL, ... Your pattern match for the list case requires three tokens: ... Only if you ignore the superfluous parentheses that make up most of the Lisp ...
  • Re: "and" operations
    ... I wrote a reasonably functional Lisp interpreter. ... the parentheses, of course, and you can also resort to tricks like ... and gradually moving into other languages. ...
  • Re: right square bracket and repl questions
    ... Some Lisps had a superbracket. ... do you close all objects that have parentheses, ... you cannot recurse into the Lisp reader functions like read-delimited-list, ... This might have to be done at the stream level; ...
  • Re: Big Problem with Scheme
    ... display different parentheses at each level. ... change view of parens in a lisp to be a function of its syntactic ... They should be always entered as a parens, ... editor fails to do lisp-specific ...