Common Lisp Implementations in 2023
n16f.net
n16f.net
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.
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.
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?
> 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.
"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"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.
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.
https://www.infoworld.com/article/3686611/oracle-per-employe...
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.
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.
The main JDK distros are big and stable enough to make this strategy viable in an enterprise environment.
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.
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.
Starting a CL project in 2023 seems risky to me given that most libraries are stagnant. I would love to be proven wrong.
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
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.
See the pricing for commercial Smalltalk. Same thing.
Perhaps a question I would ask is what are you trying to convey with this statement? It appears to be quite subjective.
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.
;-)
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.
This is something the author made up on the spot. They will most definitely fix the bugs regardless if you have support contract.
"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.
> 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.
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.
"…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.
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.
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 :-)
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'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.
> 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.
QL wants to do it portably, there are easy workarounds, but yeah…
(just saw https://github.com/rudolfochrist/ql-https)
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?
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.
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.
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.
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.
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.
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?
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
That is an entirely different business model then.
Compare for example commercial Smalltalk (VisualWorks, ObjectStudio Enterprise, Gemstone, VA Smalltalk ...):
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.
You use ASDF:LOAD-SYSTEM to have ASDF load all the content of the system, making it available to you.
Am I not supposed to load or compile the contents of an `.asd` file?
https://asdf.common-lisp.dev/asdf.html#Configuring-ASDF-to-f...
Personally I use the (:tree (:home "dev/lisp")) form.
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.
There's also a chatbot company on the front page posted by a new account. I kinda suspect they're related.
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.
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.
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...
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.
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....
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.
What are you referring to? This is a literal question, not advocacy. I haven't been paying enough attention to know what you mean.
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?
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.
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.
(edit) forgot to mention we can simply call ./myscript with the right shebang line. Gets as succinct as one can.
Quicklisp is the Common Lisp package manager from what I remember. It doesn't version its packages?
I.e. quicklisp 1.1 versus quicklisp 1.0 or libfoo 1.1 vs libfoo 1.0?
It's also quite remarkable that the project was started by a chemistry researcher.
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.
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.
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.
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.
The repository is now at https://gitlab.com/gnu-clisp/clisp
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!
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.
As an emacs user myself, I must say -- that's a high bar for trying to digest a new language.
and more: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
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.
You can also use Clojure if you already know Java, or ClojureScript a fantastic compile-to-JS language.
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.
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/>
Which shows I have not finished it, yet. :D I am finding it fun, already.
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)).
The licensing server back end for the Tankan kanji learning application runs on CLISP.
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>).
> npt was developed with the intention of embedding it in the C language.
Kind of like Guile, but Common Lisp rather than Scheme.
n.b isn't this thread infested with bots? 4 or 5 nicks created 4 days ago with incomplete messages..
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.
Also very good for education purposes.
---
[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]
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.
- SBCL
Everything else is de-facto dead or in a proprietary silo.
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.
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?
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.
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
In SBCL it's just the case, that generally the Lisp language familiy is used for developing embedded languages: domain specific and general.
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...