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-for-exploratory.html
Quote
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.
-----------
newLISP: The fully functional*, "Functional Language"...
* Dilithium crystals included!
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.
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.
.. 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.
lithper, did Paul Graham stuff you in a locker in high school or something? Why the anger? It's just a programming language.
Quote from: "Jeff"
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?
(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? :)
(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.
Quote
That is true (or T if you prefer).
Quote
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.
Seems from their postings that the real problem that Paul is guilty of is not doing what
--hsm
Quote from: "Jeff"
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
Quote
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 ;)
Quote from: "xytroxon"
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."
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:
...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.
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.
Graham is correct. The pair (or cons cell) is really the primitive type in Lisp -- it is
And the
You could pick instead
And unless someone can, Graham's claim stands.
Also,
(then
; do somethings
)
(else
; do some other somethings
)
)
(Look how easy this is to understand:
I'd rather have a language that is small, yet powerful enough to describe any abstraction I like, even that
Quote from: "rickyboy"
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.
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.
By "basic" I meant that Lisp is about lists, "list processing language", and lists can be implemented (and processed) with or without cons.
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?
Quote from: "Jeff"
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.
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
xytroxon,
I remain unconvinced of your arguments against Arc.
Quote from: "xytroxon"
Note that Graham's notion of "exploratory programming" is different from yours (from //http://arclanguage.org/):
Quote
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."
Quote from: "xytroxon"
Apparently this is not correct -- according to the //http://arclanguage.org/item?id=6245, comment by
Quote
($ (sin 1))
Again, bear in mind that Arc is a work in progress.
Quote from: "xytroxon"
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! :-)
Quote from: "xytroxon"
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. ;-)
Quote from: "xytroxon"
And this is a very, very hard thing to do well...
Again, Graham is in agreement with this. I encourage you to read
Here's is a call for community participation for the direction of Arc (again from //http://arclanguage.org/):
Quote
Curious, if you answered the call. It would certainly be more constructive than posting to the newLISP forum. Even so, my goal is
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.
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,
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.
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.
__________
Nevertheless the choice of names is important.
Next to FIRST/BUTFIRST, LAST/BUTLAST is conceivable.
;-)
I've never had any problem with car and cdr— in fact given their origins I rather liked the names. Why does every one think they are broken?
–hsm
Quote from: "rickyboy"
(then
; do somethings
)
(else
; do some other somethings
)
)
I'd rather have a language that is small, yet powerful enough to describe any abstraction I like, even that
AMEN to that!! Keep the basic toolset of LISP and let each builder (programmer) construct his own custom tools that fit the task at hand. Chuck Moore has said words to the effect that a "good" (trade-offs for speed, size, and maintainability to fit the project needs) Forth program will have about 100 Forth words. More than that and the programmer probably has more factoring to do.
DrDave
Quote from: "rickyboy"
I remain unconvinced of your arguments against Arc.
Re: xytroxon
I'm not really arguing for or against Arc, just noticed that other people find it irritating to use after I found it merely frustrating ;)
Maybe people expect Paul Graham's Arc to be on the level of his work on Bayesian filtering for SPAM... Or being able to use Arc to create a "Yahoo Store" style web service with only one or two programmers instead of the three programmerss Graham required using Common Lisp...
And if I was against Arc, I would be posting that it needs a one click Windows installer like Ruby or PHP to even have a chance to succeed ;)
======
Quote from: "xytroxon"
Note that Graham's notion of "exploratory programming" is different from yours (from //http://arclanguage.org/):
Quote
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."
Re: xytroxon
Paul Graham: "The Hundred Year Language"
http://www.paulgraham.com/hundred.html
"""What programmers in a hundred years will be looking for, most of all, is a language where you can throw together an unbelievably inefficient version 1 of a program with the least possible effort. At least, that's how we'd describe it in present-day terms. What they'll say is that they want a language that's easy to program in.
Inefficient software isn't gross. What's gross is a language that makes programmers do needless work. Wasting programmer time is the true inefficiency, not wasting machine time. This will become ever more clear as computers get faster."""
I too want that "language that's easy to program in"... Arc has been SEVEN years in development... The book "On Lisp" by Paul Graham has inspired a generation of "new" Lisp programmers... Graham's Viaweb company was sold to Yahoo, so he made some money, hire back those famed extra programmers he had to hire to seal the deal with Yahoo and get the job done!
======
Quote from: "xytroxon"
Apparently this is not correct -- according to the //http://arclanguage.org/item?id=6245, comment by
Quote
($ (sin 1))
Again, bear in mind that Arc is a work in progress.
Re: xytroxon
???
Paul Graham: "The Hundred Year Language"
http://www.paulgraham.com/hundred.html
"""I think getting rid of strings is already something we could bear to think about. We did it in Arc, and it seems to be a win; some operations that would be awkward to describe as regular expressions can be described easily as recursive functions.""""
Here Graham has said strings are out in Arc, and regular expressions are best left as an exercise in recursion, not a RegEx library...
======
Quote from: "xytroxon"
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! :-)
Quote from: "xytroxon"
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. ;-)
Quote from: "xytroxon"
And this is a very, very hard thing to do well...
Again, Graham is in agreement with this. I encourage you to read
Here's is a call for community participation for the direction of Arc (again from //http://arclanguage.org/):
Quote
Curious, if you answered the call. It would certainly be more constructive than posting to the newLISP forum. Even so, my goal is
???
I posted here in:
---------------
newLISP and/or Whatever Else
Other lisps, other languages. For the Compleat Fan.
---------------
Arc is an "Other lisps", no?
It was some Arc poster that said: "Use newLISP"... I followed the link and he was right! Even Paul Graham is yearning for a new Lisp...
http://www.paulgraham.com/popular.html
"""The good news is, it's not Lisp that sucks, but Common Lisp. If we can develop a
Lutz nicely covered the CAR CDR CONS...
And I was being slightly facetious wiith (if (> a b) (then ...)(else ...))
It raises the hackles, like seeing Graham's (if (odd)(= x 1)(= x 2))
To my mind, it's "odd" for both cases ;)
So I'm not sure who Graham is really trying to reach... The LISP and Scheme people know what they are doing... Just ask them :) They will not be easily won over...
http://www.paulgraham.com/noop.html
"""I personally have never needed object-oriented abstractions. Common Lisp has an enormously powerful object system and I've never used it once. I've done a lot of things (e.g. making hash tables full of closures) that would have required object-oriented techniques to do in wimpier languages, but I have never had to use CLOS."""
Graham has never needed objects, so Arc doesn't need them either?
So Ruby, Python, C++, Java etc. programmers will see this lack in Arc as a step backwards... And how do you efficiently use all those great C++ libraries with Arc without a well thought out object system???
Ugh! No wonder so many people are so negative to Arc!
-- xytroxon
P.S. And I enjoy your posts as well ;)
Hey xytroxon,
Interesting and thoughtful comments you gave. I won't argue the finer points of our philosophical differences, if only that (1) I've done that in the past before, when I was younger and could afford all the time it would take, and (2) it's always better to meet in person over coffee or a beer to do that, since it's more enjoyable that way (and also because I'm a slow typist). :-)
For my part, I am going to take the cautious route, before I weigh in on (or lay into :-) Arc. Since you posted your comments, I had only heard about the Arc release, but now I have downloaded and tried it. What Graham and Morris have implemented is actually a nice first cut. I'd like to play with it some more and probably contribute on the forum. However, I won't make sweeping criticisms, or praise for that matter, for something obviously in its infancy. (Yes, infancy. Seven years of wall clock time entails not software maturity.) Also, since Graham and Co. are apparently accepting of community involvement with the development and direction of Arc, I am
So, I have you to thank for spurring me, an inherently lazy but nonetheless busy person, to try Arc. So thanks! :-)
I would also encourage you to mess around with Arc too, if you haven't already. Quoting Graham's "The Hundred Year Language" is not relevant for making criticisms of the current release of Arc, which post-dates it by more than 4 years -- a lot of water has flowed under the "design bridge" during that span. Reading about the current Arc, not the Arc of Graham's fancy four years ago, is how I discovered that strings are in the Arc core and that regexen are available through a library (for now).
Finally, if there is any confusion about what I wrote here:
Quote from: "I previously"
it is completely my fault. Sorry. It would have been more clear of me to say that "it
That's what I had meant when I had originally used the phrase "It would certainly be
BTW, I'm still curious to know if you have already or are planning to investigate Arc for yourself (the install is fairly simple), and if you plan on contributing on the Arc forum.
Of course, I'm certainly glad to have you using newLISP. It is tre cool after all. :-)
I think I need that one-click Arc installer... LOL!
I explore programming on the weekends, 26.4 bps modem is the best I have here in the country... So was two days to download and install Dr/Mz Scheme... But it was the WRONG version for Arc!... Start over... Due to internet security, we are not allowed to use or download unapproved "hacker" tools at work!... Graham really needs to redefine his term "hacker"... (Don't get me started on the blank stares you get when you mention Lisp)... Also DrScheme takes 50 minutes to load on an old Win 98 machine I am targeting for development... Sadly many poorer country school systems still use Win98, WinMe (even Win95) on parent donated machines... My sister-in-law school teacher loves her custom Opera browser PIM (the Abyss server I set up running the newLISP wiki)... And other than the newLISP guiserver hanging and not working (even after upgrading to Java jre1.5.0_13), newLISP runs rings around PHP, Ruby, or even Python on these old machines...
But back to Arc... I and others expect better from Paul Graham, who others have said "wrote the most important book in programming history" (On Lisp)... He should of started earlier to include other peoples thoughts in the Arc development process... His book helped push people into LISP like languages... Now he wants to rip them away from that to pursue Arc?... But I think the pride of wanting to be the father of "The Hundred Year Language" played into his delayed release... But after the history of Wirth's Pascal and Modula 2, people are skeptical... (If I had known, I would of taken Art classes with young coeds instead :)
Unfortunately for Arc, being redirected to newLISP has taken most of my free time!... After using UPX to compress newLISP to under 80kbytes, I had to uninstall newLISP from my machine to prove to myself that it worked without hidden mirrors!... Even then, I still think it does ;)
I think Yoda would say to Luke Skywalker Graham: "Do... or do not. There is no try!"
But I will be watching and enjoying both Arc's and newLISP's development "challenge"...
May the newLISP force be with you...
-- xytroxon
(Note: Lutz is our newLISP Obi Wan Kenobi :)