A newlisp twin that died 3 years ago?

[lithper]

I recently dug out a reference to New Lisp and was very, very much impressed by the quality of the language:



1. Bits of the processing flow of my perl webscript/blogging engine, which  I prided myself for optimizing for speed, when recoded for test in NL ran roughly 2 times faster. Same algorithm, just recoded straightforwardly, with the provided equivalent or close in meaning NL operators



We'll see if the difference persists after I complete the port ;))



2. "Grep" in NewLisp seems to run with the speed of the C-coded GNU grep on my linux box, or almost (say, 0.458 seconds in NL against 0.450s with grep) when I tested it on a text copy of the Origin of Species (although comparison is not straightforward; at least they are "comparable")



3. However one even bigger advantage seems to be in the precision packing of the functionality into one executable. This is probably what a newer generation scripting language should look like - no more need to add modules/libraries and/or separate tiny utilities to make a typical web or other mainstream app run from the bare core language binary.





First I explained it by the intelligence of  NL creator. However, it seems that he was standing "on the shoulders of the giants", and things in the Lisp community are generally more mm.. advanced than in other scripting language circles.





That is what I began to believe when I discovered REFLISP - another, virtually identical packaging of a dialect of LISP with a web server and all needed libraries in a 126k binary:

"Reflisp", http://reflisp.sourceforge.net">http://reflisp.sourceforge.net



The project is written in C++, uses a more "standard" CL set of commands and syntax, has poor documentation (in the form of wiki pages in a wiki coded in Reflisp, which is supposed to be available on startup after a compilation), "installs" itself in a sort of "crooked" way (one may run it from the compilation tree, and/or would have to set and keep an environment var to point to the top of the installation, $REFLISPDIR, plus run it from a wrapper script.

So it's clumsier than NL and does not have that critical entry point: excellent tutorials and documentation.



The project, however, has been dead since 2005, and googling on the author's name one can come across a message (living under 1 April 2005 in his blog) that he is abandoning the project after all those years.  No joke this time?



Has anyone looked at this forgotten twin brother of NL? Run any tests (it seems to be able to accept CL scripts, probably with the help of some  macros) ?



And could anyone enlighten me, a longtime citizen of the unix world, and a thinker in C/shell/perl terms, but a newcomer to Lisp, if it's considered standard to package a language in the way NL and Reflisp are, or are those two just lucky exceptions?

[Fanda]

Link that worked for me is:

http://sourceforge.net/projects/reflisp/">http://sourceforge.net/projects/reflisp/



LISP is an ancient language and I am not surprised that there are so many implementations. At the same time it's interesting to see another language so close to newLISP. I guess - good ideas never die! ;-)



Fanda

[cormullion]

Hi! Interesting post.

First I explained it by the intelligence of  NL creator. However, it seems that he was standing "on the shoulders of the giants", and things in the Lisp community are generally more mm.. advanced than in other scripting language circles.

I think both are probably the case! If I stood on the shoulders of giants I wouldn't do anything as neat as newLISP.

Has anyone looked at this forgotten twin brother of NL? Run any tests (it seems to be able to accept CL scripts, probably with the help of some  macros) ?

It does look like it's related to newLISP, in concept, at least, when it's described as having 'an built-in web server, Wiki, LISP server pages, SQL Databases, XML parser, MD5 hashing, regular expressions...'. Although newLISP's wiki isn't built-in, and the md5 isn't quite built-in. But both have dynamic scoping, so they would both be sneered at by the purist anyway.



I'm interested in how languages evolve and die out. If they're used for 'real-world' tasks rather than as 'proofs of concept' or intellectual adventures, they ought to have a better chance of surviving, but even that isn't certain these days. I know that newLISP has been used in at least one commercial environment in the past. (For all I know, Lutz might be negotiating with Steve Ballmer at Microsoft to replace Visual Basic with newLISP for the next version of Windows...) Perhaps RefLisp was the HD-DVD to newLISP's BluRay... Or perhaps the author decided to focus on his Genyris project instead.

[Elica]

However one even bigger advantage seems to be in the precision packing of the functionality into one executable. This is probably what a newer generation scripting language should look like ... And could anyone enlighten me, a longtime citizen of the unix world, and a thinker in C/shell/perl terms, but a newcomer to Lisp, if it's considered standard to package a language in the way NL and Reflisp are, or are those two just lucky exceptions?

I'm not sure about Lisp, but what I'm doing with Lhogho (i.e. my Logo compiler) can be done with newLisp too ... if the developers like the idea.



Namely, if I use LHOGHO to compile program A, then the resulting binary will execute the instructions of A but in the same time it will also contain the compiler itself. Consider it as program inheritence (rather then class inheritance).



Then, the binary of A can be used to compile B (without the need to have LHOGHO itself, because A already knows how to compile), so if you run the generated binary of B it will run the commands in A and B.



Here is how I plan to use it (I'll use Windows notation of files):



LHOGHO.EXE - the pure compiler

LHOGHOGL.LGO - wrapper of OpenGL API written in Logo



If I compile LHOGHOGL.LGO I will generate:



LHOGHOGL.EXE -- the compiler+OpenGL API



Further on, if I have the source of the turtle graphics TURTLE.LGO, then I can generate TURTLE.EXE, which will be the LHOGHO compiler enhanced by OpenGL API and Turtle graphics.



This LHOGHO.EXE will inherit from the LHOGHO, from the OpenGL program and from the Turtle graphics problem ... and still it will be a single file.





Does this make any sense to you?