newLISP was the butt of half the jokes on #scheme over a decade ago. I'm surprised it had enough uptake to stick around. Uniquely for a Lisp, all objects are deep-copied by value when passed around. It also doesn't have closures. To get around these and other limitations, it has a notion of contexts that are auto-dereferenced ("default functor calls") so you can pass values by reference with syntactic sugar. At least that's how I remember it--not sure how much has changed. The way you emulate closures in newLISP is morally similar to how cl.el does it for Emacs (true lexical closures are a late addition to Emacs Lisp), namely by generating a completely new function for each closure instance, with the closed-over values in the environment hard-wired into it.
In my opinion, you can find much better versions of this sort of thing in Tcl, if for some reason you really want it.
Props to the author for keeping it going for this long, though.
newLISP is a language to replace sh/bash/perl. I don't know of any other s-expression language targeting that space?
The thing is, if you look at what people on various programming language channels mock, bash et al should be the target of widespread derision. It does everything "wrong" and is an absolute mess. Yet all of these languages do a really good job of being super simple to use when you quickly need to automate something, even if the result is an unreadable, unmaintainable mess. It's ease of writing that is being optimized for, not reading/maintenance. But a big chunk of the code I actually write is in the category of write-once, use-once, never-read. (Reorganizing data on disk, doing a one-time data cleanup or reduction, renaming deeply nested files matching certain patterns, tabulating data, etc.)
newLISP, as far as I can tell, is an attempt to apply s-expressions to the same niche, and it makes the same sort of ugly, aesthetically horrifying compromises that shell languages (+ perl) do. But the only questions of import, I think, is: does it work? Is it quick to use? Is it simple, and not mentally taxing to automate something in newLISP?
If so, I'd much rather code in newLISP than write another hideous bash loop.
> all of these languages do a really good job of being super simple to use when you quickly need to automate something... It's ease of writing that is being optimized for, not reading/maintenance.
I think of shells as being optimised for/excellent at:
- Standard input/output redirection (pipes, file reading/writing, etc.)
- Command line interaction
- Being installed by default (on Unix-like systems, anyway)
They also have some nifty string handling, but as you say it's quite messy compared to other languages. Some other languages have reasonable commandlines and are usually available by default (e.g. Python), but the majority of languages are awful at the first two points (e.g. I wrote an example at https://news.ycombinator.com/item?id=17733865 ). This is why there are many libraries which try to improve the situation, like 'sh.py' and 'plumbum' for Python, 'Shelly' and 'Turtle' for Haskell, Scala's 'process' package, 'shell-pipeline' for Racket, etc.
> I don't know of any other s-expression language targeting that space?
Others have mentioned some. I really like scsh (Scheme shell), there was a nice paper about it posted to HN recently ( https://news.ycombinator.com/item?id=17886714 ). The shell-pipeline package mentioned above is really nice, and usable from Racket (a variant of Scheme, which uses s-expressions by default).
As an amateur Lisp enthusiast, flipping through newLISP's introductory material, I found "Comparison to Common Lisp and Scheme" [0] a fascinating read.
Ah, Newlisp. The language whose community makes the Rust Evangelism Strike Force go "hey, guys, can you take it down a notch?" More than once have I seen a programming community get a contingent of Newlisp advocates airdropped into it, only to repeat the same tired Amway-tier sales pitches about how Newlisp is the first Lisp-based language, ever, to be used for practical applications. Which is true only if you ignore the decades of computer science that have been done outside Lutz Mueller's brain. And despite calling itself "new" it uses ideas old enough to sign up for AARP membership, that have been tried and abandoned early in Lisp's development, precisely because they're impractical or a source of bugs when attempting to build real-world applications.
So yeah, unless something's changed, it's gonna be a no from me. Don't get me wrong, Newlisp is interesting -- in sort of the same way TempleOS is. But its aggressive tryhard advocacy community just put me right off a language I otherwise might've given a spin.
I'm sorry you've had bad experiences with newLISP evangelists. In my experience, every single language has overly eager evangelists, and it's best not to let them affect one's overall view of things.
I am a huge newLISP advocate, and I would never dream of claiming that the language was a) first at anything, b) first to be used for practical applications, or c) does not have any limitations or flaws.
I chose to investigate the language about six years ago because I wanted to create web applications with Lisp, and I was having a lot of difficulty getting Common Lisp and Hunchentoot working (purely because of my own ignorance, I'm sure).
Newlisp, and the Dragonfly web framework, had the following advantages to me at the time:
0. It had really clear and easy to understand documentation
1. It was easy for me to get started
2. The syntax was really clean and simple
3. It had native support for parsing XML into S-expressions in a simple way that worked even with very complex XML (which was the case with the application I wanted to build at the time)
4. When combined with Dragonfly, it made it possible to create web applications that were really really fast.
I liked it so much that I ended up making my own web framework, newlisponrockets.com, based on Dragonfly. Since then I've used this framework to make my own website and to create internal tools and prototypes at work.
I don't consider myself a great or knowledgeable programmer, and I can't refute any of the people on Hacker News who mention that newLISP lacks this feature or has this poor design decision. I'm sure both of these things are true. I would never try to sell the language with an Amway-style sales pitch, or claim that it could do things that other languages couldn't.
What I do claim is that it was (and is) a very helpful and useful language for me. That's all.
Ah, if newLISP had only dispensed with the "new" and "lisp" in its name, it might be viewed in an entirely different vein. Alas, it did not and thus nearly committed language seppuku.
As to the language itself, as a casual programmer I very much like it. Its use is clear, it's well documented, and it's self-contained (and thus easily installed).
Not only its name; what it could have done without was all the posturing in the documentation about how it is better than previous Lisps, and renders them obsolete.
I find it interesting that they positon newlisp as being "for embedded systems", because from everything I've read it requires a Unix system to run on.
Anyone here running newlisp on a microcontroller or similar and able to comment?
A few years ago I compiled it on my old Nokia N900 - not a microcontroller of course, but limited than my desktop computer. I was even able to host simple websites on it using Dragonfly Web Framework for newLISP (I'm one of the authors).
It's been a while since I used it on "embedded systems" but in our case it was running on top of OpenWRT and OpenBSD on appliance-like SOC systems (think of Soekris and Mikrotik), not directly on microcontrollers.
newLISP is a Lisp-like, general-purpose scripting language. It is especially well-suited for applications in AI, simulation, natural language processing, big data, machine learning and statistics. Because of its small resource requirements, newLISP is excellent for embedded systems applications. Most of the functions you will ever need are already built in. This includes networking functions, support for distributed and multicore processing, and Bayesian statistics.
Now I can train a neural net to calculate the probability that a distributed computation will fail without having to type `require`.
I worked with Lutz, the primary developer, briefly in 2006. I used NewLISP for a few years after that, mostly for distributed computing with net-eval(). I briefly tried using it as a systems programming language where one might have reached for Perl or the then-up-and-coming Ruby or Python. If you like lispy languages, you'll probably enjoy playing with it.
In my opinion, you can find much better versions of this sort of thing in Tcl, if for some reason you really want it.
Props to the author for keeping it going for this long, though.