In most anything written by a fan of newLisp, you'll find something like the following (taken from the linked article):
> Today, unfortunately, whenever someone mentions newLISP on an online forum frequented by adherents of another LISP, an almost clan-like flame war will erupt. An adherent of one particular dialect, usually someone who has never used newLISP, will shout obscenities such as, "newLISP goes back on just about every advancement made by LISPs", or "dynamic scope is evil!"
Maybe there's something to newLisp, but any time I see a group with that flavor of persecution complex ("All the criticism is wrong because they just don't understand!") I take pause.
Maybe there's something to newLisp, but any time I see a group with that flavor of persecution complex ("All the criticism is wrong because they just don't understand!") I take pause.
To be honest, that could describe almost the entire (vocal) Lisp community these days, and I say this as a quite embarrassingly commited Lisp fan and user.
Anyway, I wouldn't say that dynamic scope is evil, but to most Lisp users is does just feel a little backwards. Un-natural, if you will. That's just one of the reasons why everyone secretly (or not-so-secretly) longs for the never-coming day when emacs lisp can just 'go away'.
I guess you can view newLISP in at least two different ways: a naive implementation of it, or a reboot of it, branching from a much older LISP than most today do.
I think of the new LISPs out there, Clojure has its act together much more than newLISP - it's quite sophisticated in a lot of ways, it's making rapid progress, and now has a relatively large development community for such a new language.
But for newLISP users: if it works, it works, and more power to you.
Maybe there's something to newLisp, but any time I see a group with that flavor of persecution complex ("All the criticism is wrong because they just don't understand!") I take pause.
Hm. You make this sound attractive; I've been messing about with PLT Scheme for a few months and will check out newLisp to see how they differ.
That said, I need to disagree with you on one point:
> I realized that it was syntax that was at the root of most programming errors.
No. You're using the word wrong. Syntax is the structure of a language--e.g., curly braces vs whitespace vs parens vs etc to set scope. Syntax is trivial and can be caught by the compiler / interpreter.
The root of most programming errors is a logic fault--i.e., the programmer is either solving the right problem incorrectly (didn't think it through or didn't understand it) or is solving the wrong problem (incorrect / out of date / misunderstood requirements).
> Up to that point in time my knowledge of LISP consisted of the usual hearsay and mantra of those unfamiliar with the language: "People who like it are crazy zealots who think they’re superior to everyone!"
So I used it... and now I'm crazy for it and I think I'm superior to everyone!
Good article, I've liked newLISP since I discovered it a few days ago but wasn't sure about it after a few responses to my comment in the newLISP webframework thread...
I think the syntax cards were pretty bogus anyways. If you really wanted to compare syntax, you'd do better to compare grammars (e.g., Scheme's: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z...) than to decide what's important enough to include in some gif. It's hand-wavy at best (cf. the explanations of why things like eql were on the card) and straw-man at worst.
I'm not saying that newlisp is to be avoided, but:
Lisp's power is not in its lack of 'syntax', but in the specific way that the code is structured. You can write code that writes code. The regular structure of the code helps this, not the specific syntaxes.
The Fexpr vs. macro comparison is bogus.
In common lisp (or scheme or Clojure) you will normally not be macro-expanding the macro more than once (when you compile it).
You will notice that compiled versions (cl or scheme) of these tests trounce newLISP soundly. Eval is to be avoided because most of the time there are are a lot of more structured ways to do exactly the same thing. Evaluating arbitrary code is very clever and can lead to a very big headache.
I don't know about the rest other than that 'we have fork' is probably not going to buy you much from clojure folks.
I think a better argument for newLisp would have been:
1.) It is lispier than python or C.
2.) It is simple and good for scripting, and therefore good for lisp newbies (you don't have to get your head around macros or the intricacies of eql eq equal, equalp and =).
I think that the CL community appears so abrasive because the language is so complex (this has nothing to do with syntax, but simply the size and complexity of the spec). You have to make serious effort to understand/know it before you can even begin to ask reasonable questions about it.
Even people who have been programming CL for years can get things wrong answering from the top of their head. It is not poorly documented, it is just huge and in some respects complex.
If you use eval in your program, the program will macroexpand each time it evaluates code containing macros. As even standard operators like setf are macros in CL, it will practically macroexpand each time it uses eval.
So, macros really slow down all or practically all programs containing eval. One can avoid evals, but from my point of view that means avoiding the most powerful, the most fun code=data feature in Lisp. It doesn't look good to me. So, why should one avoid eval?
"Eval is to be avoided because most of the time there are are a lot of more structured ways to do exactly the same thing." I miss the point here.
[+] [-] WalterGR|16 years ago|reply
http://news.ycombinator.com/item?id=788157
In most anything written by a fan of newLisp, you'll find something like the following (taken from the linked article):
> Today, unfortunately, whenever someone mentions newLISP on an online forum frequented by adherents of another LISP, an almost clan-like flame war will erupt. An adherent of one particular dialect, usually someone who has never used newLISP, will shout obscenities such as, "newLISP goes back on just about every advancement made by LISPs", or "dynamic scope is evil!"
Maybe there's something to newLisp, but any time I see a group with that flavor of persecution complex ("All the criticism is wrong because they just don't understand!") I take pause.
[+] [-] J_McQuade|16 years ago|reply
To be honest, that could describe almost the entire (vocal) Lisp community these days, and I say this as a quite embarrassingly commited Lisp fan and user.
Anyway, I wouldn't say that dynamic scope is evil, but to most Lisp users is does just feel a little backwards. Un-natural, if you will. That's just one of the reasons why everyone secretly (or not-so-secretly) longs for the never-coming day when emacs lisp can just 'go away'.
[+] [-] zephjc|16 years ago|reply
I think of the new LISPs out there, Clojure has its act together much more than newLISP - it's quite sophisticated in a lot of ways, it's making rapid progress, and now has a relatively large development community for such a new language.
But for newLISP users: if it works, it works, and more power to you.
[+] [-] rw|16 years ago|reply
[+] [-] itistoday|16 years ago|reply
I think there was more to it than that. :-)
[+] [-] dstorrs|16 years ago|reply
That said, I need to disagree with you on one point:
> I realized that it was syntax that was at the root of most programming errors.
No. You're using the word wrong. Syntax is the structure of a language--e.g., curly braces vs whitespace vs parens vs etc to set scope. Syntax is trivial and can be caught by the compiler / interpreter.
The root of most programming errors is a logic fault--i.e., the programmer is either solving the right problem incorrectly (didn't think it through or didn't understand it) or is solving the wrong problem (incorrect / out of date / misunderstood requirements).
[+] [-] WilliamLP|16 years ago|reply
So I used it... and now I'm crazy for it and I think I'm superior to everyone!
[+] [-] Ixiaus|16 years ago|reply
It can easily become a python replacement for me!
[+] [-] chipsy|16 years ago|reply
[+] [-] Nwallins|16 years ago|reply
Hmm.. what makes $args a symbol? The sigil? If not, what does the sigil $ indicate? Isn't that syntax? Why isn't it listed here: http://www.taoeffect.com/blog/wp-content/uploads/2009/12/new... ?
[+] [-] fallintothis|16 years ago|reply
[+] [-] itistoday|16 years ago|reply
http://www.newlisp.org/downloads/newlisp_manual.html#system_...
[+] [-] eru|16 years ago|reply
Shouldn't copy-on-write take care of that for the JVM?
[+] [-] lawn|16 years ago|reply
And I thought mastering something took years?
[+] [-] anonjon|16 years ago|reply
Lisp's power is not in its lack of 'syntax', but in the specific way that the code is structured. You can write code that writes code. The regular structure of the code helps this, not the specific syntaxes.
The Fexpr vs. macro comparison is bogus. In common lisp (or scheme or Clojure) you will normally not be macro-expanding the macro more than once (when you compile it).
You will notice that compiled versions (cl or scheme) of these tests trounce newLISP soundly. Eval is to be avoided because most of the time there are are a lot of more structured ways to do exactly the same thing. Evaluating arbitrary code is very clever and can lead to a very big headache.
I don't know about the rest other than that 'we have fork' is probably not going to buy you much from clojure folks.
I think a better argument for newLisp would have been: 1.) It is lispier than python or C. 2.) It is simple and good for scripting, and therefore good for lisp newbies (you don't have to get your head around macros or the intricacies of eql eq equal, equalp and =).
I think that the CL community appears so abrasive because the language is so complex (this has nothing to do with syntax, but simply the size and complexity of the spec). You have to make serious effort to understand/know it before you can even begin to ask reasonable questions about it.
Even people who have been programming CL for years can get things wrong answering from the top of their head. It is not poorly documented, it is just huge and in some respects complex.
[+] [-] KazimirMajorinc|16 years ago|reply
So, macros really slow down all or practically all programs containing eval. One can avoid evals, but from my point of view that means avoiding the most powerful, the most fun code=data feature in Lisp. It doesn't look good to me. So, why should one avoid eval?
"Eval is to be avoided because most of the time there are are a lot of more structured ways to do exactly the same thing." I miss the point here.
[+] [-] grannyg00se|16 years ago|reply
[deleted]