Why Arc is bad for exploratory programming...

[xytroxon]

I found this over at reddit:
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 ... atory.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

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 all

(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 all

(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

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 all

(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 all

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

(Look how easy this is to understand: 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.

[Jeff]

You misunderstood, Kazimir. The singly linked list is not the basic structure. The cons is. A cons is a pair; often, it is an atom and a reference to another cons. This makes a singly linked list. A cons that consists of two atoms is a dotted pair, which does not link to any other conses.

An element in a list is a cons, but a cons is not necessarily an element in a list.

[Kazimir Majorinc]

By "basic" I meant that Lisp is about lists, "list processing language", and lists can be implemented (and processed) with or without cons.

[Jeff]

What other reasonable implementation for a singly linked list is there? In C, you would do it with a two (or more) element struct containing the content and a reference to another object, which is structurally similar to a cons. This is the method (essentially) that newLISP uses. How would you propose to implement a singly linked list?

[Kazimir Majorinc]

What other reasonable implementation for a singly linked list is there?

That is the point, Jeff - lists do not need to be represented as single linked lists internally. User does not care how lists are represented internally, he only needs some set of operations, and if possible, that these operations are fast enough. With single linked lists, alot of things are slow.

Double linked lists are obvious improvement, but better than that is possible. I remember when C had no libraries, I used to implement lists as some combination of binary trees and double linked lists and every operation was very fast.

Of course, one can do such things as well in Lisp, but it is better that they are available out of the box! Especially because only code stored in default lists can be evaluated as code; code stored in some user defined lists cannot.

[xytroxon]

Graham created Arc for "Exploratory Programming"... That is, quick, easy to write, one time scripts and such... Which is what I use newLISP for!

And Graham has banned strings and RegExp from Arc!!! The two things I use the most ;)

CAR CDR CONS are sharp tools for brain surgery! (Remember. No lowercase in the original McCarthy LISP!) Just as sharp tools, they need to be used properly... This requires thought, planning, and skill... Just the thing for grad students or professional programmers to use! Now web programming is putting many less dedicated and trained people "writing code"... And once you understand how to build and use lists and trees, the low level functions should disappear from the users view. Like pointers did in JAVA. If you do need them, use well developed LISP, Scheme, etc. tools..

The true beauty of art is not in all that you can put into it... It is knowing what you need to leave out while keeping harmony with what you leave in...

And this is a very, very hard thing to do well...

--xytroxon

[rickyboy]

xytroxon,

I remain unconvinced of your arguments against Arc.

Graham created Arc for "Exploratory Programming"... That is, quick, easy to write, one time scripts and such... Which is what I use newLISP for!

Note that Graham's notion of "exploratory programming" is different from yours (from http://arclanguage.org/):

Arc is designed for exploratory programming: the kind where you decide what to write by writing it. A good medium for exploratory programming is one that makes programs brief and malleable, so that's what we've aimed for. This is a medium for sketching software.

This definitely entails that you will not get "turn-key" support. And if one is not convinced, one only needs to read the next paragraph: "Arc is unfinished. It's missing things you'd need to solve some types of problems."

And Graham has banned strings and RegExp from Arc!!! The two things I use the most ;)

Apparently this is not correct -- according to the Arc tutorial, there is plenty of core language support for strings. The regex question was a little harder in that it took me an extra minute to search the forum via Google. Apparently, there is no language or library support, per se, for regexs (which, again, just places it in the claimed "unfinished business" category); however, a user on the forum announced a work-around with make regexs imminently, and almost painlessly, possible (from http://arclanguage.org/item?id=6245, comment by skenney26):

As far as the lack of a regex library in Arc you could probably make use of PLT MzScheme's built-in support for regular expressions (http://download.plt-scheme.org/doc/mzsc ... eme-Z-H-10....) or the pregexp.ss library (http://download.plt-scheme.org/doc/mzlib/mzlib.html) for Perl-style regex. Anarki allows you to call scheme functions from within arc by using $:

($ (sin 1))

Again, bear in mind that Arc is a work in progress.

CAR CDR CONS are sharp tools for brain surgery! (Remember. No lowercase in the original McCarthy LISP!) Just as sharp tools, they need to be used properly... This requires thought, planning, and skill... Just the thing for grad students or professional programmers to use!

Not necessarily. These primitives are not so hard to apply well. There is an inherent simplicity in the axiomatic approach of McCarthy. And users who still had questions about them could even ask more experienced people on this and other forums about how to work with them. An education for free! :-)

Now web programming is putting many less dedicated and trained people "writing code"... And once you understand how to build and use lists and trees, the low level functions should disappear from the users view. Like pointers did in JAVA. If you do need them, use well developed LISP, Scheme, etc. tools..

Most would agree with that. I don't see how this part is relevant to an argument against Arc though. It is, however, an argument against using Java. ;-)

The true beauty of art is not in all that you can put into it... It is knowing what you need to leave out while keeping harmony with what you leave in...

And this is a very, very hard thing to do well...

Again, Graham is in agreement with this. I encourage you to read Take the Arc Challenge, wherein Graham addresses the issue you brought up. What's interesting here is that he starts with a simple premise related to Kolmogorov complexity, i.e. length of programs to describe certain data, and everything else is then an exercise in exploration of developing a language which keep this complexity low while, or thus, maximizing power. Surprisingly enough, this is the same kind of exploration the language itself is supposed to help programmers with at the application level. ;-)

Here's is a call for community participation for the direction of Arc (again from http://arclanguage.org/):

Second, we'd like to encourage a sense of community among Arc users. If you have a question or a suggestion, share it with everyone in the forum. And if you know the answer to a question you see in the forum, help out whoever posted it by replying.

Curious, if you answered the call. It would certainly be more constructive than posting to the newLISP forum. Even so, my goal is not to discourage you from posting here about Arc -- I rather like your postings (which is why I bothered to answer).

[Lutz]

This is my take on cons, car and cdr:

Older introductions to Lisp are full of examples how to walk and construct lists using car, cdr and cons. A modern Lisp, like newLISP has enough higher level list functions (e.g: filter, explode, rotate, transpose ...) to make walking lists with car/cdr and constructing lists with cons unnecessary.

Many newcomers to newLISP start writing programs in this old style using the 'first', 'last' and 'cons' primitives in newLISP instead of looking for the faster, more comfortable and higher level API newLISP has to offer.

I see a historical significance of car, cdr and cons and only when looking for a theoretical minimum of primitives necessary to build more complex list functions. In a modern applications oriented Lisp with a higher level API they have no place. 'first', 'rest' and 'last' are much more descriptive and code-documenting and for accessing sub-members 'nth' or implicit indexing is a better choice than cadr and the other car/cdr compositions.

[rickyboy]

Very good, Lutz!

The only thing I would add is that Lisps such as newLISP, while they indeed give us the nice high-level constructs we need, also provide us with the low-level constructs we need to write other, not-yet anticipated higher-level abstractions. newLISP answers the call at many levels.

As I said previously, if you don't shackle us with absurdities (like Java does), but give us a maximal-practical level of freedom in our programming, so that we can program at whatever levels we feel necessary to the task, we will like working with your language -- it will be useful and fun. And that's why people like newLISP, for instance.

[Elica]

To be honest I'm not sure what's the point of the whole quarrel. Historically CAR/CDR represent a physical data structure. HEAD/TAIL, or FIRST/REST, or FIRST/BUTFIRST, or whatever pair of names you come up with, represent a logical data structure*. But things change over time.

Anyway, these are just names. What is important, is what happens underground. Personally, I would not care that much about what names are used, as long as:
- I know what functionality they implement
- I have a way to create new functions with names that I prefer

Just for the record: In Elica both naming conventions are used. The back-end of Elica uses CAR and CDR. The front-end (i.e. what ELica users see) uses FIRST and BUTFIRST.


__________
* There are Llisp-machines, where some logical things have been implemented physically

[newBert]

Nevertheless the choice of names is important.

Next to FIRST/BUTFIRST, LAST/BUTLAST is conceivable.

;-)