I'm just going to list all of my criticisms after reading what's on the website:
1. Treating functions as lists effectively makes this a weakly typed language like C, whereas both Scheme and Common Lisp are both strong.
2. What advantage does having implicit function arguments (using nil if not provided, not default arguments) have at all unless if you just hate type safety and would prefer unreliable software? There are lots of other ways to maintain type safety while eliding runtime type checks in hot loops.
3. Changing the binding time for free variables within a closure would also imply that a binding by that name must be in scope at the time the function is called, no? This sounds like dynamic scoping... which is known to be difficult to use and error prone. Do you just assume 'nil' when no binding exists?
NewLisp was designed by a psychologist, who took meticulous care to endow it with design elements such that it would be instantly hated and denounced by anyone who has had anything to do with real Lisp, causing them to spew babble that is incomprehensible to NewLisp n00bies, save for the lingering perception that something gratuitously negative has been spoken. This, in turn, has the calculated effect of making them dig deeper into their trenches.
It is best to remain silent upon the subject of the NewLisp design. Let people make their bed and lie in it.
By the way, if you want to see a really crazy NewLisp zealot, search for Kazimir Majorinc. Wow ...
Maybe he's quit since (and even reformed?); it's been a few years.
> Changing the binding time for free variables within a closure
What closure? NewLisp has done away with those, and offers "name space contexts"
I'm not sure it's fair to tar all newLISP advocates with the same brush. I understand the design choices that Lutz Mueller made, and I can understand how they might be considered unsatisfactory by other Lisp users. That's fine-- I don't expect newLISP to be everything to everybody, and I don't consider it to be the be-all and end-all of languages.
I do find it to be very lightweight and flexible, with excellent documentation and a good built-in library. This makes it useful as a scripting language and for rapid prototyping. I wouldn't recommend it for very large-scale tasks or for projects developed by large teams.
> I don't expect newLISP to be everything to everybody, and I don't consider it to be the be-all and end-all of languages.
Lutz Mueller does. For instance, quote: LISP is an old language born, grown, and standardized in times very different from today, times when programming was for highly educated people who engineered programs. newLISP is LISP reborn as a scripting language: pragmatic and casual, simple to learn without requiring you to know advanced computer science concepts.
Sure, no advanced computer science concepts: just five different hacks to choose from to do some aspect of what a lexical closure does. (Just pick the one whose assumptions are least likely to break in your use case: but no engineering knowledge required to do that, nope!)
NewLisp requires the users to absorb advanced concepts that have fallen by the wayside of the computer science mainstream. A fexpr or self-modifying code are still computer science concepts.
Basically what Lutz is the real problem in NewLisp; other than that, the thing is what it is, take it or leave it. More than needing a compiler, garbage collection or lexical closures, it just needs a dose of humility, really.
On that note, it's somewhat good to see that a lot of the anti-Lisp ranting has been toned down compared to just several years ago. I don't get the sense that Lutz is yet eating any real crow. At best, he's pouring crow-flavored syrup over his ice cream. But at least that's a start!
1. I don't think so. I've used Newlisp and it behaves like your regular dynamically typed language.
2. This question reduces to static versus dynamic typing.
3. It is dynamic scoping.
As a Forth lover - Forth which sacrifices everything including types for efficiency and simplicity - I find Newlisp quite impressive: it is on the same order of magnitude as Lua size-wise (speed-wise it is more like Python according to some old benchmarks), but includes a ton of interesting functions and features where Lua is just bare-bone. Also the fact that it operates without a GC and without requiring manual memory management is quite a feat, even if it has some downsides.
The real weakness of Newlisp to me - if you can get over dynamic scope and typing - is its poor error reporting and debugging support.
Even with all its problems, IMO Newlisp is a good "hacker's language". Small, not too slow, flexible, good standard library, runs anywhere (I've compiled it for an embedded platform running uClinux).
1. Treating functions as lists effectively makes this a weakly typed language like C, whereas both Scheme and Common Lisp are both strong.
2. What advantage does having implicit function arguments (using nil if not provided, not default arguments) have at all unless if you just hate type safety and would prefer unreliable software? There are lots of other ways to maintain type safety while eliding runtime type checks in hot loops.
3. Changing the binding time for free variables within a closure would also imply that a binding by that name must be in scope at the time the function is called, no? This sounds like dynamic scoping... which is known to be difficult to use and error prone. Do you just assume 'nil' when no binding exists?