Another newLISP-like language :)
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Another newLISP-like language :)
Something called Arc. http://arclanguage.org/
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
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
Hans-Peter
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
I believe that for example Clojure innovates more:
http://clojure.sourceforge.net/
Fanda
Arc -- meh.
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
My $0.02
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
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 ...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)))
Code: Select all
(define-macro (foobar (m-uniq x y)) (set x (eval y)))
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
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.
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
That's my kind of stuff! :)But it's funky, feels sort of retro.
Here's some more "nothing wrong with retro" retro:
http://www.fat-man.co.uk/docs/product_0 ... ship.shtml
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.
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.
Why indeed. Especially when implemented in a half-assed kludgy way as in C++ or Java.Jeff wrote:Then why use contexts or OOP at all?
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.
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.
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.
-
- Posts: 394
- Joined: Wed Apr 26, 2006 3:37 am
- Location: Oregon, USA
- Contact:
A Style for Everyone
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
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
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.
I do like FOOP, though. It reminds me of the clarity of syntax of OCaml types.
-
- Posts: 394
- Joined: Wed Apr 26, 2006 3:37 am
- Location: Oregon, USA
- Contact:
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
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
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.
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.
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
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...
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...
If it's so similar to newLISP then why even bother writing it in the first place when newLISP is so much more mature?
Get your Objective newLISP groove on.
OOP and FP
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 :-)
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 :-)