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>).
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.
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.
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.
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.
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.
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?
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.
I quite agree, so I'm making a meta-library to have useful libraries available out of the box: https://github.com/ciel-lang/CIEL/ It's CL, batteries included. You can use it as a library, as a core CL image (loads up faster), and as a binary to have a REPL, and to run scripts:
ciel --script myscript.lisp
(edit) or just
./myscript
with a #!/usr/bin/env ciel shebang.
where you have access to HTTP clients, JSON parsers, CSV readers, DB drivers… and much more, out of the box.
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.
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).
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.
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.
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.
> 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 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.
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.
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.
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.
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.
> 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.
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.
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
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
> 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.
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.
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".
> 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.
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."
> 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.
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.
"…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.
> 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.
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.
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.
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.
> 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…
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.
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.
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.
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.
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.
> 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.
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.
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
5100 [first two years]
+ (1125 * 3) [next three]
= 1695 a year [asymptotically approaching 1125]
if you want to target both mobile runtimes
+ (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]
That's before any volume discount (I dunno lispworks but as a point of comparison Sicstus goes from 2550/seat to 1510/seat for just 20 seats) and unlike say Dyalog, distribution is free so only the devs need licenses not any one else in the org.
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.
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.
Now let's do Java at $180/yr/dev. We'll even throw in IntelliJ Ultimate for 5 years.
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
Drop the non-enterprise devs from support reduces Java cost from $22,500 to just $9,000. Dropping subsequent years of the new IntelliJ would cut that cost from $35,925 down to $14,975 reducing our total expenses to just $23,975.
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.
> 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.
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 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.
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.
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.
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.
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].
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.
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.
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.
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.
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.
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.
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.
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/>
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.
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.
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.
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.
(define line (lambda (x)
(lambda (w b)
(+ (* w x) b))))
Firstly, it's not full currying; the w and b parameters are not separated from each other into different lambdas.
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)
but the partial application you want is a lot less verbose:
(line 1) ;; versus (lambda (w b) (line 1 w b)).
So basically it looks like the authors may be after low-verbosity partial
application without macro assistance.
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.
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.
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.
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.
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.
242 comments
[ 0.20 ms ] story [ 340 ms ] threadOne 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.
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.
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?
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.
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.
https://github.com/fukamachi/mito
https://lisp-stat.dev/
https://github.com/marcoheisig/Petalisp
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
if you want to target both mobile runtimes That's before any volume discount (I dunno lispworks but as a point of comparison Sicstus goes from 2550/seat to 1510/seat for just 20 seats) and unlike say Dyalog, distribution is free so only the devs need licenses not any one else in the org.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.
Now let's do Java at $180/yr/dev. We'll even throw in IntelliJ Ultimate for 5 years. Drop the non-enterprise devs from support reduces Java cost from $22,500 to just $9,000. Dropping subsequent years of the new IntelliJ would cut that cost from $35,925 down to $14,975 reducing our total expenses to just $23,975.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 ...):
https://gemtalksystems.com/licensing/
https://www.instantiations.com/vast-platform/pricing/
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
- 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.
How annoying.
edit: TropicalDelight, SimplySweet4, WonderWeirdo0, WickedlyCool and SoulmateTravels as well.
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.
https://www.quicklisp.org/beta/
https://xach.com/lisp/quickproject/
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.
Firstly, it's not full currying; the w and b parameters are not separated from each other into different lambdas.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:
but the partial application you want is a lot less verbose: So basically it looks like the authors may be after low-verbosity partial application without macro assistance.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.
It's also quite remarkable that the project was started by a chemistry researcher.
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.