ARC

[Drew Whitehouse <address@hidden>]

Hello Paul (LL1 people),

I've just read your ARC page and I couldn't resist throwing in my 2
cents worth of rant. 

I'm a Python convert, and use Python for all my work, building modules
in C++ whenever speed is an issue (I do real-time 3d graphics systems
for interactive museum exhibits). I'm an average programmer, not a
language designer. I came to Python via TCL (gave that up pretty
quickly) and Scheme. I ignored Python for years because of its speed,
and the indentation syntax having acquired an arrogant stance that it
was simply bad from a theoretical standpoint. Finally I tried it to
get access to the extensive libraries that come in the standard
distribution. I found out to my surprise that, just like lisp/parens,
it was a non-issue, matter of fact I now love it. It's concise, and
you can read other peoples code immediately, and with emacs (like
as in lisp/parens) handling the indentation is a non-issue.

I think Dylan is a language that should be re-examined (a new lisp
from > mid 80's). It came so close to being a great language. I think
it could be re-worked to become that. It has a far more useful OO
semantics than simple single dispatch, operator overloading, lets not
go backwards. It sits comfortably across the static/dynamic language
fence. Besides the commercial reasons, what went wrong (IMHO) ... I
think it was for simple reasons, to do with human foibles.

1. Syntax!!!

Syntax matters. Language designers are finally beginning to realize
they are designing languages for people, rather than to impress the
Gods. And that means syntax is *extremely important*. The first Dylan
syntax was prefix/parens and hence was doomed to a cool reception, for
reasons that will debated endlessly, but only a supreme optimist would
think that the programmers of the world are about to have an infix
epiphany any time soon (evidence - the success of Java). The second
Dylan syntax was puzzling to say the least, who on earth wants all
that begin/end verbiage. It was like the designers were trying to
punish the unwashed masses who reject prefix/parens syntax, knowing
that the Gods program with complex macros and (((...)))((()))()))).

2. IDE/System Building Infrastructure.

I want a system where I can quickly get at an interpreter with REPL on
a command line, then from an editor like emacs, and finally, maybe,
from a huge graphical IDE. I don't want to have to think before I
start programming (sorry), I think while programming. I want to able
to read code as it was written, not browse it in a hyper-text browser
that wants me to believe all code is naturally OO. I don't want a
build system that gets in the way of executing new code quickly, so no
mandatory LID (library interchange definition) files, makefiles etc. I
want to iteratively develop my code, which invariably starts as messy
little code doodles, and through continual re-factoring ends up as a
clean large system with libraries/modules/packages etc.

So what could be done to make a new lisp that addresses these problems ?

1. Design *two* new syntaxes for Dylan. One for humans (simple,
concise and clean). I suggest anyone who hasn't tried it to program in
Python for a couple of weeks, then tell me that they still hate
indentation syntax. See http://www.norvig.com/python-lisp.html for
inspiration though use the new Python v2.2b2 from www.python.org
(great new features and no serious stability problems) rather than the
Java implemented Jython. Then a second syntax that is prefix s-expr
based and is a straightforward transformation from the infix, so straight
forward that a human, an emacs lisp function, a compiler, can
convert/write/read between them interchangeably. Don't like reading
s-exprs, just C-x C-E the expression in your favorite editor and you
infix syntx, perfectly indented :-) This allows for a macro system to
be s-expr based which I think people think is generally easier to both
implement and write for ?

2. Make it easy to use, simple REPL and a build/module system that
stays out of your face until you need or want it.

3. Make libraries part of the standard distribution. They should be
powerful and well written. A language without a decent set of powerful
stable libraries is not complete. So sockets aren't a part of the
language but they are part of the standard libraries in the
distribution. If you've developed a readable syntax the libraries
source code will be better for learning how to program well in ARC
than a truck load of "ARC in 24 hours", "ARC for Idiots", "Patterns to
circumvent the hairy non-dynamic nature of ARC and make it approximate
lisp" books.

I know there are Dylan developers on this list, what do you think ?

-Drew

-- 
;; Drew.Whitehouse@anu.edu.au      Sci-Viz/VR Programmer
;; http://anusf.anu.edu.au/~drw900          ANUSF VIZLAB
;; Australian National University Supercomputer Facility