"Arc: An Unfinished Dialect of Lisp"
Rich Morin
http://paulgraham.com/arcll1.html
I'm not a Lisp enthusiast, by and large, but I think he makes some
interesting observations on language design. Take a look if you're
feeling adventurous...
-r
--
email: r...@cfcl.com; phone: +1 650-873-7841
http://www.cfcl.com/rdm - my home page, resume, etc.
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Andy Wardley
> I'm not a Lisp enthusiast, by and large, but I think he makes some
> interesting observations on language design. Take a look if you're
> feeling adventurous...
I can't help feeling slightly deflated. Given the chance to re-design
Lisp from scratch, the tasks on the top of my TODO list to address would
be:
* getting rid of some/all those damn parenthesis
* renaming cons/car/cdr to something meaningful
Alas, these are about the only parts he's not changing. He promises that
Arc will have a syntax one day, but there isn't one yet.
The other comments that caught my eye were that Arc is designed for
Good Programmers[tm] and that it was particularly targetted at developing
web applications. Alas, my experience seems to suggest that most of
the people writing web applications are monkeys who would rather have
something designed for Bad Programmers, like PHP.
A
Austin Hastings
--- Andy Wardley <a...@andywardley.com> wrote:
> On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
> > I'm not a Lisp enthusiast, by and large, but I think he makes some
> > interesting observations on language design. Take a look if you're
> > feeling adventurous...
>
> I can't help feeling slightly deflated. Given the chance to
> re-design
> Lisp from scratch, the tasks on the top of my TODO list to address
> would
> be:
>
> * getting rid of some/all those damn parenthesis
> * renaming cons/car/cdr to something meaningful
Actually, sanifying some of the syntax did have the effect of removing
some parens. The other parens are necessary to part of the "philosophy"
of the language: code is data, too.
>
> Alas, these are about the only parts he's not changing. He promises
> that
> Arc will have a syntax one day, but there isn't one yet.
I think that's probably a joke. "Lisp was originally promised a syntax,
and I'm doing a flavor of lisp. If it ever shows up, I'll do it, too."
>
> The other comments that caught my eye were that Arc is designed for
> Good Programmers[tm] and that it was particularly targetted at
> developing
> web applications. Alas, my experience seems to suggest that most of
> the people writing web applications are monkeys who would rather have
> something designed for Bad Programmers, like PHP.
You know, I learned pascal, PETbasic, then PL/I; PICK {basic/asm}, then
Prolog. Then I waited a bit, and learned Perl, at least enough to get
confused a lot on this list.
I'm done with 'P'. That's it. Putative planners of programming
paradigms must proffer some prefix preferable to the pathetic
palimpsest that is 'P'!
=Austin
Sean O'Rourke
> I'm done with 'P'. That's it. Putative planners of programming
> paradigms must proffer some prefix preferable to the pathetic
> palimpsest that is 'P'!
As with operators, so with programming languages -- Unicode comes not a
moment too soon.
/s
Adam Turoff
> On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
> > I'm not a Lisp enthusiast, by and large, but I think he makes some
> > interesting observations on language design. Take a look if you're
> > feeling adventurous...
>
> I can't help feeling slightly deflated. Given the chance to re-design
> Lisp from scratch, the tasks on the top of my TODO list to address would
> be:
>
> * getting rid of some/all those damn parenthesis
> * renaming cons/car/cdr to something meaningful
>
> Alas, these are about the only parts he's not changing. He promises that
> Arc will have a syntax one day, but there isn't one yet.
These slides are over a year old. There hasn't been much of Arc since
Paul Graham's early musings on it. But one of the things he did do was
rename lambda to fn. This is proof that the holy grails can be tossed
out of the window.
The problem with cons/car/cdr is that they're fundemental operations.
Graham *has* learned from perl, and is receptive to the idea that
fundemental operators should be huffman encoded (lambda -> fn). It
would be easy to simply rename car/cdr to first/rest, but that loses
the huffman nature of car/cdr.
Austin mentioned that the syntax has eliminated the need for some of the
parens, so that's a start. Perhaps a real syntax can follow. :-)
> The other comments that caught my eye were that Arc is designed for
> Good Programmers[tm] and that it was particularly targetted at developing
> web applications. Alas, my experience seems to suggest that most of
> the people writing web applications are monkeys who would rather have
> something designed for Bad Programmers, like PHP.
"Good Programmers [tm]" has been a theme of Graham's work. Figure that
less than 10% of programmers make this cut. Lisp hackers like to assert
that good programmers eventually migrate to Lisp or something lisp-like
(er, functional). Count up all of the Lisp/Scheme/ML/Haskell programmers
you know relative to the total number of programmers, and that's the
percentage of web programmers he's targeting.
The fact that a good many web programmers want ASP/PHP doesn't really
have an impact on what he's trying to do. A bigger problem is that
employers demand large numbers of these folks to do the job that someone
Good [tm] could do in a day. Alone. While reading email.
Z.
Tanton Gibbs
> Graham *has* learned from perl, and is receptive to the idea that
> fundemental operators should be huffman encoded (lambda -> fn). It
> would be easy to simply rename car/cdr to first/rest, but that loses
> the huffman nature of car/cdr.
hmm...ML uses hd and tl. I believe that is pretty coded :)
Adam Turoff
Good point. I've used Scheme and Lisp, but not ML...
Z.
Piers Cawley
> On Wed, Jan 22, 2003 at 10:16:50AM +0000, Andy Wardley wrote:
>> On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
>> > I'm not a Lisp enthusiast, by and large, but I think he makes some
>> > interesting observations on language design. Take a look if you're
>> > feeling adventurous...
>>
>> I can't help feeling slightly deflated. Given the chance to re-design
>> Lisp from scratch, the tasks on the top of my TODO list to address would
>> be:
>>
>> * getting rid of some/all those damn parenthesis
>> * renaming cons/car/cdr to something meaningful
>>
>> Alas, these are about the only parts he's not changing. He promises that
>> Arc will have a syntax one day, but there isn't one yet.
>
> These slides are over a year old. There hasn't been much of Arc since
> Paul Graham's early musings on it. But one of the things he did do was
> rename lambda to fn. This is proof that the holy grails can be tossed
> out of the window.
>
> The problem with cons/car/cdr is that they're fundemental operations.
> Graham *has* learned from perl, and is receptive to the idea that
> fundemental operators should be huffman encoded (lambda -> fn). It
> would be easy to simply rename car/cdr to first/rest, but that loses
> the huffman nature of car/cdr.
ISTR that he was also a fan on the 'composibility' of car and cdr,
giving operators like (caar list), which means (car (car list)). I can
see where he's coming from, but I can also see that those tricks could
also be dismissed as clever dickery.
Andy Wardley
> The problem with cons/car/cdr is that they're fundemental operations.
> Graham *has* learned from perl, and is receptive to the idea that
> fundemental operators should be huffman encoded (lambda -> fn). It
> would be easy to simply rename car/cdr to first/rest, but that loses
> the huffman nature of car/cdr.
Good point, but I can't help thinking that list/head/tail or list/item/rest
(for example) would be preferable to cons/car/cdr. More meaning at the cost
of a character or two.
I doubt there are few people who remember, ever knew or even care that
"car" is "Contents of the Address Part of the Register" and "cdr" is
"Contents of the Decrement part of the Register" (yes, I had to look
them up :-). Even when you know what the acronyms stand for, they still
doesn't make a great deal of sense.
A