Common Lisp Implementations in 2023
1–10 of 243 posts
Re: Common Lisp Implementations in 2023
#2No 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>).
Re: Common Lisp Implementations in 2023
#3I just spent months working on a large piece of software and could say without a doubt, Lisp is awesome! But I also want to say that most implementations are hashing out a spec written decades ago and not trying to improve what's obviously lacking -- a full modern standard library! Trying to piece together functionality from here and there (and Quicklisp which is an unversioned mess) will only take you so far and in the end you will realize the amount of time wasted chasing this great language! AFAIK Lisp needs more backing from the heavyweights to make any reasonable progress which I'm sure won't happen.
Re: Common Lisp Implementations in 2023
#4I always like seeing Common Lisp links, but personally I was a bit put off by the very strong anti-commercial comments about LispWorks and Franz.
I had a business idea requiring Common Lisp a few years ago and I purchased a LispWorks Professional license. Small standalone executables with a tree shaker [1] and I has received very good support without paying for the high priority support service. I also paid the maintenance fee last year for continued updates. Coincidentally, I am an advisor and chief architect for a small AI company and they use LispWorks also.
Many years ago, I worked as a consultant on a medical AI project and my customer paid a fair amount of money to Franz for software licensing and tech support that included helping with development. Incredibly useful!
I also love open source Common Lisp and Scheme implementations.
Anyway, I would respectfully suggest to the author to maybe tone down the rhetoric a bit since different individual developers and companies have different requirements.
[1] you can also make small standalone apps with SBCL by building from source and setting a flag to allow compressed heap files.
Re: Common Lisp Implementations in 2023
#5I just spent months working on a large piece of software and could say without a doubt, Lisp is awesome! But I also want to say that most implementations are hashing out a spec written decades ago and not trying to improve what's obviously lacking -- a full modern standard library! Trying to piece together functionality from here and there (and Quicklisp which is an unversioned mess) will only take you so far and in…
Good comments. Quicklisp has certainly helped.
A few years ago, after Common Lisp being my favorite language since around 1982, I thought that I might switch for my personal projects to Racket Scheme since it does have good library support. What holds me back is that I have found plentiful work opportunities over the last several decades with Common Lisp, but except for getting paid by Springer-Verlag to write a Scheme book, I have never been paid to use Scheme.
Also, to be really honest, so much of my work in the last ten years has involved deep learning, that I have somewhat reluctantly learned to love Python for writing short programs.
Re: Common Lisp Implementations in 2023
#6I just spent months working on a large piece of software and could say without a doubt, Lisp is awesome! But I also want to say that most implementations are hashing out a spec written decades ago and not trying to improve what's obviously lacking -- a full modern standard library! Trying to piece together functionality from here and there (and Quicklisp which is an unversioned mess) will only take you so far and in…
I think every programmer that tries common lisp eventually comes to the same conclusion, however none of the new versions of "standard" libraries got any traction to my knowledge. Usually it's used only by the author who created it which makes their code unique in some sense, like a recent post from Ron Garret [0].
The spec is really valued by cl community and I guess I'll tell an unpopular opinion now, but I think there could be a place for an ecosystem built around one of the compilers like sbcl with all the old cruft removed and a really good all purpose standard library (similar in capabilities to the one of go for example). What that will achieve is that it will allow new developers to write the code without reading on why the things were designed is a certain way 40 years ago because of now forgotten os or hardware limitation.
Similar to what was done with neovim project
[0]: http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited....
Re: Common Lisp Implementations in 2023
#7There 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...
Re: Common Lisp Implementations in 2023
#8First time one of my articles lands on HN! Feel free to ask any follow up question.
Re: Common Lisp Implementations in 2023
#9I always like seeing Common Lisp links, but personally I was a bit put off by the very strong anti-commercial comments about LispWorks and Franz. I had a business idea requiring Common Lisp a few years ago and I purchased a LispWorks Professional license. Small standalone executables with a tree shaker [1] and I has received very good support without paying for the high priority support service. I also paid the maint…
The commercial aspect is not a problem in my opinion (but again english is not my main language so I might have conveyed the wrong tone). The issue is the pricing model which may work for established company ready to invest money from the start, but is simply out of touch with independant developers and small companies exploring the possibility of using Common Lisp.
Open sourcing Lispworks and selling support contracts and an enterprise version (with CAPI, CORBA, etc.) would make more sense. The world has changed: all other languages have open source implementations; most servers are open source, most databases too. It is hard to convince a company to use Common Lisp, but even harder to justify paying for a proprietary implementation.
And for me personally, Lispworks would force me to buy two licenses (Linux and FreeBSD) for personal use, and two for my solo company. It simply does not make any sense financially speaking.
Re: Common Lisp Implementations in 2023
#10I just spent months working on a large piece of software and could say without a doubt, Lisp is awesome! But I also want to say that most implementations are hashing out a spec written decades ago and not trying to improve what's obviously lacking -- a full modern standard library! Trying to piece together functionality from here and there (and Quicklisp which is an unversioned mess) will only take you so far and in…
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.