Page 1 of 2
Another newLISP-like language :)
Posted: Wed Jan 30, 2008 7:24 am
by cormullion
Posted: Wed Jan 30, 2008 7:27 am
by HPW
It is discussed for a long time here:
http://www.paulgraham.com/
So everyone can try if the huge expectations into the latest kid of Paul Graham get into real.
http://www.paulgraham.com/arc0.html
http://ycombinator.com/arc/tut.txt
Posted: Wed Jan 30, 2008 7:46 am
by newdep
I can remember a seminar or paper where Paul mentioned Arc as a language
he carried a long time with him but never got to the point creating it.
...Now when i look at the link I see another Lisp-Cream... And thats quiet
logical because you cant twist a lambda much ;-)
Posted: Wed Jan 30, 2008 8:44 am
by HPW
A side note: MzScheme is under LGPL.
So ARC should it be also?
Posted: Wed Jan 30, 2008 9:22 am
by newdep
I understand that they use MzScheme because of the initial stage of Arc.
But i like that they created it in Scheme ;-)
Posted: Wed Jan 30, 2008 9:23 am
by Fanda
My expectations were quite high, but there are some good things to look at ;-)
I believe that for example Clojure innovates more:
http://clojure.sourceforge.net/
Fanda
Arc -- meh.
Posted: Wed Jan 30, 2008 8:41 pm
by ghfischer
I read through the arc tutorial and am thoroughly unimpressed.
Most of the stuff I like newLISP already has, and there's no mention of any integrated web stuff (like net-* or *-url).
The one interesting feature I thought might be useful to put in newLISP is some version of Arc's uniq macro functionality. Quoting in full
The way to fix repeat is to use a symbol that couldn't occur in
source code instead of x. In Arc you can get one by calling the
function uniq. So the correct definition of repeat (and in fact
the one in the Arc source) is
(mac repeat (n . body)
`(for ,(uniq) 1 ,n ,@body))
If you need one or more uniqs for use in a macro, you can use w/uniq,
which takes either a variable or list of variables you want bound to
uniqs. Here's the definition of a variant of do called do1 that's
like do but returns the value of its first argument instead of the
last (useful if you want to print a message after something happens,
but return the something, not the message):
(mac do1 args
(w/uniq g
`(let ,g ,(car args)
,@(cdr args)
,g)))
I've always been ok with using leading underscores, but I could see the use in being able to use syntactic sugar like the following ...
Code: Select all
(define-macro (foobar (m-uniq x y)) (set x (eval y)))
My $0.02
Posted: Thu Jan 31, 2008 9:05 pm
by xytroxon
I back tracked this from a posting on reddit you might find interesting...
Arc's not even an acceptable modern Lisp (xent.com)
http://reddit.com/r/programming/info/677u6/comments/
[FoRK] Arc's out, Nu vs. newLISP, and a retort to Paul Graham's elitism
http://www.xent.com/pipermail/fork/Week ... 48238.html
...I'm coming to the conclusion that I reallyDontLike: ObjCStyleCode:
dueToTheRidiculouslyLongSelectors. Really, I find it hard to read.
OTOH, here is (mostly) the same thing in newLISP (sans shebang script
scaffolding, urlencoding and arg processing...)
(define (shrink-url url)
(get-url (append "
http://tinyurl.com/api-create.php?url=" url)))
newLISP is really a weird beast. It is defiantly NOT lexically
scoped, rather has a weird fluid or dynamic scoping mechanism built
on the idea of first-class environments called "contexts." Contexts
form the basis of a kind of pseudo-module system, pseudo-object
system, etc. But it's funky, feels sort of retro. OTOH, it's really
seriously batteries-included, though; has built-in remote execution,
a web server with RESTful app framework --- that's built into the
interpreter, command-line option, NOT a library. It's even got
funky stuff like bayesian classifier functions and finance functions
like npv all built in --- not broken out into libraries or a standard
lib or anything, just built-in functions. And from the docs it's not
clear that the author understands the difference between threads
(which it doesn't support) and processes (which it does via fork and
exec wrappers.) Nonetheless it's one of the most immediately-useful
out-of-the-box programming environment I've seen in a while for a
wide variety of programming tasks.
And it's got the Best. Logo. Ever.
One of these days, if folks don't get their language crap together,
I'm going to have to scratch that lifelong itch and roll my own.
Maybe arc will help me avoid that.
Posted: Thu Jan 31, 2008 9:43 pm
by cormullion
But it's funky, feels sort of retro.
That's my kind of stuff! :)
Here's some more "nothing wrong with retro" retro:
http://www.fat-man.co.uk/docs/product_0 ... ship.shtml
Posted: Fri Feb 01, 2008 1:55 am
by Jeff
Arc is supposed to be the 100 year language. Well, yeah, it's taken nearly that long to develop it, and when we get it, its a layer over scheme.
Posted: Tue Feb 05, 2008 10:10 pm
by itistoday
Advantages/disadvantages when compared to newLISP?
Posted: Tue Feb 05, 2008 11:15 pm
by Jeff
Advantages: lexical scoping
Disadvantages: built on scheme, speed, less mature
Posted: Tue Feb 05, 2008 11:56 pm
by jrh
Jeff wrote:Advantages: lexical scoping
Lexical scoping is nothing but a computer "science" shibboleth.
Posted: Wed Feb 06, 2008 12:32 am
by Jeff
Then why use contexts or OOP at all? OOP is entirely based in static scope.
The only other active languages that I know of that uses dynamic scoping is Perl and emacs lisp (if you consider that an active language).
I'm not saying that dynamic scoping is bad, but lexical scoping certainly cannot be denied as a valid and useful convention.
Posted: Wed Feb 06, 2008 12:52 am
by jrh
Jeff wrote:Then why use contexts or OOP at all?
Why indeed. Especially when implemented in a half-assed kludgy way as in C++ or Java.
As for newLISP, I tried using contexts as objects but the performance was dog slow. Whether FOOP is worth it remains to be seen. I certainly haven't seen any advantages to it yet. Every example seems to be more wordy and complex than just using lists and defined functions.
Pre-compiled components in packages or purchased code are OK, especially for gui stuff but that's not really what OOP is all about.
I remain sceptical and especially so as far as lightweight scripting languages like newLISP are concerned.
Posted: Wed Feb 06, 2008 1:13 am
by Jeff
Don't confuse my defense of lexical scope as advocating OOP :). Arc and newLISP have different aims.
That being said, I was skeptical about FOOP, too. After playing with it a bit, I found I was able to model types like I do in OCaml (which has very expressive types).
There was certainly overhead, but it was not atrocious. I think that it was certainly worth the enhanced readability in my code.
I wouldn't use it for everything, especially applications creating large numbers of prototyped contexts. But some things really lend themselves to the object model, like ORM.
A Style for Everyone
Posted: Wed Feb 06, 2008 3:39 pm
by m i c h a e l
I believe the various styles of programming (FP, OOP, SP, FOOP) appeal to different mindsets. OOP, for instance, appeals to creative types, while FP appeals to the mathematically minded. No approach, unless fundamentally flawed, should be considered "wrong," as this implies that a person's way of thinking is "wrong" if they prefer a style different from our own.
Is vanilla ice cream the "One True Way"? Or chocolate? How about Strawberry? Neapolitan, perhaps? The answer is: all of them! One for every taste. And in the case of programming, one for every mindset.
FP and OOP exist at opposite ends of the programming style spectrum. If the OOP part of FOOP can develop sufficiently enough to handle its side of the spectrum (newLISP already handles the other side), then any style in between should be possible. Even future styles!
Then again, this could turn out to be a big pile of FOOP ;-)
m i c h a e l
Posted: Wed Feb 06, 2008 4:41 pm
by Jeff
I disagree with the statement that OOP is for creative types and functional is for mathematical types. I'm not mathematical. I find functional languages to be much more elegant than that majority of OOP languages. I think that OOP can easily become a crutch and that many programmers try to model *everything* at the expense of logic, efficient and elegant algorithms, and overall program design.
I do like FOOP, though. It reminds me of the clarity of syntax of OCaml types.
Posted: Wed Feb 06, 2008 6:12 pm
by m i c h a e l
My use of "creative types" and "mathematically minded" was perhaps a bad choice of words. Maybe "non-programmers" and "programmers" would have been better? In fact, let's throw out the entire sentence all together. What's important is that you have a preference, and that your preference should be respected.
The impression I've received over the last 16 years is that programmers tend to hate OOP with a capital "H," and that artists and children seem to prefer playing with objects. I've never understood the disdain programmers have for OOP. (In fact, it reminds me of the disdain Common Lispers have for newLISP!) As I said in the above post, I assume it stems from having a mindset at odds with the OOP style.
m i c h a e l
Posted: Wed Feb 06, 2008 6:26 pm
by Jeff
Nope. My problem with OOP is that it tries to force round pegs through square holes and it leads to a lot of poor programming practices. It's a way of trying to fix the maintainability of procedural code, and as an abstraction it can be very inefficient.
I like Python's balance of functional and OOP as well as newLISP's. Neither require it, but they both have it available for problems that are best solved by modeling.
My feeling is that OOP is best used as an expressive way to model data types. The reason lisps generally look down on OOP is that most data can be just as easily represented as a nested list (which can also store functions that act upon that list).
Modeling the logic of the program as objects is trying to force a verb to be a noun. Functional programming or plain procedural code is best for this. I dislike Python's ", ".join(some_list) syntax where it becomes difficult to tell what is acting on what.
Posted: Wed Feb 06, 2008 7:53 pm
by cormullion
As for Arc ... I liked the tutorial, although I didn't download the software. It's interesting that they wrote a tutorial aimed at "readers with little programming experience and no Lisp experience", given Arc's natural audience. I might borrow a few passages for my own tutorial.
At first glance, to my non-technical eye, the Arc language looks a bit like newLISP for people who don't like typing. I prefer the more English-like style of newLISP - I'm a fairly fast touch-typist and my reading's not too slow, so I can handle the extra characters required...
Posted: Wed Feb 06, 2008 8:07 pm
by itistoday
If it's so similar to newLISP then why even bother writing it in the first place when newLISP is so much more mature?
Posted: Wed Feb 06, 2008 8:28 pm
by Jeff
A lot of its popularity is due to this being Paul Graham's big project and the anticipation that has built up over the years it's been in development.
OOP and FP
Posted: Thu Feb 07, 2008 8:05 pm
by Fanda
To me, it's a great thing to have a language allowing you to use both OOP and FP techniques. That's why I wanted to have OOP in newLISP so much. I can actually model some interesting things with it.
My guess is that languages like Python and Ruby are so popular, because they also allow both.
I see a great beauty in declaring class with methods written in functional style. It looks so much better than imperative for/while loops.
[Warning: commercial follows]
I have also been searching and found interesting language called Scala. It is compiled, runs on the JVM, can import Java libraries, supports OOP and FP in a new way (pattern matching on objects/types) and has interesting ways how to extend it. I don't understand it yet and it seems much more complex than newLISP, but I think it's worth looking into :-)
Fanda
PS: It is funny, but after some programming using my OOP framework, I came to understanding that FOOP has some interesting properties, which I would like to add to OOP framework :-)
Posted: Thu Feb 07, 2008 9:07 pm
by Jeff
Scala is an interesting language. I played with it for a while, but my implementations in it always ended up being very slow (which may or may not say something about the language).