newLISP future and updates

Notices and updates
Post Reply
S_Ghost
Posts: 2
Joined: Sat Nov 26, 2022 4:01 am

newLISP future and updates

Post by S_Ghost »

Hello All, my first post in the forum. I have recently fallen in love with the simplicity, approach, excellent documentation, and power of newLISP. I am seriously contemplating using it moving forward with my data analysis projects. Currently developing in C, D, Basic, and Java. Being new to the community is newLISP receiving regular updates and being kept in good order by a volunteer team, or is it only a single person (and what happens if that person can no longer provide the required updates). I ask this because before I invest much time and sweat in developing in the language I am hoping that its future is somewhat secure. I would be willing to contribute once I get a bit more up to speed myself. Thank you in advance for your kind opinions and thoughts. S_Ghost ~ 25 NOV 2022.

HPW
Posts: 1389
Joined: Thu Sep 26, 2002 9:15 am
Location: Germany
Contact:

Re: newLISP future and updates

Post by HPW »

Hello,

You may read this thread:

viewtopic.php?f=5&t=5225

Since newLISP is open-source you can do work on it under the given license.

Regards
Hans-Peter
Hans-Peter

S_Ghost
Posts: 2
Joined: Sat Nov 26, 2022 4:01 am

Re: newLISP future and updates

Post by S_Ghost »

Thank you Hans-Peter. Greatly appreciate your reply and the link. I wish Lutz the best. He is clearly of great intellect and has developed a real gem.
Kind regards,
S Ghost

Astrobe
Posts: 43
Joined: Mon Jan 11, 2010 9:41 pm

Re: newLISP future and updates

Post by Astrobe »

Regarding the future of Newlisp, and the prospect that sooner or later (later, hopefully), Lutz won't be able to maintain it:

Like OP I've evaluated multiple languages - namely Lua, TCL, Scheme, "portable" Shell scripting with Busybox, and my own thing - and I must say that the feature/size ratio is very good. Lua is fast, but has no "battery included" (without LuaRocks). Tcl is ok-ish but slower and bigger. Scheme is bigger too, and is not that portable. Shell scripting is actually multiple languages (Bash variants + the many domain specific languages like Awk, Sed).

When it comes to saying "look, download this program and use it to run this script" not many things beat Newlisp.

If I think about a version 11, and allow myself to think one would be allowed to make breaking changes, there are a number of things I would consider. This list is in random order of importance:
  • The internal I/O management is sub-par. I took a look at it because I was mistakingly using peek on a stream I was trying to read with readline. I saw that Newlisp both relies on C FILE* streams and in some cases fetches the characters one at a time from the OS. Truely, a feature like readline is important because a lot of data is text-based, and I think Newlisp would do better if it used its own caching instead of the FILE* blackbox.
  • Choose between setq and setf.
  • I would remove [if] in favor of cond. if. For "else-less" conditionals when/unless are more convenient, and for multiple alternatives I find cond more convenient.
  • case is rarely usable, I'd like cond to take that name.
  • More and more often, web APIs use HTTPS only, and Newlisp is not equipped for that while having everything else (JSON/XML). I'd like to see TLS support, but it would mean to tie Newlisp with a crypto library (openssl,...) which would make it more difficult to compile. This looks like a job for libCurl or Curl (through process pipes), but that's another kind of external dependency, so I'm not sure about which route one should take.
  • I think the option of using Java or Tk is now inferior to the javascript alternative - in other words, using the browser as a GUI front end. But the internal HTTP server Newlisp provides is limited, and the way it manages CGI not fitted for that use. One problem with browser GUIs is that HTML/JS were not made for highly interactive applications. It appears that websockets have won over the other hacks meant to overcome that limitation. Websocket support would be welcome in Newlisp. It could be a way to avoid CGI, but still I think a CGI mode of operation that calls directly Newlisp code (no spawning, no pipes between processes) would also be better for when you don't want to program most of the GUI part in JS.
  • I think Newlisp has every thing needed in its kit to implement an http server in pure lisp. "You could DIY then" you might think, but for performance, the most processing-heavy/annoying parts could be implemented as primitives (stuff like URL encoding/decoding or chunked transfer).
  • date/time functions favor the local time; every time I needed them I actually needed UTC. One can convert between local time and UTC of course, but it is error prone and difficult to test (in particular with daylight saving time).
  • Arrays - I think the FOOP stuff would benefit from supporting them (I'm thinking new Class but with arrays instead of lists). The reason for this is that most of the times, objects are just small and fixed data structures, a perfect fit for arrays. Also, the way array works makes it hard to use. IMO it should work just like list (drop the multidimension stuff, it's trivial to make arrays of arrays if you need that).
  • FOOP - this is purely cosmetic, but I don't like the way it is introduced. I'd like to downplay both the "functional' and "OO" parts by introducing it as a way to define new types (which is the core of the feature), and changing the self function into something else - maybe an "anamorphic variable".

Post Reply