

How newLisp Took My Breath (And Syntax) Away - itistoday
http://www.taoeffect.com/blog/2010/01/how-newlisp-took-my-breath-and-syntax-away/

======
WalterGR
The opinion of those who know significantly more than me is that newLisp is to
be avoided.

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

~~~
rw
Step 0: don't pretentiously prepend "new" to the name of your language.

~~~
eru
What's the difference to adding ++?

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

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

------
Ixiaus
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
I like the idea of "Python replacement." I'm finding Python grating in some
ways these days...

~~~
mahmud
Python is a better "Lisp" than NewLisp.

------
Nwallins
> _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/new...](http://www.taoeffect.com/blog/wp-
content/uploads/2009/12/newLISP-in-a-nutshell2.gif) ?

~~~
fallintothis
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...](http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-
Z-H-10.html#%25_sec_7.1)) 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.

------
eru
> 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?

------
lawn
_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?

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

~~~
anonjon
Right, that is the reason that there is such a huge difference between the
runtime for eval between the languages. Macros do slow down eval if you are
doing macro-expansion. They are complicated enough that normally you do not
write (or expect) them to expand quickly. This is obvious because macros and
fexprs are much different. Overall, macros can speed up your program because
you are allowed to do certain calculations ahead of time, if you are clever
about it.

I am not saying that you should avoid eval completely, I am just saying that
it shouldn't be your only tool. And when you do use it, if you put it in a
tight loop, you are probably doing something wrong.

The main alternative that comes to mind for me is function passing. There is a
lot that you can do with function passing that overlaps with eval, except the
function passing version will be safer and faster.

We agree that is one of the most powerful, most fun aspects of using lisp (the
power is what makes it fun!). I also hope we agree that the frequency of its
use should be the inverse of its power.

~~~
lispm
Macros only really slow down things when you for some unknown reason call EVAL
on source code many times.

When code is running using EVAL and an interpreter, macros can be expanded
once and then the expanded code is used next time. For example in a loop it is
not necessary to expand a macro each time it is used.

If one needs to EVAL new code all the time, then one may ask oneself if that
is really necessary. For example if one is doing some kind of genetic
programming. Otherwise it is basically a programmer error to do so.

I haven't seen any convincing example where it is really needed. My Symbolics
Lisp Machine (which comes out of the MacLisp tradition, which had FEXPRs) got
only limited FEXPRs (can't be compiled, can only be used at the top-level).
Still the developers who had extensive FEXPR experience with Maclisp, were
able to write the compiler, the garbage collector, the graphics driver, the
window system, the network system, compilers and interpreters for various
languages, text editors, mail clients, mail servers, and much more without
using FEXPRs.

