Why Arc is bad for exploratory programming...

[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/">//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 http://ycombinator.com/arc/tut.txt">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">//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/mzscheme/mzscheme-Z-H-10">http://download.plt-scheme.org/doc/mzsc ... eme-Z-H-10">http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-10....) or the pregexp.ss library (http://download.plt-scheme.org/doc/mzlib/mzlib.html">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 http://paulgraham.com/arcchallenge.html">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/">//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.



;-)

[hsmyers]

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

[DrDave]

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
   )
)

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!

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

[xytroxon]

xytroxon,



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 ;)

======

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/">//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."



======

Re: xytroxon



Paul Graham: "The Hundred Year Language"

http://www.paulgraham.com/hundred.html">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!

======

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

Apparently this is not correct -- according to the http://ycombinator.com/arc/tut.txt">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">//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/mzscheme/mzscheme-Z-H-10">http://download.plt-scheme.org/doc/mzsc ... eme-Z-H-10">http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-10....) or the pregexp.ss library (http://download.plt-scheme.org/doc/mzlib/mzlib.html">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.



======

Re: xytroxon



???



Paul Graham: "The Hundred Year Language"

http://www.paulgraham.com/hundred.html">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...



======

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 http://paulgraham.com/arcchallenge.html">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/">//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).

Re: xytroxon



???



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">http://www.paulgraham.com/popular.html

"""The good news is, it's not Lisp that sucks, but Common Lisp. If we can develop a new Lisp that is a real hacker's language, I think hackers will use it. They will use whatever language does the job. All we have to do is make sure this new Lisp does some important job better than other languages."""



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">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 ;)

[rickyboy]

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 even more so willing to give them the benefit of the doubt and the benefit of my time.



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).



(Aside: Graham did say, as you noted, in "The Hundred Year Language" that "[in Arc] some operations that would be awkward to describe as regular expressions can be described easily as recursive functions."  Well, if he could manage to pull off a way to describe operations on strings more easily than regexen, but at least as powerful, then I would be all for it!! (I'm quite sure I'm preaching to the choir here.))



Finally, if there is any confusion about what I wrote here:

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).

it is completely my fault.  Sorry.  It would have been more clear of me to say that "it is constructive to post here about other Lisps, but it would certainly be more constructive to post your concerns on the Arc forum."



That's what I had meant when I had originally used the phrase "It would certainly be more constructive than posting to the newLISP forum".  The rest of the original verbiage was not designed to confuse, but perhaps did -- mea culpa.



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.  :-)

[xytroxon]

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 :)