Better spend your time learning Clojure, Racket, Scheme or Common Lisp. NewLisp repeats the design mistakes of ancient Lisps that were fixed in the newer Lisps, like dynamic scoping and interpreting only instead of compiling which makes it much slower than other Lisps. NewLisp should be called OldLisp. It also adds some mistakes of its own, like deep copying everything when you pass it around. And making `cons` act like `list` when the second argument is not a list.
While it is true that NewLisp isn't going to win any awards from either the Avant /or/ the Vieille Garde, I would argue that just because its philosophy is different from what you believe is most performant doesn't make it a bad language. Ruby's defenders should back me up on that...
As I understand it, scoping is handled by "contexts", which can be inconvenient if you expect every function to be a single standalone snowflake, but just fine if you`re tossing off quick scripts which don`t require hermetic degrees of encapsulation. You can also force scope by using 'let' or declaring private variables as arguments, among other things. Certainly Emacs Lisp seems to do OK with similar constraints.
As mentioned elsewhere in this post, the deep copy thing may not be as bad as you make it out to be -- certainly it's never particularly troubled me.
As for cons... It seems to me that cons is a rather obsolete construct, referring to a long obsolesced hardware feature. I can't get too unhappy about someone trying to make it more immediately useful in a modern context.
We've talked about what you don't like about it -- here's what I think NewLisp has gotten very much right:
* It's simple to use.
* It's small and self contained.
* It has a REPL and you can do introspection.
* It has conveniently and reasonably named built-in functions.
* It deals well with a UNIX-derived file system.
* It's easy to pick up and start using, but you can still do fancy stuff.
* The documentation contains worked out examples for every built in function.
* The main developer is very responsive and helpful.
* Trivially cross-platform with downloads, not compiles.
I have found NewLisp to be very convenient for many of the problems I have applied it to. I have used it for everything from dynamic web pages to image processing to ad-hoc render farms. So, I certainly feel that it may be invaluable for someone who is interested in Lisp, but has been intimidated or discouraged by the "official" compilers and needs to get some real world work done.
As for cons... It seems to me that cons is a rather obsolete construct, referring to a long obsolesced hardware feature. I can't get too unhappy about someone trying to make it more immediately useful in a modern context.
Actually, it neatly fits the place of the concept of a "Pair" or "two-value tuple". SICP suggests that it serves the most basic function of data structures, that it can glue any two values together; from CONS can all (?) other data structures arise. It has little to do with lists other than the fact that most sources show you how to use CONS to construct a singly-linked list (a CS 101 data structure), and there is some built-in support for this basic approach. However, Common Lisp also provides built-in support for using CONS to construct arbitrary trees of data.
The notions that CONS is only for pushing an element onto a list, that CAR is equivalent to FIRST or HEAD, and that CDR is equivalent to REST or TAIL are a misunderstanding of its power -- one that I accidentally made in the past. Rename it to "CONSTRUCT-PAIR", and it makes more sense.
I have to admit when I first glanced at NewLisp, thinking it was a kind of modern revision of Lisp, this incorrect pigeon-holing was one of my big turn-offs and tends to lend credence to statements like "NewLisp repeats the design mistakes of ancient Lisps that were fixed in the newer Lisps". All that said, it's great to see people dabbling with their own experimental languages; it is a great learning experience for the developers.
There are many Lisps that are simple and easy to use. Scheme, for one, is
extraordinary simple and easy to use. Indeed, many colleges use it for their
introduction to programming classes.
>It's small and self contained.
This could apply to any Lisp, but again is especially true of Scheme. Scheme is
a very small language; the entire language can be built from 7 special forms.
How much smaller can a language get? Even all the special forms required to
build a "practical" Lisp like Clojure can be counted on two hands. Lisp, in
general is a very elegant and self contained language. NewLisp's elegance and
cohesion does not break new ground.
>It has a REPL and you can do introspection.
Every Lisp extant today has these two features. Indeed, introspection is
inherent to all Lisps; when code is data and data is code, introspection becomes
trivial.
>It has conveniently and reasonably named built-in functions.
>It deals well with a UNIX-derived file system.
Most Lisps have fairly nice pre-built functions for accessing files. Moreover, I
don't want my programming language to become especially tied to a single
platform, by making file-system assumptions that may not hold true on other
systems.
>It's easy to pick up and start using, but you can still do fancy stuff.
Well, it is Lisp. The inherent abstraction of the language will mean that Lisp
won't ever be as "beginner-friendly" as, say, Python or Ruby. That said, Scheme
(especially Racket) does an incredibly good job of allowing total novices to
build programs in a very short time. As far "fancy stuff" goes, I wrote a
minimax chess engine with an interactive graphical front-end for a school
project. I don't know if that's fancy enough, but it certainly seemed pretty
cool at the time.
>The documentation contains worked out examples for every built in function.
Again. see Racket.
>The main developer is very responsive and helpful.
Well, here I must concede a point. I have no idea how responsive the developers
of Racket are, for I never had cause to contact them.
>Trivially cross-platform with downloads, not compiles.
First, this is true of every JIT compiled and interpreted language. Second, its
not as trivial as you're making it out to be. The user has to have the
interpreter installed, unless the interpreter, libraries and script are all
packaged together as a frozen binary of some sort.
Comparing newLISP with Clojure or Common Lisp is a bit like comparing a sandwich with a three-course meal. If you must compare languages, it's probably better to consider newLISP with Lua or ELisp or AppleScript or Perl or whatever.
Each language has its own sweet spots. It's possible that newLISP is another tool useful enough to have in one's toolbox, alongside all those other tools. "A craftsman uses the right tool for each job; an amateur uses the same tool for every job."
In practice, I haven't found dynamic scoping or lack of compilation to be a huge problem. If you run out of speed, you need to change horses.
The most serious problem with newLISP is, I think, the name. The author managed to choose and combine the seven letters of the alphabet most likely to irritate the most irritable section of the programming community.
I like clojure for server-side work, but newLisp is a great counterpart, especially if you've been spoiled by clojure features like implicit indexing and don't want to go back to CL.
The jvm startup time makes clojure unsuitable for quick scripts, but newLisp has no such issue. It's also got enough batteries included that you don't really need to bother looking for libraries when you're doing basic scripting tasks (sockets, http client, file io all built in). Json parsing is a notable exception, but there's a good library out there by Jeff Ober if you google "newlisp json".
Basically, newLisp is my scripting language of choice until self-hosted clojure becomes a reality.
