do...until wisdom needed...

[Douglas Alan]

"Rainer Deyke" <root at rainerdeyke.com> writes:

> "Douglas Alan" <nessus at mit.edu> wrote:

> > Regarding the parentheses thing -- I don't know why some people don't
> > like that.  I think that if people had an open mind, they would see
> > that Lisp's notation has its own beauty.  On the other hand, many
> > people don't have an open mind; for instance, many people I've talked
> > to summarily dismiss Python merely on the basis that it uses
> > whitespace to determine nesting.

> I think it has less to do with abstract "beauty" and more with the
> way the human brain processes information.

I'm more dyslexic than most, and I can say with surety that for me
Lisp's syntax is easier to process than that of most programming
languages, with perhaps the exception of Python.

> In Python (and to a lesser degree most other programming languages),
> the shape of a program gives you a lot of informtion about its
> structure.

This is certainly true of Lisp too.  Because Lisp has so many
parentheses, Lisp programmers know that good indentation is very
important.  Consequently, the parentheses end up looking rather
translucent once you get used to the syntax and you end up reading the
code a lot like you'd read Python code -- by its shape.

> This is not true in Lisp.  Given a form '(a b)', you can't even tell
> if 'b' is evaluated without looking at 'a'.

But all you have to do is look at 'a' to tell what the form is.  This
makes things easier to process.  In Scheme, for instace, you can
instantly tell that this is an assignment:

   (set! long-variable-name1 long-variable-name2)

In Python, the equivalent is

   long_variable_name1 = long_variable_name2

This means that you have to scan down to see the "=" before you even
know what kind of statement it is, while in Lisp you know right away.
In C, it's even worse, where you have things like

   longDataTypeName longVariableName;

If you've never heard of "longDataTypeName", you might have to stare
at the above for quite a bit of time to even be able to figure out
what type of statement this is.

> More generally, you can't tell if anything is evaluated without
> looking every single enclosing form.  This is the result of only
> having a single all-purpose syntactic form to express anything and
> everything.

I agree that it would have been better if there had been a different
syntax for special forms and for function calls, to make determining
the difference between the two a bit easier.  Perhaps something like
this:

[define (fact x)
  [if (= x 1) 1
      (* x (fact (- x 1)))]]


Instead of

(define (fact x)
  (if (= x 1) 1
      (* x (fact (- x 1)))))

|>oug