9 ms·

How newLisp Took My Breath (And Syntax) Away

61 points by itistoday 17y ago

Nwallins 17y ago
> and extra stuff can be accessed through the function (args) or the symbol $args. 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/newLISP-in-a-nutshell2.gif http://www.taoeffect.com/blog/wp-content/uploads/2009/12/new... ?
- itistoday 17y ago
  The '$' is just another character. $args is a symbol defined by newLISP, which uses the $ character as a convention to indicate system symbols: http://www.newlisp.org/downloads/newlisp_manual.html#system_symbols http://www.newlisp.org/downloads/newlisp_manual.html#system_...
- fallintothis 17y ago
  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-H-10.html#%25_sec_7.1 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.
Ixiaus 17y ago
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... It can easily become a python replacement for me!
- chipsy 17y ago
  I like the idea of "Python replacement." I'm finding Python grating in some ways these days...
  - Luyt 17y ago
    Could you elaborate on that?
  - mahmud 17y ago
    Python is a better "Lisp" than NewLisp.
WalterGR 17y ago
The opinion of those who know significantly more than me is that newLisp is to be avoided. http://news.ycombinator.com/item?id=788157 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.
- itistoday 17y ago
  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. I think there was more to it than that. :-)
  - WalterGR 17y ago
    I haven't read (in your article or elsewhere) sufficient defense for newLisp's choice of o Lazy evaluation ("fexprs") over Lisp macros o "One-Reference-Only" memory management over garbage collection o Dynamic scope over lexical scope But you've found it "the easiest [Lisp] to setup, deploy, and develop for"? Great! newLisp has fantastic documentation and a helpful community? Perfect! I full-heartedly agree with zephjc: "if it works, it works, and more power to you."
    - itistoday 17y ago
      I'm surprised the reasons listed were insufficient for you, but as you say, to each his own. :-)
    - KazimirMajorinc 17y ago
      * Fexprs are easier to write and more expressive than macros. They can be mapped, applied, wrapped around other functions, fexprs and built in primitives, in the case of Newlisp, even mutated during runtime. Fexprs are lot of fun. And the price is - dynamic scope. More about dynamic scope later. * ORO is something in between "manual" memory management like in assembler in C and real GC. It is "more automatized" than former, and less automatized than later. Basically, i agree with you, GC has some important advantages, but ORO is - adequate - and I'd say, not completely without advantages in practice as well. (Theoretically, GC is not excluded in the form of libraries. In past there was little interest for that, but Greg's recent "Objective Newlisp" library provides simple, reference counting-based GC algorithm.) * Dynamic scope - it gives more expressive power: the functions in dynamic scope are about equally expressive as macros, and they are the first class values. The problem with dynamic scope is - accidental name clashes, or "overshadowing." That is where static scope helps and I understand it is reasonable choice for languages like Ada, Eiffel and many others: safety over expressiveness. However, it was not original design goal of Lisp, supposed to be very adventurous language - and it is still visible: CL, Scheme and Clojure programmers have to face exactly the same problem if they write macros. The solutions: namespaces, gensyms and "hygiene" work on the same or similar way for Newlisp dynamic scope. So, it is not really consistent to complain against dynamic scope as unsafe, and to believe that macros are (or can be) "safe enough."
grannyg00se 17y ago
I'd like to see some detail on how the project was done in order to allow us to judge the syntax ourselves. The examples provided aren't very detailed. Perhaps a code snippet or two would help. I'd especially like to see how the graphics were done.
dstorrs 17y ago
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).
anonjon 17y ago
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.
- KazimirMajorinc 17y ago
  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.
  - lispm 17y ago
    EVAL is most of the time not needed. Why add a complication. Write simpler code. There is little need to call EVAL over and over. Using EVAL in Newlisp and any other Lisp slows down the execution. Any compiled Lisp code will run MUCH faster than any evaluated code in Newlisp (with Fexprs, or without). Who cares if the Newlisp interpreter is faster than the CLISP interpreter, if Newlisp is anyway many times slower than compiled code in any other Lisp? Why should I burn useless cycles with Newlisp, when a simple compiler will speed up things much more?
WilliamLP 17y ago
> 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!
lawn 17y ago
It was a language that I had come close to mastering in a matter of minutes, having never used it before! And I thought mastering something took years?
eru 17y ago
> Its modest stature makes [forking] a fairly cheap operation, allowing the OS to handle scheduling and memory-protection. Try forking a JVM… Shouldn't copy-on-write take care of that for the JVM?

61 points by itistoday 17y ago

> and extra stuff can be accessed through the function (args) or the symbol $args. 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/newLISP-in-a-nutshell2.gif http://www.taoeffect.com/blog/wp-content/uploads/2009/12/new... ?

itistoday 17y ago
The '$' is just another character. $args is a symbol defined by newLISP, which uses the $ character as a convention to indicate system symbols: http://www.newlisp.org/downloads/newlisp_manual.html#system_symbols http://www.newlisp.org/downloads/newlisp_manual.html#system_...
fallintothis 17y ago
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-H-10.html#%25_sec_7.1 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.

Ixiaus 17y ago

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... It can easily become a python replacement for me!

chipsy 17y ago
I like the idea of "Python replacement." I'm finding Python grating in some ways these days...
- Luyt 17y ago
  Could you elaborate on that?
- mahmud 17y ago
  Python is a better "Lisp" than NewLisp.

WalterGR 17y ago

The opinion of those who know significantly more than me is that newLisp is to be avoided. http://news.ycombinator.com/item?id=788157 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.

itistoday 17y ago
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. I think there was more to it than that. :-)
- WalterGR 17y ago
  I haven't read (in your article or elsewhere) sufficient defense for newLisp's choice of o Lazy evaluation ("fexprs") over Lisp macros o "One-Reference-Only" memory management over garbage collection o Dynamic scope over lexical scope But you've found it "the easiest [Lisp] to setup, deploy, and develop for"? Great! newLisp has fantastic documentation and a helpful community? Perfect! I full-heartedly agree with zephjc: "if it works, it works, and more power to you."
  - itistoday 17y ago
    I'm surprised the reasons listed were insufficient for you, but as you say, to each his own. :-)
  - KazimirMajorinc 17y ago
    * Fexprs are easier to write and more expressive than macros. They can be mapped, applied, wrapped around other functions, fexprs and built in primitives, in the case of Newlisp, even mutated during runtime. Fexprs are lot of fun. And the price is - dynamic scope. More about dynamic scope later. * ORO is something in between "manual" memory management like in assembler in C and real GC. It is "more automatized" than former, and less automatized than later. Basically, i agree with you, GC has some important advantages, but ORO is - adequate - and I'd say, not completely without advantages in practice as well. (Theoretically, GC is not excluded in the form of libraries. In past there was little interest for that, but Greg's recent "Objective Newlisp" library provides simple, reference counting-based GC algorithm.) * Dynamic scope - it gives more expressive power: the functions in dynamic scope are about equally expressive as macros, and they are the first class values. The problem with dynamic scope is - accidental name clashes, or "overshadowing." That is where static scope helps and I understand it is reasonable choice for languages like Ada, Eiffel and many others: safety over expressiveness. However, it was not original design goal of Lisp, supposed to be very adventurous language - and it is still visible: CL, Scheme and Clojure programmers have to face exactly the same problem if they write macros. The solutions: namespaces, gensyms and "hygiene" work on the same or similar way for Newlisp dynamic scope. So, it is not really consistent to complain against dynamic scope as unsafe, and to believe that macros are (or can be) "safe enough."

grannyg00se 17y ago

I'd like to see some detail on how the project was done in order to allow us to judge the syntax ourselves. The examples provided aren't very detailed. Perhaps a code snippet or two would help. I'd especially like to see how the graphics were done.

dstorrs 17y ago

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

anonjon 17y ago

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.

KazimirMajorinc 17y ago
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.
- lispm 17y ago
  EVAL is most of the time not needed. Why add a complication. Write simpler code. There is little need to call EVAL over and over. Using EVAL in Newlisp and any other Lisp slows down the execution. Any compiled Lisp code will run MUCH faster than any evaluated code in Newlisp (with Fexprs, or without). Who cares if the Newlisp interpreter is faster than the CLISP interpreter, if Newlisp is anyway many times slower than compiled code in any other Lisp? Why should I burn useless cycles with Newlisp, when a simple compiler will speed up things much more?

WilliamLP 17y ago

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

lawn 17y ago

It was a language that I had come close to mastering in a matter of minutes, having never used it before! And I thought mastering something took years?

eru 17y ago

> Its modest stature makes [forking] a fairly cheap operation, allowing the OS to handle scheduling and memory-protection. Try forking a JVM… Shouldn't copy-on-write take care of that for the JVM?