Re: ARC

[Paul Graham <address@hidden>]

Dylan has some good qualities, and I'm sure Arc will end
up doing many things the same way (ditto for CL and Scheme).

My main gripe with Dylan is the pervasive object-orientedness.
I would rather have simpler ideas at the core of the language, 
and let people build fancy OO systems as libraries.

As for syntax, we do plan to have it as an option in Arc,
but as a way to abbreviate s-expressions, not to appeal
to the programmers of the world.  (There are enough
languages designed for them already.)

I agree with you about development enviroments.  My personal
favorite is vi + load.

There will be lots of libraries of course, esp.for things
useful to Web-based apps.

--pg

--- Drew Whitehouse <Drew.Whitehouse@anu.edu.au> wrote:
> 
> 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


__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1