Why Arc is bad for exploratory programming...

[xytroxon]

I found this over at reddit:

http://reddit.com/r/programming/info/6jgnp/comments/">//http://reddit.com/r/programming/info/6jgnp/comments/



They are discussing this article:

"Why Arc is bad for exploratory programming" (arcfn.com)

http://arcfn.com/2008/05/why-arc-is-bad-for-exploratory.html">//http://arcfn.com/2008/05/why-arc-is-bad-for-exploratory.html

...The problem, of course, is that Arc lacks libraries. Arc lacks basic functionality such as fetching a web page, parsing an XML document, or accessing a database. Arc lacks utility libraries to parse HTML pages or perform numerical analysis. Arc lacks specialized API libraries to access sites such as del.icio.us or Akismet. Arc lacks specialized numerical libraries such as a support-vector machine implementation. (In fact, Arc doesn't even have all the functionality of TRS-80 BASIC, which is a pretty low bar. Arc is inexplicably lacking trig, exp, and log, not to mention arrays and decent error reporting.)



To be sure, one could implement these libraries in Arc. The point is that implementing libraries detours you from the exploratory programming you're trying to do.



Paul Graham has commented that libraries are becoming an increasingly important component of programming languages, that huge libraries are now an expected part of a new programming language, and that libraries are an increasing important feature of programming languages. Given this understanding of the importance of libraries, it's surprising that Arc is so lacking in libraries. (It's also surprising that it lacks a module system or some other way to package libraries.) It's a commonplace complaint about Lisp that it lacks libraries compared to other languages, and Arc makes this even worse...

-----------



newLISP: The fully functional*, "Functional Language"...



* Dilithium crystals included!

[Jeff]

Arc is just a public preview at the moment.  As long as it's taking to release, it's easily possible that the implementors are working on standard libraries in edition to finishing the core language.

[Kazimir Majorinc]

I think he has good strategy - to develop superior core language first. Core is for decades, libraries can be added gradually. And superior core + his celebrity appeal that can attract many hackers to contribute open source + enough money to pay few excellent ones to work full time on libraries, tools, documentation etc - and he has everything for success. But I think his core design decisions are not really significant improvement. And some are even step back, i.e. [ ... _ ... ] syntax is not Lisp any more. Newlisp is much bolder improvement in core language.

[lithper]

.. and I think (sorry for being abrupt in such a non-american way) that Paul Graham is parasiting on his popularity while keeping on explaining how great Arc will be the moment it is.

Instead of adding their efforts to an existing open project  he and his hot-air brigade just blabber endlessly over this seeming kludge.



I know at least 3 micro-lisp implementations, newlisp including, if one ignores countless other micro-scheme's.



Graham does not even come close to a one-piece 300-kb executable, with all modern APIs built-in, which by virtue of its compactness and lack of need to do a "system install" can offer pioneering, distributed models of architecting an app.



He does not give us a modern simple and high-level set of operators, etc. etc. etc.



They are talkers, while others simply quietly DO things.

All "Arc" purports to become IS ALREADY AVAILABLE, in several implementations. Two obvious examples are newlisp - and more cryptic, but still quite powerful, at a first glance, picoLisp.

[Jeff]

lithper, did Paul Graham stuff you in a locker in high school or something? Why the anger?  It's just a programming language.

[xytroxon]

lithper, did Paul Graham stuff you in a locker in high school or something? Why the anger?  It's just a programming language.

I must admit my expectations were raised as well after reading several of Graham's writings that claimed he was trying to get back into "the mindset of McCarthy"... I to was hopeful that Graham was really trying to advance the functional programming art... But when Graham decided to keep the obtuse IBM 704 inspired "CAR" and "CDR" syntax... Because, he couldn't think of anything better... That did raise my eyebrow a tad... :)



http://www.paulgraham.com/arc.html">//http://www.paulgraham.com/arc.html



It can't be that hard to do... Can it?



Since McCarthy is the father of "IF THEN ELSE", maybe something simpler could be pursued...



Like expanding (begin ... ) to include (then ...) and (else ...) syntax forms to improve readability?

Code Select Expand


(if (> a b)
   (then
      ; do somethings
   )
   (else
      ; do some other somethings
   )
)


But of course, as long as we can still play "Pong" and Conway's "Life" in the emacs editor, who cares what the syntax of lisp-like languages are? :)

[Kazimir Majorinc]

Code Select Expand


(if (> a b)
   (then
      ; do somethings
   )
   (else
      ; do some other somethings
   )
)


But philosophy behind Lisp syntax is that code=data, i.e. language is optimized to be easily processed as data, not to be human readable. If Lisp has sense at all, then this idea shouldn't be compromised.

[Jeff]

But philosophy behind Lisp syntax is that code=data, i.e. language is optimized to be easily processed as data, not to be human readable. If Lisp has sense at all, then this idea shouldn't be compromised.

That is true (or T if you prefer).  

But when Graham decided to keep the obtuse IBM 704 inspired "CAR" and "CDR" syntax... Because, he couldn't think of anything better... That did raise my eyebrow a tad... :)

Car and cdr are deeply ingrained.  I have a hard time remembering to use first/rest in newLISP.  I don't think he did it because he couldn't think of anything better.  I don't think it occurred to him to even consider it.  car/cdr are as much a part of lisp as parenthesis.

[hsmyers]

Seems from their postings that the real problem that Paul is guilty of is not doing what other people want them to. This un-slave like performance is of course met with name calling in truly adult fashion.



--hsm

[xytroxon]

Car and cdr are deeply ingrained.  I have a hard time remembering to use first/rest in newLISP.  I don't think he did it because he couldn't think of anything better.  I don't think it occurred to him to even consider it.  car/cdr are as much a part of lisp as parenthesis.

From the Arc FAQ:

http://paulgraham.com/arcfaq.html">//http://paulgraham.com/arcfaq.html

Why did you keep car and cdr?



Because we couldn't think of any better alternatives. It would have been misleading to use first and rest or head and tail, because conses are fundamentally pairs; lists are one thing you can build with them, but not the only thing.



There's no conventional name in English for the first and second halves of a pair. If you have to make up names, car and cdr are pretty good choices, because they're short and the same length and naturally composable (e.g. cadr).

:)



In the context of writing a paper on computing using IBM 704 machine language to create list structures for the first time, it makes perfect sense...



But 50 years later, claiming to attempt to be designing "The Hundred Year (Computer) Language", it is like naming functions on an i-Pod by terms used for 1950's record players...



At some point in time  "Eject" and "78 RPM" do not reflect the actual operation of the function anymore... Sure, the old folks "dig it", but the kiddies won't "grok it"... And sorry, but teaching complex concepts to young minds suffer when using obtuse syntax... That's why they line up to use Ruby and dread Lisp...



And this LISP-"mess" is more serious than the dreaded GOTO.



On a complex medical machine, a support progarmmer blindly coding caadr  instead of cadr during a code refactoring session could kill someone...



And English only? Try French or Greek and not just ancient "Geek".



Oops! Sorry... Graham bashing is contagious ;)

[Kazimir Majorinc]

And this LISP-"mess" is more serious than the dreaded GOTO.

I like GOTO. Only way I know for simulating labyrinth in code (not in data) is by using GOTOs.



5 print "start "; time

10 if (rnd>0) then goto 30 else goto 80

20 if (rnd >0) then goto 90 else goto 40

...

90 Print "end "; time



Because of that, I think we need some form of GOTO in Lisp. Another reason is that, of course, assembler has GOTO and McCarthy's intention was to make "higher level assembler."

[Jeff]

CL, newLISP, and Scheme all have goto.  Scheme has the systematic call/cc, which sets a continuation point that works like a goto.  CL and newLISP both have catch/throw, which allows non-local exits.  CL also has tagbody, which lets you tag locations and goto them.



Re car/cdr, I think I agree with Paul Graham.  In newLISP it might be as big a deal, since you can't cons items onto anything other than what is fundamentally a list:

Code Select Expand

(cons 'a 'b) ;=> '(a b)[code]

...but CL certainly allows it:

[code](cons 'a 'b) ;=> '(a . b)

In the second example, the result is a dotted pair, where the cdr is pointing to an atom, rather than another cons, which would make it a list.  In everything but newLISP, lists are all terminated by nil, which is the same as an empty list.  This is actually the most difficult part of newLISP for me.  '() isn't always false and consing onto nil just gives you a list of an atom and nil, rather than a list of just the atom.

[Kazimir Majorinc]

True, CL has goto, although bit restricted (no jumps to nested tags) but continuations and catch/trow are different, they cannot completely replace goto's (for example that "10 goto 90" statement) although they can obviously do some things goto's cannot.

[rickyboy]

Graham is correct.  The pair (or cons cell) is really the primitive type in Lisp -- it is more primitive than the list.  Car and cdr are the pair accessors, whereas first and rest are list accessors.  It so happens that, only because of the way lists are defined, first is defined by car and rest is defined by cdr.  For instance, you could define a list in other ways such that first is NOT car or that rest is NOT cdr.



And the c[ad]+r family of functions self-describe their definitions as compositions of car and cdr, as Graham stated in the faq.  That is a very nice feature and a strong argument for why one would pick such names.



You could pick instead a for car and b for cdr; then the identifiers [ab]+ become de facto reserved, whereas c[ad]+r is, in the current case.  Notice that there isn't an advantage gained by changing to the new convention.  This is, in part, why Graham claims that he "couldn't think of any better alternatives."



And unless someone can, Graham's claim stands.



Also, cond is more general, more powerful, and thus more beautiful than this nonsense:

Code Select Expand

(if (> a b)
   (then
      ; do somethings
   )
   (else
      ; do some other somethings
   )
)
(Look how easy this is to understand: http://lib.store.yahoo.net/lib/paulgraham/jmc.lisp">in McCarthy's Lisp cond is one of ten primitive structures which the evaluator deals with, and parsing its structure is child's play.  So much so that even a human could do it! :-)  These Lisp primitives are not at all complex, BTW.)



I'd rather have a language that is small, yet powerful enough to describe any abstraction I like, even that if-then-else monstrosity above.  :-)  Which means that I think anyone should have the right to build that monstrosity, but not the right to force it upon the unwilling!

[Kazimir Majorinc]

Graham is correct.  The pair (or cons cell) is really the primitive type in Lisp -- it is more primitive than the list.  

It is - but it does not need to be. Single linked list was  good choice for basic data structure when computers had very little available memory. Today it is not the case any more, so it is reasonable to chose some more sophisticated list data structure as a basic one.