Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
screenshotbot-oss
A Screenshot Testing service to tie with your existing Android, iOS and Web screenshot tests
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
No love for NPT (<https://github.com/nptcl/npt>)? Well, I get it, it is very, very new.
One note about ABCL is that it doesn't support TCO, which the Common Lisp spec doesn't mandate. For people who want a Lisp on the JVM and really want tail calls, I would recommend checking out Kawa (<https://www.gnu.org/software/kawa/index.html>).
There was a great comment about LispWorks over on the reddit discussion, linked here[0]. I really need to give it a shot at some point, especially as someone doing CL professionally.
I know that Lisp is popular on HN but that it's mostly a kind of zoo like experience where the proper devs come here to gawk at us but I really cannot recommend it enough for any kind of work. We use it for stock market analysis but almost every piece of code we write is CL. I'm currently trying to convince people to switch over our CSS over to LASS[1].
0: https://www.reddit.com/r/Common_Lisp/comments/11979q4/commen...
1: https://github.com/Shinmera/LASS
But no one is stopping you from building a "full modern standard library". I am doing just that with https://github.com/galdor/tungsten. Of course it would be nice to have a large company do all the work as it is the case for Go, but it is not going to happen. As always, you either do the work yourself or pay someone to do it.
The specification is limited, no doubt about that, but I am convinced that any modernization effort would end up in a huge mess with everyone trying to inject their own preferences from the languages they already know with no regard for the spirit of the original specification.
One should note that while it is true that the last CLISP release was a long time ago and there is not a lot of development going on right now, it's not dead. Bruno Haible just commited last week.
The repository is now at https://gitlab.com/gnu-clisp/clisp
I quite agree, so I'm making a meta-library to have useful libraries available out of the box: https://github.com/ciel-lang/CIEL/ It's CL, batteries included. You can use it as a library, as a core CL image (loads up faster), and as a binary to have a REPL, and to run scripts:
ciel --script myscript.lisp
This LispWorks comment on reddit is very interesting:
---
[cite]
As a Lispworks user, yes it is super pricey, but it does make sense for certain people. Arguably, Lispworks provides features that aren't available in any other programming language, Lisp or not.
* Support for just about every platform I can imagine. Yes it's expensive, but if I want to port to a new platform I can pay Lispworks, and get it over with. It'll mostly work without too much changes. It works on Android, iOS, Windows, Linux, Mac, and some really obscure systems.
* Application delivery with tree shaking. May be there are other languages that do this, but I haven't worked with something like this before in my career. (Maybe proguard for Java, but that's very rudimentary compared to LW's delivery). The tool I work on delivers a binary that people need to download during the CI jobs for every run, so having it be 100MB is way too big. After compression, my LW delivered binaries come to around 9MB.
* You mention support being expensive. Actually, for simple support questions LW does a pretty good job of responding back to you. I've asked tonnes of questions over the years, and have not paid for a separate support contract apart from the yearly maintenance contract. I suspect they like people asking questions, because then they fix those bugs and it becomes even more rock solid.
* The documentation is glorious. And in the off-chance that I need to know something that's not documented, I just mail them and they'll respond usually by the next working day.
* Very stable Java support (although the API could be better), let's me use the entire Java ecosystem of libraries when I need it.
* The platform itself is rock-solid. Now SBCL is fantastic, but when I ran my servers on SBCL, I would have a crash every now and then. With LW, I can have my server running weeks (current uptime is a month) with reloading code multiple times a day, and everything is still super stable.
There's more, but I think the rest is more negotiable. For instance, the FLI is a lot more polished than using CFFI, which makes a huge difference in productivity when writing native code. Or the fact that its remote-debugger facility can be used as a very stable protocol to programmatically control a remote LW process. I don't use the IDE btw, so I'm not even considering that. I don't use CAPI either, but I mean to someday.
2023, Arnold @tdrhq of Screenshotbot (https://github.com/screenshotbot/screenshotbot-oss) on reddit: https://www.reddit.com/r/Common_Lisp/comments/11979q4/common...
[/cite]
> That's what regular devs do, they don't even bother writing articles or commenting on HN :-)
I'll take the bait, and roll up several of my comments into one.
First, the support contract costs from the commercial vendors can make sense. It's one of the most expensive parts of software. We joke about fixing relatives' printers, but its not false. Support costs introduce a counter-balance.
Second, a message to everyone looking into or using QuickLisp, it uses http instead of https: https://github.com/quicklisp/quicklisp-client/issues/167
You can patch your version to fix this. I'd also recommend adding firewall rules to deny in case your patches roll back. And any other mitigation. Or stricter policies, such as not using it, if it makes sense for your organization.
And the AI bots? I hope there aren't people herding them who don't want to, that's how you get unloving brats and a crappy world.
LPM's warning is not surprising. It's common for libraries (dare I say open-source ones?), even if they work well. It's part of the stability game, once they are marked 1.0, they are stable. LPM works well (as reported by others).
QL wants to do it portably, there are easy workarounds, but yeah…
(just saw https://github.com/rudolfochrist/ql-https)
i think lisp-stat library is actually being developed. however one numerical cl library that doesnt get enough mention and is being constantly developed is petalisp for HPC
https://github.com/marcoheisig/Petalisp