NewLisp(newlisp.org)
newlisp.org
NewLisp
http://www.newlisp.org/
19 comments
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:
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.
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.
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.
Let me respond to your points individually:
>It's simple to use.
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.
>It's simple to use.
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.
> >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.
They are very responsive and helpful and the mailing list is active.
> 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.
They are very responsive and helpful and the mailing list is active.
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.
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.
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.
It is especially well-suited for applications in AI...
<Groan>. I wish people would stop putting "lisp" and "AI" in the same sentence. How many decades did lisp languish because people thought there was no reason to learn it if they weren't doing AI?
<Groan>. I wish people would stop putting "lisp" and "AI" in the same sentence. How many decades did lisp languish because people thought there was no reason to learn it if they weren't doing AI?
And from the other side, how many decades was AI approached from an ineffective direction because it was assumed that Lisp was good at it?
Has there been any measurable progress in actual AI since, well, ever?
Your thesis here is that Lisp itself was a limiting factor in AI research? What alternate language/direction would have resulted in substantially more progress?
I'm not Miky, but I interpreted his statement to be that doing AI is a whole heck of a lot more complicated than just using an introspective, code-as-data, data-as-code language.
LISP is a hammer in an AI researcher's toolbox. Human-level AI is a monumental skyscraper undertaking. For sure, any construction team would be hard-pressed to build the Empire State Building without the proper tools, but there's a lot more to it than that.
LISP is a hammer in an AI researcher's toolbox. Human-level AI is a monumental skyscraper undertaking. For sure, any construction team would be hard-pressed to build the Empire State Building without the proper tools, but there's a lot more to it than that.
Can someone explain NewLisp's memory management model to me? The description here: http://www.newlisp.org/MemoryManagement.html makes it sound like NewLisp essentially uses something like an std::auto_ptr from C++ for all its references, but I'm not sure how its possible to write a Lisp where you only ever have one reference to things.
It looks like everything is passed by value, so instead of passing a reference to that int, string, list, array, etc, you are always passing a copy. Once you hit an evaluation contact above where the copy cane from, it can be deleted.
I would imagine for some particular set of data (many large arrays and such) that this could get really slow, but their claim is, at least in the general case, it is faster to copy everything.
I would imagine for some particular set of data (many large arrays and such) that this could get really slow, but their claim is, at least in the general case, it is faster to copy everything.
They also provide mechanisms to pass by reference. Default pass-by-copy with specially enabled pass-by-reference is indeed the opposite from most other languages do. I wonder how this interacts with things like memory paging and CPU cache.
Default pass-by-copy with specially enabled pass-by-reference isn't that uncommon; it's how C++ works, for example.
When I read any well written Lisp code I feel my awareness of the subject gets cleaner, sharper and lighter. I never experienced a similar thing with other languages. I am not belittling them, or criticising. It is just a deep personal feeling, that has been lasting since university times, back in the 90s.
I liked the code that I have seen at newlisp.org, newlisper.wordpress.com (for example) and I am eager to see what I can do with it.
After reading so many pages (including this one), on so many sites, I have decided that I will learn newlisp too.
I liked the code that I have seen at newlisp.org, newlisper.wordpress.com (for example) and I am eager to see what I can do with it.
After reading so many pages (including this one), on so many sites, I have decided that I will learn newlisp too.
[deleted]