Common Lisp Implementations in 2023(n16f.net)
n16f.net
Common Lisp Implementations in 2023
https://www.n16f.net/blog/common-lisp-implementations-in-2023/
242 comments
I am convinced that Lispworks is a great product. From what I can see it comes with a nice IDE and some nice libraries. I would have loved to give it a try, but unfortunately I was never able to do do so. And that is where the critique of the licensing scheme comes from. I am sure there are quite a few professionals for whom Lispworks has great value and the license costs are just a non-issue. But despite being a professional Lisp programmer for more than 15 years, I never came close to licensing Lispworks. Nor in the 20 years of being a Lisp enthusiast.
As an enthusiast, I would be happy to spend a few hundred € for private usage, but not thousands. I would like to be able to really evaluate the product before spending a significant amount of money on it, but with the limits of the personal edition, it immediately quit on the first attempt of starting my back-then tiny hobby project.
Don't get me wrong, a company has the right to select the business model which fits them best and I might not be their intended audience. But that is why I never bought from them and as I never used the product didn't really put under strong consideration when choosing a Lisp implementation for commercial work.
On the other side, with SBCL I have a really strong Lisp implementation. The compiler is likely to produce better code and it is readily available. Slime might lack the fanciness of a standalone IDE, but as a longtime Emacs user, that might actually be an advantage.
As an enthusiast, I would be happy to spend a few hundred € for private usage, but not thousands. I would like to be able to really evaluate the product before spending a significant amount of money on it, but with the limits of the personal edition, it immediately quit on the first attempt of starting my back-then tiny hobby project.
Don't get me wrong, a company has the right to select the business model which fits them best and I might not be their intended audience. But that is why I never bought from them and as I never used the product didn't really put under strong consideration when choosing a Lisp implementation for commercial work.
On the other side, with SBCL I have a really strong Lisp implementation. The compiler is likely to produce better code and it is readily available. Slime might lack the fanciness of a standalone IDE, but as a longtime Emacs user, that might actually be an advantage.
> As an enthusiast, I would be happy to spend a few hundred € for private usage, but not thousands.
Note that the cost for private usage starts at a few hundred €. You only get to "thousands" if you include multiple platforms or several support incidents.
Note that the cost for private usage starts at a few hundred €. You only get to "thousands" if you include multiple platforms or several support incidents.
Professional starts at $1500 for the 32-bit edition. That price doubles for 64-bit. Need to connect to a database and use their ORM? That’s another $1500. Want to do a cross platform mobile app? Add another $2000.
Need windows and Mac? That’s another $4500 for each.
A cross platform app would cost $15,500 PER DEVELOPER.
I work for a fortune 500 company and they’d just say no at those prices. It’s an absolute no go for regular companies.
Need windows and Mac? That’s another $4500 for each.
A cross platform app would cost $15,500 PER DEVELOPER.
I work for a fortune 500 company and they’d just say no at those prices. It’s an absolute no go for regular companies.
Okay but why would you do that in a large company, you don't need every single developer triple booting. You've got 150 people and 25 of are RHEL, 25 are macos and 100 are windows.
and also the 5k license is a one time fee. over the course of say 5 years its
I'm not saying it's cheap mind you but even at 3700 a year * 100 devs, if your bumping up against sharp edges in SBCL: 370000 only gets you 1-2 devs to work on those edges.
At the size of a Google adding developers works out to be cheaper than licensing software for all the existing devs. But a lot of companies don't have high 3-4 digits worth of devs such that they can break off a team to work on support technology instead of core internal business apps or products.
and also the 5k license is a one time fee. over the course of say 5 years its
5100 [first two years]
+ (1125 * 3) [next three]
= 1695 a year [asymptotically approaching 1125]
+ (5 * 2000)[the mobile runtimes *are* annual although as with desktop you wouldn't actually need everyone to have both, or either]
= 3695 a year [asymptotically approaching 3125]
I'm not saying it's cheap mind you but even at 3700 a year * 100 devs, if your bumping up against sharp edges in SBCL: 370000 only gets you 1-2 devs to work on those edges.
At the size of a Google adding developers works out to be cheaper than licensing software for all the existing devs. But a lot of companies don't have high 3-4 digits worth of devs such that they can break off a team to work on support technology instead of core internal business apps or products.
No matter how you slice it, Java enterprise would only cost $180/yr which is almost 10x better than your best estimate
Let's say you have 25 devs on a 5-year project. 5 of them are mobile focused, 5 are windows focused, 5 are mac/Linux focused, and 10 are focused on the cloud/server side of the project.
We'll make the (probably bad) assumption that you don't need enterprise licenses for the desktop app portion. We'll further assume that windows devs use only windows and backend devs use only Linux while mobile and mac/Linux devs use both the systems they work on.
I'd calculate these for LispWorks, but they don't even provide that option at all. If you forego maintenance entirely, you're still stuck with $115,000 the first year and $40,000 for the remaining 4 years of subscription to mobile meaning your absolute minimum here is $155,000 and exceeds even the top-end budget for a Java project. If you turn out to need the Enterprise version for the non-backend devs and want maintenance, that cost goes up to $267,875.
The difference in money is enough to provide every team member with a new $4,000 laptop year 2 and again year 4 OR to increase their yearly bonus by $1600.
Let's say you have 25 devs on a 5-year project. 5 of them are mobile focused, 5 are windows focused, 5 are mac/Linux focused, and 10 are focused on the cloud/server side of the project.
We'll make the (probably bad) assumption that you don't need enterprise licenses for the desktop app portion. We'll further assume that windows devs use only windows and backend devs use only Linux while mobile and mac/Linux devs use both the systems they work on.
First 2 years (because we get a discount on year 1 maintenance)
$17,000 for 5 64-bit windows professional
$51,000 for 10 64-bit linux enterprise
$37,000 for 5 64-bit mac professional and 5 pairs of mobile for 2 years
$34,000 for 5 64-bit mac professional and 5 64-bit linux professional
$139,000 for first 2 years
Next 3 years (maintenance and mobile annual fees)
$11,250 for 5 64-bit windows professional
$33,750 for 10 64-bit linux enterprise
$41,250 for 5 64-bit mac professional and 5 pairs of mobile for 3 years
$22,500 for 5 64-bit mac professional and 5 64-bit linux professional
$108,750 for next 3 years
$247,750 for project.
First 2 years
$9,000 - 25 devs for 2 years of enterprise Java
$14,975 - 25 devs for year 1 of IntelliJ Ultimate ($599/yr/dev)
$11,975 - 25 devs for year 2 of IntelliJ Ultimate ($479/yr/dev)
$35,950 for first 2 years
next 3 years
$13,500 - 25 devs for 3 years of enterprise Java
$8,975 - 25 devs for year 3-5 of IntelliJ Ultimate ($359/yr/dev)
$22,475 for next 3 years
$58,425 for project
I'd calculate these for LispWorks, but they don't even provide that option at all. If you forego maintenance entirely, you're still stuck with $115,000 the first year and $40,000 for the remaining 4 years of subscription to mobile meaning your absolute minimum here is $155,000 and exceeds even the top-end budget for a Java project. If you turn out to need the Enterprise version for the non-backend devs and want maintenance, that cost goes up to $267,875.
The difference in money is enough to provide every team member with a new $4,000 laptop year 2 and again year 4 OR to increase their yearly bonus by $1600.
Well, it starts at €480 (Linux) - €720 for the Mac for a pure IDE, without the ability to produce executables. You are limited to run your programs inside the development environment, this limits its applicability a lot. You can't write a simple command line utility this way, just to name one example. You cannot give it to a friend etc. The HobbyistDV edition is in my eyes the first really usable one. It is already over €1400, and that is for a single OS, a single CPU architecture. Especially as a hobbyist I might be able to play around with it a bit. I would be interested if there is any customer who has more than one hobbyistDV license. And that doesn't seem to include any updates.
> The HobbyistDV edition is in my eyes the first really usable one. It is already over €1400
Less than 1000 if you can live with 32 bits but I wonder if someone goes for that option nowadays.
> and that is for a single OS, a single CPU architecture.
The MacOS version supports both Apple Silicon and Intel.
Less than 1000 if you can live with 32 bits but I wonder if someone goes for that option nowadays.
> and that is for a single OS, a single CPU architecture.
The MacOS version supports both Apple Silicon and Intel.
The macOS version is not available as 32-bit edition so it is twice as expensive as the cheapest 32-bit version.
Also, you are not allowed to give a saved image away / cannot run it without the licensed LispWorks installation.
Also, you are not allowed to give a saved image away / cannot run it without the licensed LispWorks installation.
> Also, you are not allowed to give a saved image away / cannot run it without the licensed LispWorks installation.
I think you're not talking now about the HobbyistDV version mentioned in the parent comment, are you?
I think you're not talking now about the HobbyistDV version mentioned in the parent comment, are you?
macOS itself is no longer available as 32-bit edition, but as 64bit versions on two processor platforms.
> Less than 1000 if you can live with 32 bits but I wonder if someone goes for that option nowadays.
Right. I don't count the 32 Bit versions as serious contenders.
> The MacOS version supports both Apple Silicon and Intel.
That is good news. For pure Mac users this is interesting, still very expensive. Personally, my development time is split between MacOS and Linux.
Right. I don't count the 32 Bit versions as serious contenders.
> The MacOS version supports both Apple Silicon and Intel.
That is good news. For pure Mac users this is interesting, still very expensive. Personally, my development time is split between MacOS and Linux.
By the way, this is not completely correct:
> You are limited to run your programs inside the development environment, this limits its applicability a lot. You can't write a simple command line utility this way, just to name one example.
You can save and run a console-only image which doesn't start the graphical IDE.
> You are limited to run your programs inside the development environment, this limits its applicability a lot. You can't write a simple command line utility this way, just to name one example.
You can save and run a console-only image which doesn't start the graphical IDE.
> I would like to be able to really evaluate the product before spending a significant amount of money on it, but with the limits of the personal edition, it immediately quit on the first attempt of starting my back-then tiny hobby project.
Usually one contacts the vendor and asks for a time-limited full version of the product for evaluation.
> On the other side, with SBCL I have a really strong Lisp implementation.
That's one of the advantages of a language standard with multiple competing / complementing implementations.
Usually one contacts the vendor and asks for a time-limited full version of the product for evaluation.
> On the other side, with SBCL I have a really strong Lisp implementation.
That's one of the advantages of a language standard with multiple competing / complementing implementations.
> Usually one contacts the vendor and asks for a time-limited full version of the product for evaluation.
Yes, if there is already the deep desire to acquire Lispworks, this would be the way to go. But I never arrived at that point. It is also a bit odd to have a personal edition which supposedly is usable for evaluation, but it really isn't. As I said before, I might not be their target customer, but on the other side, my experiences might be more common, so I am presenting them here.
Yes, if there is already the deep desire to acquire Lispworks, this would be the way to go. But I never arrived at that point. It is also a bit odd to have a personal edition which supposedly is usable for evaluation, but it really isn't. As I said before, I might not be their target customer, but on the other side, my experiences might be more common, so I am presenting them here.
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.
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.
> Open sourcing Lispworks and selling support contracts and an enterprise version (with CAPI, CORBA, etc.) would make more sense.
I don't think it makes any sense, since the market for such complex Lisp systems is tiny. It would not generate a reliable revenue stream for such a niche technology.
It's not that it has not been tried in the past, but all Lisp vendors from the past, and there were a dozen or more with different license models / pricing, have gone. Left are Franz and LispWorks. Both are 30+ years in business.
I don't think it makes any sense, since the market for such complex Lisp systems is tiny. It would not generate a reliable revenue stream for such a niche technology.
It's not that it has not been tried in the past, but all Lisp vendors from the past, and there were a dozen or more with different license models / pricing, have gone. Left are Franz and LispWorks. Both are 30+ years in business.
They know their locked-in customers, but they also know they don’t get many additional customers at those prices either.
The market is small anyway. Better have customers at all. Mabe the customers are not "locked in", but happy that there are remaining offerings.
See the pricing for commercial Smalltalk. Same thing.
See the pricing for commercial Smalltalk. Same thing.
> The issue is the pricing model which may work for established company ready to invest money from the start, but ...
That's a much more nuanced way to put it - compared to "The professional and enterprise licenses do not really make sense for anyone".
That's a much more nuanced way to put it - compared to "The professional and enterprise licenses do not really make sense for anyone".
> That's a much more nuanced way to put it - compared to "The professional and enterprise licenses do not really make sense for anyone".
Where does he say that?
Where does he say that?
I've read it and if you're referring to this:
> I do not have anything personal against commercial software, and I strongly support developers being paid for their work. But this kind of licensing makes Lispworks irrelevant to everyone but those already using their proprietary libraries.
is he wrong?
Go ask 100 random devs working for various companies. My money's on 99% on them avoiding those licensing terms in favor of probably anything else.
> I do not have anything personal against commercial software, and I strongly support developers being paid for their work. But this kind of licensing makes Lispworks irrelevant to everyone but those already using their proprietary libraries.
is he wrong?
Go ask 100 random devs working for various companies. My money's on 99% on them avoiding those licensing terms in favor of probably anything else.
In case it was not clear I was referring to this literal quote from the linked article:
"The professional and enterprise licenses do not really make sense for anyone"
"the pricing model which may work for established company ready to invest money from the start"Ah, I was looking at the wrong quote.
However, I think techies are too nitpicky.
In casual use "everyone" or "anyone" do not mean: "I literally asked everyone on the surface of the planet".
And he's not wrong.
Unless you have a preexisting commitment to Lisp and ecosystem or your needs are so specific that you need this precise piece of software, you won't use it.
However, I think techies are too nitpicky.
In casual use "everyone" or "anyone" do not mean: "I literally asked everyone on the surface of the planet".
And he's not wrong.
Unless you have a preexisting commitment to Lisp and ecosystem or your needs are so specific that you need this precise piece of software, you won't use it.
I think it's a prior that anyone considering the choice of a Common Lisp implementation for production has a preexisting commitment to Lisp.
What's an example of something that is used for production without preexisting commitment?
Someone who's a language polyglot choosing a programming language for a new system, without external constraints (legal requirements, client mandating tech, closed developer stack, etc).
They have the luxury of choosing the most mature ecosystem.
That kind of person, and there are a fair amount of these around, will look at this kind of enterprise/niche pricing and go that: that's crazy, I'll just use Java/C#/Go/Rust/whatever else.
They have the luxury of choosing the most mature ecosystem.
That kind of person, and there are a fair amount of these around, will look at this kind of enterprise/niche pricing and go that: that's crazy, I'll just use Java/C#/Go/Rust/whatever else.
On the page, commenting about LispWorks.
[deleted]
You wrote of LispWorks: “ The professional and enterprise licenses do not really make sense for anyone”
Perhaps a question I would ask is what are you trying to convey with this statement? It appears to be quite subjective.
Perhaps a question I would ask is what are you trying to convey with this statement? It appears to be quite subjective.
You quote him saying "The professional and enterprise licenses do not really make sense for anyone"
your quote is the definition of "out of context", you left out his colon leading to the rest of his sentence where he explains what he means, i.e. what you are asking.
"The professional and enterprise licenses do not really make sense for anyone: you will have to buy separate licenses for every..." ...now, I'm not quoting the rest of it because while it's easy to engage with a substantive argument, you didn't say anything.
Still your move.
your quote is the definition of "out of context", you left out his colon leading to the rest of his sentence where he explains what he means, i.e. what you are asking.
"The professional and enterprise licenses do not really make sense for anyone: you will have to buy separate licenses for every..." ...now, I'm not quoting the rest of it because while it's easy to engage with a substantive argument, you didn't say anything.
Still your move.
Since you're going to be a condescending pendant...everything after the colon is why it doesn't make sense for him, not why it doesn't make sense for anyone, and it's very clear that's the point he's making. It's a common fallacy around here: "I think this, therefore it's applicable to everyone".
I assume you have some specific needs that couldn't be handled by open source Lisps like SBCL, CCL, etc?
No, his needs are probably better handled by Java or .NET or Go or whatever. And that's how Lisp atrophies. The complaint is a valid one.
Enterprise Java licenses are charged per developer seat, just saying.
Hasn't this just recently changed to per employee?
https://www.infoworld.com/article/3686611/oracle-per-employe...
https://www.infoworld.com/article/3686611/oracle-per-employe...
$15/mo or $180/yr.
Lispworks for that same platform support would cost about $20,000 per dev the first year then a few thousand every year after.
You could buy 100 years of enterprise Java support for Jay one year of Lispworks.
Lispworks for that same platform support would cost about $20,000 per dev the first year then a few thousand every year after.
You could buy 100 years of enterprise Java support for Jay one year of Lispworks.
The Java license costs per employee. Not per developer. That's an entirely different business model in a very different market for a very different tool.
It's a bit like claiming that your AMG Mercedes has a different pricing than a corporate car of a large fleet managed by a large rental company. That's trivially true, but you are comparing very different things.
It's a bit like claiming that your AMG Mercedes has a different pricing than a corporate car of a large fleet managed by a large rental company. That's trivially true, but you are comparing very different things.
Any company worth their salt doesn't pay for that, though. Heck, even stuffy enterprises like banks, who usually pay for everything, frequently don't do that.
The main JDK distros are big and stable enough to make this strategy viable in an enterprise environment.
The main JDK distros are big and stable enough to make this strategy viable in an enterprise environment.
Are there studies on the rate of project success comparing effort in A: JDK, .NET; and B: Go, Lisp at high status yacht racing sponsored by big names? There was a headline indicating failure is 68% all over in tech.
And, does paying for it more and more make a difference to success overall? Banks were leaving their terminals on overnight with bright white screens without powering them off which crypto entrepreneurs could have used the power for grinding out tokens.
And, does paying for it more and more make a difference to success overall? Banks were leaving their terminals on overnight with bright white screens without powering them off which crypto entrepreneurs could have used the power for grinding out tokens.
> Are there studies on the rate of project success comparing effort in A: JDK, .NET; and B: Go, Lisp
No, there aren't and anyone saying otherwise is lying.
Almost all relevant data is tightly locked up in corporate software development silos (FAANG, enterprise middle ware, website or mobile dev shops, game devs, etc). The few studies that we have are limited to academic (basically toy projects) or OSS settings (and we don't really have the behind the scenes info from the corporate sponsors) and their sample sizes are pitiful.
Plus, what even is success? Adoption after 1 year? After 10 years (https://www.joelonsoftware.com/2001/07/21/good-software-take...)?
What we can measure instead is the number of developers, jobs, projects started based on public announcements, etc.
And for that it's no contest. Java/C# >> Go >>>>>>> Lisp.
The reasons are less important than the facts on the ground.
Especially since Common Lisp was first proposed in 1982 (41 years ago), so a really long time ago. However, its rivals aren't spring chickens either, these days. Java was launched in 1995, 27 years ago (early Java devs are close to retirement, already), C# was launched in 2000, 23 years ago, heck, even Go was launched in 2019, that's 13 years ago.
So we're in a reality were we have multiple competing ecosystems that are big and developed and have been around for decades. So the mainstream ones will be major for a long time.
No, there aren't and anyone saying otherwise is lying.
Almost all relevant data is tightly locked up in corporate software development silos (FAANG, enterprise middle ware, website or mobile dev shops, game devs, etc). The few studies that we have are limited to academic (basically toy projects) or OSS settings (and we don't really have the behind the scenes info from the corporate sponsors) and their sample sizes are pitiful.
Plus, what even is success? Adoption after 1 year? After 10 years (https://www.joelonsoftware.com/2001/07/21/good-software-take...)?
What we can measure instead is the number of developers, jobs, projects started based on public announcements, etc.
And for that it's no contest. Java/C# >> Go >>>>>>> Lisp.
The reasons are less important than the facts on the ground.
Especially since Common Lisp was first proposed in 1982 (41 years ago), so a really long time ago. However, its rivals aren't spring chickens either, these days. Java was launched in 1995, 27 years ago (early Java devs are close to retirement, already), C# was launched in 2000, 23 years ago, heck, even Go was launched in 2019, that's 13 years ago.
So we're in a reality were we have multiple competing ecosystems that are big and developed and have been around for decades. So the mainstream ones will be major for a long time.
Oh wow so offering a paid tool when free ones are available is not the offense after all, as we are finding out!
I am also curious about this, what specific needs are better served by CL than Clojure or any Scheme / Racket?
Starting a CL project in 2023 seems risky to me given that most libraries are stagnant. I would love to be proven wrong.
Starting a CL project in 2023 seems risky to me given that most libraries are stagnant. I would love to be proven wrong.
Could it be that most of the critical libraries are stable? Can you give an example of a necessary library that is stagnant?
CLSQL, most graphics toolkits or lisp-stat.
for ORM people tend to use Mito. 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/fukamachi/mito
https://lisp-stat.dev/
https://github.com/marcoheisig/Petalisp
https://github.com/fukamachi/mito
https://lisp-stat.dev/
https://github.com/marcoheisig/Petalisp
Thanks for mentioning Mito, I had not seen that before. I used to rely on database migrations with Ruby’s ActiveRecord, it would be nice to have that for CL.
for my use case its just that the common lisp compilers, SBCL in particular, blow anything Clojure or Scheme/Racket has to offer. on the other hand the stability of the language should not be underestimated, but this is something you feel after years of use
on the other hand i think the common lisp development culture is very different to the black box library plug&play culture of other languages. if you find that you like to extend/personalise libraries it is a great language and i find the code to be much more comprehensible than the libraries from other languages i use. of course this is all a bit more demanding on the developer but for me the rewards are worth it
on the other hand i think the common lisp development culture is very different to the black box library plug&play culture of other languages. if you find that you like to extend/personalise libraries it is a great language and i find the code to be much more comprehensible than the libraries from other languages i use. of course this is all a bit more demanding on the developer but for me the rewards are worth it
The linux lispworks runs fine for me on Freebsd with linux_compat.
> I 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.
What? I found it informative - clear and to the point about what frustrations you can expect with the licenses.
I mean, FCOL, he even made the effort to search google for the cost of the licenses because Franz hides them.
What exactly in the following texts do you describe as "strong anti-commercial comments"?
------------------------------------------------------
> Moving to proprietary implementations; Lispworks has been around for more than 30 years and the company producing it still release new versions on a regular basis.
> While Lispworks supports most features you would expect from a commercial product (native compiler, multithreading, FFI, GUI library, various graphical tools, a Prolog implementation…), it is hampered by its licensing system.
> The free “Personal Edition” limits the program size and the amount of time it can run, making it pretty much useless for anything but evaluation. The professional and enterprise licenses do not really make sense for anyone: you will have to buy separate licenses for every single platform at more than a thousand euros per license (with the enterprise version being 2-3 times more expensive). Of course you will have to buy a maintenance contract on a yearly basis… but it does not include technical support. It will have to be bought with “incident packs” costing thousands of euros; because yes, paying for a product and a maintenance contract does not mean they will fix bugs, and you will have to pay for each of them.
-----------------------------------
Releases are uncommon, the last one being almost 6 years ago. But Allegro is a mature implementation packed with features not easily replicated such as AllegroCache, AllegroServe, libraries for multiple protocols and data formats, analysis tools, a concurrent garbage collector and even an OpenGL interface.
Allegro suffers the same issue as Lispworks: the enterprise-style pricing system is incredibly frustrating. The website advertises a hefty $599 starting price (which at least includes technical support), but there is no mention of what it contains. Interested developpers will have to contact Franz Inc. to get other prices. A quick Google search will reveal rumours of enterprise versions priced above 8000 dollars. No comment.
What? I found it informative - clear and to the point about what frustrations you can expect with the licenses.
I mean, FCOL, he even made the effort to search google for the cost of the licenses because Franz hides them.
What exactly in the following texts do you describe as "strong anti-commercial comments"?
------------------------------------------------------
> Moving to proprietary implementations; Lispworks has been around for more than 30 years and the company producing it still release new versions on a regular basis.
> While Lispworks supports most features you would expect from a commercial product (native compiler, multithreading, FFI, GUI library, various graphical tools, a Prolog implementation…), it is hampered by its licensing system.
> The free “Personal Edition” limits the program size and the amount of time it can run, making it pretty much useless for anything but evaluation. The professional and enterprise licenses do not really make sense for anyone: you will have to buy separate licenses for every single platform at more than a thousand euros per license (with the enterprise version being 2-3 times more expensive). Of course you will have to buy a maintenance contract on a yearly basis… but it does not include technical support. It will have to be bought with “incident packs” costing thousands of euros; because yes, paying for a product and a maintenance contract does not mean they will fix bugs, and you will have to pay for each of them.
-----------------------------------
Releases are uncommon, the last one being almost 6 years ago. But Allegro is a mature implementation packed with features not easily replicated such as AllegroCache, AllegroServe, libraries for multiple protocols and data formats, analysis tools, a concurrent garbage collector and even an OpenGL interface.
Allegro suffers the same issue as Lispworks: the enterprise-style pricing system is incredibly frustrating. The website advertises a hefty $599 starting price (which at least includes technical support), but there is no mention of what it contains. Interested developpers will have to contact Franz Inc. to get other prices. A quick Google search will reveal rumours of enterprise versions priced above 8000 dollars. No comment.
> It will have to be bought with “incident packs” costing thousands of euros; because yes, paying for a product and a maintenance contract does not mean they will fix bugs, and you will have to pay for each of them.
This is something the author made up on the spot. They will most definitely fix the bugs regardless if you have support contract.
This is something the author made up on the spot. They will most definitely fix the bugs regardless if you have support contract.
I did not "make it up on the spot", I simply read their website:
"Typically incidents are chargeable when they require work from us such as writing, compiling or testing patches, updating documentation, analysing or debugging your code, finding workarounds, providing technical advice or other significant effort.
In particular, please note that we may regard fixes for bugs in its own Lisp products, and for shortcomings in the documentation, as chargeable."
Source: http://www.lispworks.com/support/description.html#chargeable
Note how the list and following text clearly indicate that you can and will be charged for bugs in their own products.
"Typically incidents are chargeable when they require work from us such as writing, compiling or testing patches, updating documentation, analysing or debugging your code, finding workarounds, providing technical advice or other significant effort.
In particular, please note that we may regard fixes for bugs in its own Lisp products, and for shortcomings in the documentation, as chargeable."
Source: http://www.lispworks.com/support/description.html#chargeable
Note how the list and following text clearly indicate that you can and will be charged for bugs in their own products.
I've never worked for or with Franz, but I have worked support.
The cost of supporting a customer is relatively uncorrelated with any of the typical ways of charging for maintenance (e.g. per dev seat, company market-cap &c.). This leads to maintenance contracts that are very limited in scope. OTOH Companies really want a way to be guaranteed that you will support them. This often leads to some form of tiered support system. If you are not noisy, you can get away with a low tier. If you are noisy you'll be pushed to a higher tier. If you are rich and don't want to bother with that nonsense you just buy the top tier.
Also there's a difference between "Thanks for the bug report, it will be fixed in the next release" and "Here's a patch against <whatever version you are using> 24 hours after we fixed it in our development branch". The former is free pretty much everywhere (bug reports are like free QA). The latter is going to cost money.
The cost of supporting a customer is relatively uncorrelated with any of the typical ways of charging for maintenance (e.g. per dev seat, company market-cap &c.). This leads to maintenance contracts that are very limited in scope. OTOH Companies really want a way to be guaranteed that you will support them. This often leads to some form of tiered support system. If you are not noisy, you can get away with a low tier. If you are noisy you'll be pushed to a higher tier. If you are rich and don't want to bother with that nonsense you just buy the top tier.
Also there's a difference between "Thanks for the bug report, it will be fixed in the next release" and "Here's a patch against <whatever version you are using> 24 hours after we fixed it in our development branch". The former is free pretty much everywhere (bug reports are like free QA). The latter is going to cost money.
You wrote:
> Of course you will have to buy a maintenance contract on a yearly basis…
One does not have to buy a maintenance contract. It's entirely up to the customer if he/she does that.
> but it does not include technical support. It will have to be bought with “incident packs” costing thousands of euros; because yes, paying for a product and a maintenance contract does not mean they will fix bugs, and you will have to pay for each of them.
You don't have to pay for each of them. They clearly say that they "may" charge you money and they inform you if that is the case.
I have been reporting many things and for most fixes (for their bugs) I didn't have to pay anything additionally. For a lot of those I got patches immediately, sometimes they told me that it will be fixed in the next release, especially if it was in combination of a new feature. For example I once complained that the terminal listener/debugger wasn't supporting UTF-8. That feature got added in some release later. If I would have wanted to have it earlier, I surely would have had to pay for it.
> Of course you will have to buy a maintenance contract on a yearly basis…
One does not have to buy a maintenance contract. It's entirely up to the customer if he/she does that.
> but it does not include technical support. It will have to be bought with “incident packs” costing thousands of euros; because yes, paying for a product and a maintenance contract does not mean they will fix bugs, and you will have to pay for each of them.
You don't have to pay for each of them. They clearly say that they "may" charge you money and they inform you if that is the case.
I have been reporting many things and for most fixes (for their bugs) I didn't have to pay anything additionally. For a lot of those I got patches immediately, sometimes they told me that it will be fixed in the next release, especially if it was in combination of a new feature. For example I once complained that the terminal listener/debugger wasn't supporting UTF-8. That feature got added in some release later. If I would have wanted to have it earlier, I surely would have had to pay for it.
If you go as far as to the next sentence:
"…this policy reflects the reality that our engineers, quality assurance and support staff must spend time on providing expedited fixes outside of our normal product schedules."
You still get your bug fix for free with the next release/update unless you need it expedited.
"…this policy reflects the reality that our engineers, quality assurance and support staff must spend time on providing expedited fixes outside of our normal product schedules."
You still get your bug fix for free with the next release/update unless you need it expedited.
I don't think the licensing model is wrong but I think it is stupid, because it keeps new customers away.
There should be a way to charge for the produced value. If many users are using the produced programs, charge for that. For instance keep the basic development environment reasonably priced but charge for the ability to create executables.
My favorite IDE (Integrated Development Environment) at the moment is WebStorm by JetBrains. It is about $60 (?) for personal license with updates per year. I can develop JavaScript programs and run them on any JS platform. It is a nice product which truly adds to my productivity. And I can afford it. And I read that JetBrains is doing financially great.
There should be a way to charge for the produced value. If many users are using the produced programs, charge for that. For instance keep the basic development environment reasonably priced but charge for the ability to create executables.
My favorite IDE (Integrated Development Environment) at the moment is WebStorm by JetBrains. It is about $60 (?) for personal license with updates per year. I can develop JavaScript programs and run them on any JS platform. It is a nice product which truly adds to my productivity. And I can afford it. And I read that JetBrains is doing financially great.
Heh, if you thought this post had very strong comments about LispWorks and Franz, wait till you read my rant from last year: https://www.thejach.com/view/2022/1/thoughts_on_writings_on_...
It doesn't bother me as much as maybe it seems from the rant, I don't think about them hardly at all. But when I do, it's frustrating, because just about every other ecosystem out there is better. The rant highlights IntelliJ from the Java world as an alternative. Somehow, JetBrains is able to cater to individual developers and incredibly giant enterprises just fine. They care about their IDE and associated software. LispWorks and Franz do not, to the same degree. That's fine, it's their businesses, but it's disappointing when you want to see Lisp succeed and you have two great proprietary IDEs and implementations that are effectively untouchable for a huge portion of Lispers and would-be-Lispers.
It doesn't bother me as much as maybe it seems from the rant, I don't think about them hardly at all. But when I do, it's frustrating, because just about every other ecosystem out there is better. The rant highlights IntelliJ from the Java world as an alternative. Somehow, JetBrains is able to cater to individual developers and incredibly giant enterprises just fine. They care about their IDE and associated software. LispWorks and Franz do not, to the same degree. That's fine, it's their businesses, but it's disappointing when you want to see Lisp succeed and you have two great proprietary IDEs and implementations that are effectively untouchable for a huge portion of Lispers and would-be-Lispers.
Keep in mind that IntelliJ was developed for a market which is three or four orders of magnitude larger: devs, investments, etc.
That is an entirely different business model then.
Compare for example commercial Smalltalk (VisualWorks, ObjectStudio Enterprise, Gemstone, VA Smalltalk ...):
https://gemtalksystems.com/licensing/
https://www.instantiations.com/vast-platform/pricing/
That is an entirely different business model then.
Compare for example commercial Smalltalk (VisualWorks, ObjectStudio Enterprise, Gemstone, VA Smalltalk ...):
https://gemtalksystems.com/licensing/
https://www.instantiations.com/vast-platform/pricing/
Yeah, I totally agree.
I only use Lisp as a hobby so I stick to the free implementations, but if I made money with it I definitely wouldn't mind paying for LispWorks or Allegro.
An $8k license fee really isn't that much for enterprise software.
I only use Lisp as a hobby so I stick to the free implementations, but if I made money with it I definitely wouldn't mind paying for LispWorks or Allegro.
An $8k license fee really isn't that much for enterprise software.
Haha, if only it was $8k one-and-done, but if you're using it for more than just the IDE but also delivering binaries with it, hope you like paying runtime license fees depending on how your application is used: https://franz.com/products/licensing/commercial.lhtml Yes, there are times this makes sense to pay anyway (it's still not uncommon for game engines for example), but it's a lot to ask for outside of those times especially given the competition.
Also processor licenses, library costs for devs, etc. I recently stumbled over a Java domain specific development system (for insurance), where the dev seat did cost 100k euros.
Franz and LispWorks has different licensing models for companies. Franz is going the route of per usage/value and LispWorks has no extra cost for delivery (without the dev environment).
These licensing models are specific for tools in small niches. You'll see similar models for example for commercial Smalltalk systems.
Franz and LispWorks has different licensing models for companies. Franz is going the route of per usage/value and LispWorks has no extra cost for delivery (without the dev environment).
These licensing models are specific for tools in small niches. You'll see similar models for example for commercial Smalltalk systems.
He's right, though.
If I'm a somewhat polyglot developer ambivalent to any language out there, why would I pay those licensing costs when I can just go elsewhere instead?
That's what regular devs do, they don't even bother writing articles or commenting on HN :-)
If I'm a somewhat polyglot developer ambivalent to any language out there, why would I pay those licensing costs when I can just go elsewhere instead?
That's what regular devs do, they don't even bother writing articles or commenting on HN :-)
> 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 it's 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.
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 it's 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.
Is support costs for a language actually worth it? I've used Python professionally for about 10 years now and never hit an actual python runtime bug or needed to contact the PSF for support. A language vendor telling me about the faith I should have in their support sounds like I shouldn't have faith in the language.
I've never learned a lisp because every runtime and tooling set up seems 20 years behind modern. I'd be interested in learning with a good lisp variant, but not if I have to pay.
It's like how Adobe doesn't really do anything major to prevent piracy. And because of that hobbyists learn their tools and then companies have to pay for those tools because it's the dominant tool in that industry.
I've never learned a lisp because every runtime and tooling set up seems 20 years behind modern. I'd be interested in learning with a good lisp variant, but not if I have to pay.
It's like how Adobe doesn't really do anything major to prevent piracy. And because of that hobbyists learn their tools and then companies have to pay for those tools because it's the dominant tool in that industry.
Support at this level can also include help making something perform well. Or help understanding bugs in your code. That is, it isn't just a "prove we are at fault and we will fix it thing" which plagues a lot of moderate sized projects online.
For https, we can now use the newer Lisp Package Manager: https://gitlab.common-lisp.net/clpm/clpm (or use a mitm proxy: https://hiphish.github.io/blog/2022/03/19/securing-quicklisp... )
It looks interesting, however this is a bit scary:
> WARNING: This software is BETA quality. I use it as my daily driver, but it is still a little rough around the edges and it may accidentally eat your files.
And for QuickLisp, this is scary:
https://github.com/quicklisp/quicklisp-client/issues/167#iss...
> It would be good to do, but there's no straightforward path to do it. Implementations do not all provide HTTPS support, it's not straightforward to make it from scratch or use HTTPS libraries on all supported platforms.
The fact that the package manager (!!!) isn't able to ensure use of HTTPS libraries as its own dependency on all platforms is... super scary.
> WARNING: This software is BETA quality. I use it as my daily driver, but it is still a little rough around the edges and it may accidentally eat your files.
And for QuickLisp, this is scary:
https://github.com/quicklisp/quicklisp-client/issues/167#iss...
> It would be good to do, but there's no straightforward path to do it. Implementations do not all provide HTTPS support, it's not straightforward to make it from scratch or use HTTPS libraries on all supported platforms.
The fact that the package manager (!!!) isn't able to ensure use of HTTPS libraries as its own dependency on all platforms is... super scary.
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)
QL wants to do it portably, there are easy workarounds, but yeah…
(just saw https://github.com/rudolfochrist/ql-https)
Looking at the price of the “Hobbyist DV” version, it is not out of line with what people often spend on hobbies like photography, music, and cycling.
Or just on beer and/or wine.
Or books.
Not to say people don’t spend less on their hobbies, just that a license is a less than a Sony A7R3 or a used Les Paul.
Or just on beer and/or wine.
Or books.
Not to say people don’t spend less on their hobbies, just that a license is a less than a Sony A7R3 or a used Les Paul.
Yes, if a hobbyist absolutely wants to buy a Lispworks license, that should be possible for many people. But that isn't the only criterium. The question is: is anyone as happy to pay the price compared to spend the money on other things, like buying a camera or lens. There is some perception of value involved. For example I do spend a lot of money on my camera equipment and some people are suprised by it, though I spend way less on my car than they do. But on the other side, many people can't spend so much on any hobby or car.
On the other side there is SBCL. This is really a great Lisp implementation, in some ways clearly superior even, this limits the amount what at least I am willing to pay for some fancyness of the commercial edition. As far as I can see, I struggle to preceive a critical advantage for Lispworks. And the price is way above the impulse by territory.
On the other side there is SBCL. This is really a great Lisp implementation, in some ways clearly superior even, this limits the amount what at least I am willing to pay for some fancyness of the commercial edition. As far as I can see, I struggle to preceive a critical advantage for Lispworks. And the price is way above the impulse by territory.
> I struggle to preceive a critical advantage for Lispworks.
CAPI is the reason. If you want to develop a professional GUI application and you want to use Common Lisp, LW is pretty much the only option.
CAPI is the reason. If you want to develop a professional GUI application and you want to use Common Lisp, LW is pretty much the only option.
Depends on what exactly you mean by professional. There are Gtk and Qt bindings for SBCL (haven't tried them), and I have deployed GUI applications in an professional environment based on LTk. Yes, CAPI is certainly a strong point of Lispworks and in a commercial environment, the costs are not necessarily a problem, but I was making the statement in the context of the Hobbyist versions.
[deleted]
> Small standalone executables with a tree shaker
How small? Are they static and hassle-free like Go/Rust binaries?
> you can also make small standalone apps with SBCL
Same question. Also what's the downside? Slower run-time?
How small? Are they static and hassle-free like Go/Rust binaries?
> you can also make small standalone apps with SBCL
Same question. Also what's the downside? Slower run-time?
With SBCL, the bare-bones image would be ±100MB, with core compression (a single flag to set in the .asd file) I get apps at ±25MB. The startup time of the latter is ±0.30s, the bigger executable is faster. My app would be a web app, with the webserver, templates, and many libraries. This binary also contains the Lisp debugger and compiler, which is useful to interact with it when it's running.
In a latest version, SBCL switched to compression with zstd, which makes the compression process 4 times faster, decompression around 2 times, and it saves around +10% more space.
On reddit (link below), a user speaks about LispWorks binaries of ±9MB.
In a latest version, SBCL switched to compression with zstd, which makes the compression process 4 times faster, decompression around 2 times, and it saves around +10% more space.
On reddit (link below), a user speaks about LispWorks binaries of ±9MB.
Yes, compressed SBCL images load so fast that a few years ago I had a command line tool that I wrote using a compressed image. I think the load time for the tool was perhaps 100 milliseconds.
SBCL's save-lisp-and-die is my all time favourite function name. It's so unintentionally melodramatic :)
There's a weird spike in new accounts with what appear to be AI generated comments in this thread.
One problem I run into when learning Common Lisp is ASDF. For some reason I can't figure out how to use it properly. For example, when I open a system definition in a new REPL, what's the expected workflow? I'm using emacs and slime by the way. Maybe my environment is set up wrong. I also have to prefix the `defsystem`s with `asdf:`. When I look at examples in open source projects they just straight up use `uiop` functions and `defsystem` in their `.asd` files without the package.
One problem I run into when learning Common Lisp is ASDF. For some reason I can't figure out how to use it properly. For example, when I open a system definition in a new REPL, what's the expected workflow? I'm using emacs and slime by the way. Maybe my environment is set up wrong. I also have to prefix the `defsystem`s with `asdf:`. When I look at examples in open source projects they just straight up use `uiop` functions and `defsystem` in their `.asd` files without the package.
This should help: https://lispcookbook.github.io/cl-cookbook/getting-started.h...
The workflow is:
- open the .asd file,
- compile it so that your Lisp image knows about it: C-c C-k in Slime, or (asdf:load-asd "project.asd")
- you are ready to "quickload" it.
The link shows how you can tell ASDF to find your projects at startup, so than you can "quickload" it directly.
The workflow is:
- open the .asd file,
- compile it so that your Lisp image knows about it: C-c C-k in Slime, or (asdf:load-asd "project.asd")
- you are ready to "quickload" it.
The link shows how you can tell ASDF to find your projects at startup, so than you can "quickload" it directly.
Thanks, I honestly felt a bit gaslighted with the way no one was mentioning anything about these accounts.
>There's a weird spike in new accounts with what appear to be AI generated comments in this thread.
There's also a chatbot company on the front page posted by a new account. I kinda suspect they're related.
There's also a chatbot company on the front page posted by a new account. I kinda suspect they're related.
As a former "good old fashioned AI" researcher who used Lisp (LispWorks) between '89 and '95 this seems oddly appropriate!
What do you mean by "open [...] in a new REPL"?
You use ASDF:LOAD-SYSTEM to have ASDF load all the content of the system, making it available to you.
You use ASDF:LOAD-SYSTEM to have ASDF load all the content of the system, making it available to you.
I edited the comment to add some additional details.
Am I not supposed to load or compile the contents of an `.asd` file?
Am I not supposed to load or compile the contents of an `.asd` file?
No you do not have to. ASDF knows where to find your ASD files:
https://asdf.common-lisp.dev/asdf.html#Configuring-ASDF-to-f...
Personally I use the (:tree (:home "dev/lisp")) form.
https://asdf.common-lisp.dev/asdf.html#Configuring-ASDF-to-f...
Personally I use the (:tree (:home "dev/lisp")) form.
Just don't put a node_modules/ in there!
Thanks a lot for this actually. I just gave it a shot and it seems to have been the piece I've been missing.
You can load the contents of a .asd file (this can be useful when developing on versions other than what you want in your ASDF search path). It is unnecessary outside of that use case though.
You need to have ASDF itself loaded into your Lisp.
Yes one can also load system definitions, they are Lisp code. But usually it is expected that they are found automatically, when calling a system operation (load, compile, ...), when registered correctly.
Yes one can also load system definitions, they are Lisp code. But usually it is expected that they are found automatically, when calling a system operation (load, compile, ...), when registered correctly.
Just use quicklisp, it handles ASDF in a nice manner. Then jou just grow into using ASDF.
For a period much earlier in my career (think early 00's) I seriously desired to work in Common Lisp professionally. Through a series of life decisions and other opportunities, that never really happened. But I continued to work on Lisp projects on my own and use it for various things. I don't consider it a "superpower," and I don't think it makes me 10x more productive or anything like that. Most modern languages have stolen most of the thunder from Lisp (other than macros) so I would be hard-pressed to recommend it for greenfield development.
That said, I love working in it. I don't have any illusions that it will make a "comeback" or that I will ever make money writing it (I long ago switched to looking for job opportunities based on the problem domain rather than the toolset), but I continue to use it personally because it makes me happier than any other language.
That said, I love working in it. I don't have any illusions that it will make a "comeback" or that I will ever make money writing it (I long ago switched to looking for job opportunities based on the problem domain rather than the toolset), but I continue to use it personally because it makes me happier than any other language.
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
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
I 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.
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:
where you have access to HTTP clients, JSON parsers, CSV readers, DB drivers… and much more, out of the box.
It is not done, I am dogfooding it.
ciel --script myscript.lisp
./myscript
where you have access to HTTP clients, JSON parsers, CSV readers, DB drivers… and much more, out of the box.
It is not done, I am dogfooding it.
I’ve noticed many lisps and schemes are not set up to simply accept a single file name as the sole command line argument, which is something common to nearly every other platform. Seems like an easy target for reducing friction for newcomers.
Thanks for the feedback. I'll look into it, it's early enough to change.
(edit) forgot to mention we can simply call ./myscript with the right shebang line. Gets as succinct as one can.
(edit) forgot to mention we can simply call ./myscript with the right shebang line. Gets as succinct as one can.
Excellent. It's kinda like Janet, right (in terms of being a battery-included LISP)?
Yes, and kinda like Babashka for Clojure, in terms of fast starting scripting environment with one binary and useful built-in utilities.
You are very active in CL community, vindarel. Thanks!
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....
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....
What part of Common Lisp would you consider old cruft and what value would removing it bring to the language that would offset the value we have from having one of the most stable language definitions still in use? I can think of a few dusty parts of the language that are rarely used today but it's perfectly safe to ignore.
Lisp has a good all purpose library ecosystem, it's just informal rather than baked into the language, and I haven't had any significant issues with quicklisp since it came out however many years ago. Writing portable common lisp is not at all difficult and there is no problem like with say Scheme of one library needing a specific compiler. And libraries tend to have a long shelf-life too. How much of Python's standard library is old cruft with better alternative packages available now for example? Didn't they have to prune a bunch of stuff in the python2->3 transition? There is considerable risk in including standard libraries in a standard, and the risk is that those libraries will end up being outdated eventually. You want to add more potential for more old cruft to be in Lisp and then pruned again? Why? Just use quicklisp or one of it's alternatives that are cropping up.
Lisp is not Go, it's an agreement between many different parties about what lisp is, it's not a codebase under the defacto control of one organization, or even an informal group or "community". This is extremely valuable and recent events around Go show why, I am extremely glad that I never payed much attention to Go because honestly I cannot trust it's governance model, but a specification that hasn't been and won't be updated in decades I can trust completely, and if one implementation betrays that trust, I can always move to one of the many alternatives listed in the OP.
sidenote:
> I think every programmer that tries common lisp eventually comes to the same conclusion
if this refers to "Lisp needs more backing from the heavyweights", then OH GODS PLEASE NOOO! I want to write code that will run in a year without modification and won't have some corporation put spyware in my compiler while trying to convince me it's for my own good and have my IDE slurp my code to train some LLM to make it easier to pile even more pointless unmaintainable code upon the world. The "heavyweights" have shown themselves very poor stewards of the discipline of computing indeed.
Lisp has a good all purpose library ecosystem, it's just informal rather than baked into the language, and I haven't had any significant issues with quicklisp since it came out however many years ago. Writing portable common lisp is not at all difficult and there is no problem like with say Scheme of one library needing a specific compiler. And libraries tend to have a long shelf-life too. How much of Python's standard library is old cruft with better alternative packages available now for example? Didn't they have to prune a bunch of stuff in the python2->3 transition? There is considerable risk in including standard libraries in a standard, and the risk is that those libraries will end up being outdated eventually. You want to add more potential for more old cruft to be in Lisp and then pruned again? Why? Just use quicklisp or one of it's alternatives that are cropping up.
Lisp is not Go, it's an agreement between many different parties about what lisp is, it's not a codebase under the defacto control of one organization, or even an informal group or "community". This is extremely valuable and recent events around Go show why, I am extremely glad that I never payed much attention to Go because honestly I cannot trust it's governance model, but a specification that hasn't been and won't be updated in decades I can trust completely, and if one implementation betrays that trust, I can always move to one of the many alternatives listed in the OP.
sidenote:
> I think every programmer that tries common lisp eventually comes to the same conclusion
if this refers to "Lisp needs more backing from the heavyweights", then OH GODS PLEASE NOOO! I want to write code that will run in a year without modification and won't have some corporation put spyware in my compiler while trying to convince me it's for my own good and have my IDE slurp my code to train some LLM to make it easier to pile even more pointless unmaintainable code upon the world. The "heavyweights" have shown themselves very poor stewards of the discipline of computing indeed.
recent events around Go show why, I am extremely glad that I never payed much attention to Go...
What are you referring to? This is a literal question, not advocacy. I haven't been paying enough attention to know what you mean.
What are you referring to? This is a literal question, not advocacy. I haven't been paying enough attention to know what you mean.
Someone proposed adding telemetry to the compiler. People reacted to this as they usually do to telemetry. Google reacted to this as they usually do to criticism.
>Google reacted to this as they usually do to criticism.
Which is how? Not been folllowing them lately, for obvious reasons, so interested to know how they react these days.
Constructive non-egoistic non-spin engagement with the critics / stony silence with compressed lips / furious rebuttal / muttered denial and then look verbally down at the plebs while giving each other group-affirming backslaps in their posh pubs? With guilty looks in the mirror after the party and then downing some Valium to salve their conscience and get some sleep?
Which is how? Not been folllowing them lately, for obvious reasons, so interested to know how they react these days.
Constructive non-egoistic non-spin engagement with the critics / stony silence with compressed lips / furious rebuttal / muttered denial and then look verbally down at the plebs while giving each other group-affirming backslaps in their posh pubs? With guilty looks in the mirror after the party and then downing some Valium to salve their conscience and get some sleep?
Go telemetry will be opt-in. https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/qPpgO...
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.
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.
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.
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.
> and Quicklisp which is an unversioned mess
Quicklisp is the Common Lisp package manager from what I remember. It doesn't version its packages?
Quicklisp is the Common Lisp package manager from what I remember. It doesn't version its packages?
Not really, but there are ways around it: http://blog.quicklisp.org/2011/08/going-back-in-dist-time.ht...
I'm confused, is this about Quicklisp itself or about the packages it manages?
I.e. quicklisp 1.1 versus quicklisp 1.0 or libfoo 1.1 vs libfoo 1.0?
I.e. quicklisp 1.1 versus quicklisp 1.0 or libfoo 1.1 vs libfoo 1.0?
It's about the packages, a Quicklisp dist has a list of packages of specific versions (like libfoo 1.1, libbar 1.0, and libbaz 1.2) and you can switch to an older dist (which can have libfoo 1.0, no libbar, and libbaz 1.2).
Oh, so it's actually a carefully curated limited list? Because otherwise the combinatorial explosion would make this unmanageable super fast.
It may be worth mentioning that CLASP is one of the only languages/runtime systems that can interoperate with C++ code directly - say, to catch C++ exceptions, or pass around std::vector<T> and so on.
It's also quite remarkable that the project was started by a chemistry researcher.
It's also quite remarkable that the project was started by a chemistry researcher.
I used to use ECL a bit, and in hindsight I really wish it emitted C++ rather C, even if the generated code was only using C features.
I've used ECL in C++ mode, to interface with ClickHouse (which is a massive C++ codebase).
Are there any serious attempts at reworking the Common Lisp standard for more modern problems?
I know the space is active, but when I see the old bright yellow CLHS linked to from documentation sites, I just frown a bit. The Lisp community very nearly goes out of its way to be unhospitable to the younger generation of coders, and downright dismissive of modern techniques like containers and DevOps practices.
Not that the Scheme community is doing a radically better job, but at least the RnRS standard is marching forward at an acceptable pace.
A few years ago there was CL21, but it didn't really garner enough support from the community to really take form into anything worthwhile. I think we need a "Lisp for 20XX" council or something to gather up ideas and begin a reconstruction era for Lisp in this century.
I know the space is active, but when I see the old bright yellow CLHS linked to from documentation sites, I just frown a bit. The Lisp community very nearly goes out of its way to be unhospitable to the younger generation of coders, and downright dismissive of modern techniques like containers and DevOps practices.
Not that the Scheme community is doing a radically better job, but at least the RnRS standard is marching forward at an acceptable pace.
A few years ago there was CL21, but it didn't really garner enough support from the community to really take form into anything worthwhile. I think we need a "Lisp for 20XX" council or something to gather up ideas and begin a reconstruction era for Lisp in this century.
re CLHS, there is a new rendering, much more welcoming and practical! https://cl-community-spec.github.io/pages/index.html (a search box, syntax highlighting!!)
Indeed, that is VERY nice! That's exactly the type of upgrade I bet a lot of people can appreciate. The search is particularly crisp, feels instantaneous.
> downright dismissive of modern techniques like containers and DevOps practices
The last project in CL I made for other people to use (several years ago now) included a Dockerfile people seemed to appreciate it and nobody seemed to dismiss it.
> Are there any serious attempts at reworking the Common Lisp standard for more modern problems?
There are many extensions for more modern problems either as a library or in individualCL implementations. Where the extensions are highly overlapping, there is a library that unifies the interface (usually named "trivial-FOO"). There are exactly zero paying customers that need to wait for a feature to be in the standard for them to adopt that feature, so there is zero impetus to update the standard.
The last project in CL I made for other people to use (several years ago now) included a Dockerfile people seemed to appreciate it and nobody seemed to dismiss it.
> Are there any serious attempts at reworking the Common Lisp standard for more modern problems?
There are many extensions for more modern problems either as a library or in individualCL implementations. Where the extensions are highly overlapping, there is a library that unifies the interface (usually named "trivial-FOO"). There are exactly zero paying customers that need to wait for a feature to be in the standard for them to adopt that feature, so there is zero impetus to update the standard.
The GCL documentation (browsable with an info browser, like Emacs) contains a fairly complete reference of the standard.
This is just not true...
> I know the space is active, but when I see the old bright yellow CLHS linked to from documentation sites, I just frown a bit.
This is how documentation has been FOREVER. The newer documentation is not necessarily better. In fact, I find the "forced by the compiler" type docs that come from Rust et al to be infuriating at times. PyDoc is no better. I much prefer the terse documentation when I need to know something for sure rather than just copy-pasting examples out of docs.
> downright dismissive of modern techniques like containers and DevOps practices.
Citation needed? Lisp containerizes just fine. Unless you mean hand-holding-via-blog-post which yeah, I guess the community can be hostile. If you hang around the IRC people are often very helpful. The greybeards in the field are very experienced and very intelligent. To be crass, many of these "modern" developers you refer to need a LOT of handholding. CL doesn't provide this handholding. Honestly, it is no harder than getting actual work done in Haskell. You spend a lot of time in documentation and not a lot of people can help you. Of those people that can, your problem is not hard enough to interest them because they are VERY good. That being said I had no problem at all getting help from the community IRC and mailing lists.
As far as I can tell CL is fine for the 21st century. A more streamlined package system would be nice but quicklisp and ASDF aren't that complicated.
Frankly, I dont think you've spent any time working in CL at any real size. You could argue it doesnt scale well across large teams and that'd be fair. Your other criticisms though...don't make sense and don't align with my experience at all.
> I know the space is active, but when I see the old bright yellow CLHS linked to from documentation sites, I just frown a bit.
This is how documentation has been FOREVER. The newer documentation is not necessarily better. In fact, I find the "forced by the compiler" type docs that come from Rust et al to be infuriating at times. PyDoc is no better. I much prefer the terse documentation when I need to know something for sure rather than just copy-pasting examples out of docs.
> downright dismissive of modern techniques like containers and DevOps practices.
Citation needed? Lisp containerizes just fine. Unless you mean hand-holding-via-blog-post which yeah, I guess the community can be hostile. If you hang around the IRC people are often very helpful. The greybeards in the field are very experienced and very intelligent. To be crass, many of these "modern" developers you refer to need a LOT of handholding. CL doesn't provide this handholding. Honestly, it is no harder than getting actual work done in Haskell. You spend a lot of time in documentation and not a lot of people can help you. Of those people that can, your problem is not hard enough to interest them because they are VERY good. That being said I had no problem at all getting help from the community IRC and mailing lists.
As far as I can tell CL is fine for the 21st century. A more streamlined package system would be nice but quicklisp and ASDF aren't that complicated.
Frankly, I dont think you've spent any time working in CL at any real size. You could argue it doesnt scale well across large teams and that'd be fair. Your other criticisms though...don't make sense and don't align with my experience at all.
I had a great time writing common lisp for the better part of 2022, including doing about half of Advent of Code in it. It's such an awesome language and once you get an understanding of macros, it really does feel powerful.
Unfortunately, I hit a bit of a wall. I don't really have any personal projects to work with CL, and if I used CL (or any lisp/scheme dialect for that matter) at work I'd be in trouble.
Nice to have in the back pocket though, and I'm excited to reach for it in the future.
Unfortunately, I hit a bit of a wall. I don't really have any personal projects to work with CL, and if I used CL (or any lisp/scheme dialect for that matter) at work I'd be in trouble.
Nice to have in the back pocket though, and I'm excited to reach for it in the future.
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
The repository is now at https://gitlab.com/gnu-clisp/clisp
That is exactly the problem, there have been many commits to HEAD but no release for 12 years??? It isn’t dead, it is undead. Strange.
Not strange. The new generational GC does not work yet on Windows. libsigsegv esp. which signals out of memory conditions, which triggers a major GC.
Any windows assembler help there appreciated.
First time one of my articles lands on HN! Feel free to ask any follow up question.
I would like to learn Lisp but am easily confused with where to start. What implementation do I use? On a general level do I start with CL, schema, racket, etc (apologies I know this thread is about common lisp). It's all very confusing.
I'm like this with most things, like I want to learn Forth too but have that same problem. I learned vanilla JavaScript because I didn't know where to start with the 1000+ frameworks; and as a result am learning flutter/dart for cross platform apps.
Any advice would be much appreciated!
I'm like this with most things, like I want to learn Forth too but have that same problem. I learned vanilla JavaScript because I didn't know where to start with the 1000+ frameworks; and as a result am learning flutter/dart for cross platform apps.
Any advice would be much appreciated!
In my opinion, the simplest way is to start with Common Lisp, with SBCL and the Practical Common Lisp book by Peter Seibel.
Make sure you are comfortable with Emacs. It is possible to write Common Lisp without it, but Emacs and SLIME are so much better than anything else it feels like cheating.
Make sure you are comfortable with Emacs. It is possible to write Common Lisp without it, but Emacs and SLIME are so much better than anything else it feels like cheating.
>..simplest way
>..make sure you are comfortable with Emacs.
As an emacs user myself, I must say -- that's a high bar for trying to digest a new language.
>..make sure you are comfortable with Emacs.
As an emacs user myself, I must say -- that's a high bar for trying to digest a new language.
On the plus side there is a fair amount of conceptual overlap between Elisp and Common Lisp.
Learning Lisp really is more learning a complete development environment; a development philosophy even. Sure you can write Lisp as you would C, editing in a basic editor and then compiling and running the complete program in a a shell, but it’s really missing the point. While that reduces the learning curve significantly, it reduces the benefits even more.
Learning Lisp really is more learning a complete development environment; a development philosophy even. Sure you can write Lisp as you would C, editing in a basic editor and then compiling and running the complete program in a a shell, but it’s really missing the point. While that reduces the learning curve significantly, it reduces the benefits even more.
Agree, it's kind of a pain. There is ALIVE for vscode and VLIME for vim which are fine for just getting started.
and more: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
and more: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
I didn't feel like relearning Emacs when I started diving back into CL so I've been using VSCode with the Alive extension and once I got it fully up and running with Quicklisp etc my SBCL has run great.
I will say, using VLIME with vim is pretty nice as well. Once you get the keys memorized, you mostly match an Emacs/SLIME experience.
While personally I got started with Lisp through the OpenCourseWare Structure and Interpretation of Computer Programs videos (and working through the book using Guile), you could also try Common Lisp: A Gentle Introduction to Symbolic Computation (<https://www.cs.cmu.edu/~dst/LispBook/>). For Common Lisp I would recommend using SBCL, it is a very high quality and popular implementation.
Additional resources I would recommend:
For Common Lisp: CLiki, the Common Lisp wiki: <https://cliki.net/>
For Scheme: Either the R7RS or R6RS documentation depending on which implementation you choose (Chez and Loko use R6RS, Gauche uses R7RS, and Guile can use either): <https://standards.scheme.org/>
Additional resources I would recommend:
For Common Lisp: CLiki, the Common Lisp wiki: <https://cliki.net/>
For Scheme: Either the R7RS or R6RS documentation depending on which implementation you choose (Chez and Loko use R6RS, Gauche uses R7RS, and Guile can use either): <https://standards.scheme.org/>
Racket is a good education language and has lots of features with batteries included.
You can also use Clojure if you already know Java, or ClojureScript a fantastic compile-to-JS language.
You can also use Clojure if you already know Java, or ClojureScript a fantastic compile-to-JS language.
Common Lisp, specifically SBCL. Most popular choice (outside of Clojure and Emacs Lisp?). That's the easy answer. You'll encounter more libraries and online answers/resources which will help any growing pains.
Quicklisp is used for package management and quickproject is a great starting point to get you writing lisp asap.
Practical Common Lisp is a great introduction to the language.
https://www.quicklisp.org/beta/
https://xach.com/lisp/quickproject/
Quicklisp is used for package management and quickproject is a great starting point to get you writing lisp asap.
Practical Common Lisp is a great introduction to the language.
https://www.quicklisp.org/beta/
https://xach.com/lisp/quickproject/
If you are not looking at a specific project to get going, https://mitpress.mit.edu/9780262546379/the-little-learner/ was just released and is a very fun treatment of both lisp and machine learning.
I thought Little Learner assumed you already knew Lisp/scheme. You'd probably want to go through at LEAST Little Schemer from same author first to get the basics.
The first chapter goes over everything you'd need to know of scheme to get running. And it has its own choices in how they are using scheme. In particular, they curry all of the functions, it looks. My understanding is that this is on purpose for things they do later in the book.
Which shows I have not finished it, yet. :D I am finding it fun, already.
Which shows I have not finished it, yet. :D I am finding it fun, already.
Huh interesting. And I've never seen someone make curryable functions in lisp, though I'm not surprised you can lol.
For machine learning, it makes a lot of sense. Effectively, training is a function that returns a function, after all.
Oh yeah not disagreeing with that, just interesting because I'd never seen anyone rig up curried functions in scheme/lisp before as it obviously isn't default behavior in a traditional lisp. I'm assuming using some sort of wrapper function or macro.
The examples look like normal Scheme to me. There is nothing odd going on with custom macros.
They have broken some argument lists into currying, that's all.
These kinds of nested lambdas are not unheard of in Lisp and Scheme programming.
Lisps do not have automatic partial application. If you have a (f x y z) function, you cannot just call it (f 42) to partially apply it, to obtain a function which takes the y and z arguments. You have to do a clumsy thing with an explicit lambda like this: (lambda (y z) (f 42 y z)). There are macros for that, which can make it look like (op f 42) or what have you.
If you need partial application regularly over some functions, it may behave you to write the function in the curried style. Passing all the parameters becomes a bit less convenient:
They have broken some argument lists into currying, that's all.
(define line (lambda (x)
(lambda (w b)
(+ (* w x) b))))
These kinds of nested lambdas are not unheard of in Lisp and Scheme programming.
Lisps do not have automatic partial application. If you have a (f x y z) function, you cannot just call it (f 42) to partially apply it, to obtain a function which takes the y and z arguments. You have to do a clumsy thing with an explicit lambda like this: (lambda (y z) (f 42 y z)). There are macros for that, which can make it look like (op f 42) or what have you.
If you need partial application regularly over some functions, it may behave you to write the function in the curried style. Passing all the parameters becomes a bit less convenient:
((line 1) 2 3) ;; versus just (line 1 2 3)
(line 1) ;; versus (lambda (w b) (line 1 w b)).
Ah ha, yeah having a pre set one or two step currying setup is a lot easier sure. Just return a lambda that captures the value passed in from the first one.
https://mitpress.ublish.com/ebook/the-little-learner-a-strai... has the first two chapters. The forward plants the seed for the fact that it will be currying. When the chapters start, they don't use the term and just show functions returning functions. Immediately.
CLISP is excellent for learning Common Lisp; it has a readline-based REPL with editing and tab completion, so you don't need anything other than the CLISP installation.
The licensing server back end for the Tankan kanji learning application runs on CLISP.
The licensing server back end for the Tankan kanji learning application runs on CLISP.
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>).
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>).
So, say what's promising about NPT? The readme doesn't try to; neither does the first page of the docs.
The documentation (B1_Using) does explain that:
> npt was developed with the intention of embedding it in the C language.
Kind of like Guile, but Common Lisp rather than Scheme.
> npt was developed with the intention of embedding it in the C language.
Kind of like Guile, but Common Lisp rather than Scheme.
Thanks. Someone coming to this project page cold is not going to find that third-level sub-page unless they're motivated; the table of contents doesn't reveal that that's where they'll find a rationale. Hope this helps.
[deleted]
Compared to languages that have a single implementation, have multiple commercial and open source implementations in reasonable states of continuous development seems like a good place to be.
ECL license is LGPL-2.1-or-later (not LGPL2), the same applies to Clasp (which was forked from ECL).
n.b isn't this thread infested with bots? 4 or 5 nicks created 4 days ago with incomplete messages..
n.b isn't this thread infested with bots? 4 or 5 nicks created 4 days ago with incomplete messages..
Indeed, corrected. Thank you!
I'm not sure what is happening, there are multiple small posts which look like spam, with green nicknames.
Edit: green nicknames are from new accounts. On this page, all of them are spam. At some point it would make sense to just hide them all.
I'm not sure what is happening, there are multiple small posts which look like spam, with green nicknames.
Edit: green nicknames are from new accounts. On this page, all of them are spam. At some point it would make sense to just hide them all.
the correction is not really correct - you say lgpl-2.1 without the "or later version". It is sometimes abbreviated ls LGPL-2.1+, but SPDX identifier is preferable since it is semi-standard for abbreviating license names.
> The free “Personal Edition” limits the program size and the amount of time it can run, making it pretty much useless for anything but evaluation.
Also very good for education purposes.
Also very good for education purposes.
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]
---
[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]
Pro-tip for SBCL servers: Manually call the GC periodically. All non-FFI related crashes I've had on SBCL servers were allocation failures. They may have squashed all of those bugs now, but I still do this.
Franz releases updates continuously bringing in new features.
The update.sh handles these patches, and new items.
Sad to see Clozure CL abandoned, that was my main squeeze back in my lisp days (I was on Windows and SBCL wasn't cut out for it at the time). How's SBCL on Windows these days?
CCL is not "abandoned". I recently brushed the dust off an application that I last released in 2014. It uses CCL on Windows. I was pleased to see there is a recent new version from 2021. I upgraded to that and did some new work, making new releases.
Well, that's good, but the article made it sound like it was no more. Maybe it's just that it's feature-complete.
There are bugs which have not been fixed, maybe they are - who knows. For example on ARM processor it dies in multiprocessing.
Next: CCL comes originally from the Mac platform (the original Coral Lisp started on the early Mac, Apple even owned Macintosh Common Lisp for a few years, that code was used to create OpenMCL, aka Clozure CL) and there is still no Apple Silicon port and there is no real progress to get there.
Next: CCL comes originally from the Mac platform (the original Coral Lisp started on the early Mac, Apple even owned Macintosh Common Lisp for a few years, that code was used to create OpenMCL, aka Clozure CL) and there is still no Apple Silicon port and there is no real progress to get there.
Common Lisp implementations in 2023:
- SBCL
Everything else is de-facto dead or in a proprietary silo.
- SBCL
Everything else is de-facto dead or in a proprietary silo.
What about GCL?
"NEW! (20230113) GCL 2.6.14 is released"
I tried to use it when writing my article. It could not even load my initialization file because it is not standard compliant (it does not support the :VERBOSE argument of COMPILE-FILE).
The fact that they use GCC under the hood is interesting though, I'd be curious to see how fast it can get. But standard compliance comes first.
The fact that they use GCC under the hood is interesting though, I'd be curious to see how fast it can get. But standard compliance comes first.
Never heard of anyone using it. AIUI not standards-compliant. LGPL for a Common Lisp impl. is not something I want to touch with a ten foot pole.
What about Clasp or ABCL?
ABCL got a new release just today! https://abcl-dev.blogspot.com/2023/02/abcl-191-never-use-dot...
Lispworks starts with an affordable hobbyist edition. There is also a hobbyist development edition.
Sorry, I have to disagree. €500-600 for just the ability to use the IDE but not being able to create an executable doesn't sound very appealing to me. And that all limited to "non-commercial" use. And per platform. So you can't just switch between different OSes.
if sbcl significantly faster than racket why and when do practitioners use racket?
What do you mean by that? A lot of people use racket, a lot of people use SBCL, which is indeed significantly faster. They are actually completely different software for different purposes and very different strengths.
what are strengths of sbcl over racket?
what are strengths of racket over sbcl?
if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl?
what purposes does racket uniquely serve not served by sbcl?
what are strengths of racket over sbcl?
if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl?
what purposes does racket uniquely serve not served by sbcl?
They're completely different languages. Common Lisp isn't Racket. Racket is "a Lisp", but it's not Common Lisp (or even Scheme, which it's much more closely based on). You're writing something like:
If Java raw speed > TypeScript raw speed wouldn't most expert curly-bracers by default choose Java?
Differences include all the differences different languages have: features (hygienic macros, continuations, conditions, CLOS, ...), libraries (standard or otherwise), tooling...
If Java raw speed > TypeScript raw speed wouldn't most expert curly-bracers by default choose Java?
Differences include all the differences different languages have: features (hygienic macros, continuations, conditions, CLOS, ...), libraries (standard or otherwise), tooling...
> what are strengths of sbcl over racket?
SBCL is a Common Lisp implementation, racket implements variants of Scheme. SBCL is natively compiled, creates standalone executables.
> what are strengths of racket over sbcl?
It implements various scheme dialects, the ability to integrate different languages in one image is unique. It offers an integrated enviroment with a lot of libraries included, that is why it is popular in academia.
> if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl?
First of all, they implement different programming languages, that means they are not competing directly with each other and are very different beasts as discribed above. Racket seems to be very popular in academia, while SBCL is more used for practical software development. At least that is the impression I have.
> what purposes does racket uniquely serve not served by sbcl?
I think I have answered that above.
SBCL is a Common Lisp implementation, racket implements variants of Scheme. SBCL is natively compiled, creates standalone executables.
> what are strengths of racket over sbcl?
It implements various scheme dialects, the ability to integrate different languages in one image is unique. It offers an integrated enviroment with a lot of libraries included, that is why it is popular in academia.
> if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl?
First of all, they implement different programming languages, that means they are not competing directly with each other and are very different beasts as discribed above. Racket seems to be very popular in academia, while SBCL is more used for practical software development. At least that is the impression I have.
> what purposes does racket uniquely serve not served by sbcl?
I think I have answered that above.
> the ability to integrate different languages in one image is unique
Somehow.
It should be possible to load a C, Prolog and Python implementations into one sbcl image.
The Symbolics Lisp Machine emulator I use comes with C, Pascal, Fortran, several Common Lisp variants, Lisp Machine Lisp in one image.
Kalman Reti once gave a demo how to debug mixed Lisp and C code in a REPL on such a Lisp Machine: https://www.youtube.com/watch?v=o4-YnLpLgtk
Somehow.
It should be possible to load a C, Prolog and Python implementations into one sbcl image.
The Symbolics Lisp Machine emulator I use comes with C, Pascal, Fortran, several Common Lisp variants, Lisp Machine Lisp in one image.
Kalman Reti once gave a demo how to debug mixed Lisp and C code in a REPL on such a Lisp Machine: https://www.youtube.com/watch?v=o4-YnLpLgtk
why is there a need to integrate many different languages in one image? [ in racket/sbcl]
In Racket the 'language orientation' is a part of the philosophy and the language & implementation & infrastructure is especially and prominently developed to support that. This can for example be used in education.
In SBCL it's just the case, that generally the Lisp language familiy is used for developing embedded languages: domain specific and general.
In SBCL it's just the case, that generally the Lisp language familiy is used for developing embedded languages: domain specific and general.
is racket not compiled to a native binary like sbcl,c,cpp,haskell?
[deleted]
Amumulava5(1)
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.