1.3.2.1 Syntax: The Dylan Decision
Eric Kidd
The Dylan decision:
  • Well, not that many people use macros, and not that many people need to view their code as a data structure. On the other hand, a very large group of programmers just don't like fully-parenthesized prefix languages. So we'll make the macro system painful and please the largest number of day-to-day coders.


Here is the full talk
Michael T. Richter
I had gathered that from my Scheme hacking (before (I got (tired)(of  (the)) fingernail) parings which (seem constantly (to) litter) Lisp-like > code).
Eric Kidd
Indeed. But there's a reason for all those parentheses--they make the macro system elegant and easy to understand.
Dylan has a convenient infix syntax, but you'll pay for it five times over when you try to write big macros. This is probably the right tradeoff in practice, given that people don't seem to like fully parenthesized prefix languages very much.
Michael T. Richter
This strikes me as bass-ackwards.  The macro system -- a component which will not be frequently opened up by most programmers -- is made easy at the expense of making the day-to- day code everyone will use most of the time  difficult to read and maintain.
From a design perspective this gives me chills.
 
You have to understand that a lot of people around here have written and maintained very large, real-world systems written in LISP. You've programmed a bit in Python, which will help me explain the viewpoint of the typical LISP programmer.

In Python, white space is significant:
def factorial (x):
    if (x == 0):
      return 1
    else:
      return x * factorial(x - 1)
This looks a little bit odd at first, but it works quite well in practice. The Common LISP function looks very similar:
  (defun factorial (x)
    (if (eql x 0)
      1
      (* x (factorial (- x 1)))))
Now, I've written a lot of LISP code in the past two years. Here's how my eyes see that function:
  defun factorial (x)
    if (eql x 0)
      1
      * x (factorial (- x 1))
Like Python programmers, LISP programmers rely almost entirely on whitespace. This is why LISP programmers get vicious if you indent your code incorrectly--they don't *ever* want to count parentheses.
A good LISP editor does two things. It indents your code for you according to the One True Style, and it balances parentheses. I've written thousands of lines of LISP code without ever thinking of how many )'s appear at the end of each function--I just keep hitting Shift-0 until the correct ( flashes.
Since professional LISP programmers don't see and don't think about the parentheses, nobody thinks of them as a drawback. Since they're not considered a bad thing in and of themselves, it's acceptable to choose them as part of another design tradeoff.
The LISP decision:
  • We can have really powerful macros and actually think of our code as a   data structure. The only price we pay is a bunch of parentheses, which we happen to like anyway. Seems like an obvious enough choice. ;-)
The Dylan decision:
  • Well, not that many people use macros, and not that many people need to view their code as a data structure. On the other hand, a very large group of programmers just don't like fully- parenthesized prefix languages. So we'll make the macro system painful and please the largest number of day-to-day coders.
To be fair, neither design is really "chilling". They just proceed from a different set of constraints.
Top