Hacker News Reader

Comment by mark_l_watson | Hacker News Reader

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.

View on HN

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.

> The HobbyistDV edition is in my eyes the first really usable one. It is already over €1400

Less than 1000 if you can live with 32 bits but I wonder if someone goes for that option nowadays.

> and that is for a single OS, a single CPU architecture.

The MacOS version supports both Apple Silicon and Intel.

> Less than 1000 if you can live with 32 bits but I wonder if someone goes for that option nowadays.

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.

The macOS version is not available as 32-bit edition so it is twice as expensive as the cheapest 32-bit version.

Also, you are not allowed to give a saved image away / cannot run it without the licensed LispWorks installation.

> Also, you are not allowed to give a saved image away / cannot run it without the licensed LispWorks installation.

I think you're not talking now about the HobbyistDV version mentioned in the parent comment, are you?

macOS itself is no longer available as 32-bit edition, but as 64bit versions on two processor platforms.

By the way, this is not completely correct:

> You are limited to run your programs inside the development environment, this limits its applicability a lot. You can't write a simple command line utility this way, just to name one example.

You can save and run a console-only image which doesn't start the graphical IDE.

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.

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.

> The issue is the pricing model which may work for established company ready to invest money from the start, but ...

That's a much more nuanced way to put it - compared to "The professional and enterprise licenses do not really make sense for anyone".

> That's a much more nuanced way to put it - compared to "The professional and enterprise licenses do not really make sense for anyone".

Where does he say that?

https://www.n16f.net/blog/common-lisp-implementations-in-202...

I've read it and if you're referring to this:

> I do not have anything personal against commercial software, and I strongly support developers being paid for their work. But this kind of licensing makes Lispworks irrelevant to everyone but those already using their proprietary libraries.

is he wrong?

Go ask 100 random devs working for various companies. My money's on 99% on them avoiding those licensing terms in favor of probably anything else.

In case it was not clear I was referring to this literal quote from the linked article:

    "The professional and enterprise licenses do not really make sense for anyone"

which does indeed convey a more negative tone than this literal quote from the comment that I replied to:

   "the pricing model which may work for established company ready to invest money from the start"

Ah, I was looking at the wrong quote.

However, I think techies are too nitpicky.

In casual use "everyone" or "anyone" do not mean: "I literally asked everyone on the surface of the planet".

And he's not wrong.

Unless you have a preexisting commitment to Lisp and ecosystem or your needs are so specific that you need this precise piece of software, you won't use it.

I think it's a prior that anyone considering the choice of a Common Lisp implementation for production has a preexisting commitment to Lisp.

What's an example of something that is used for production without preexisting commitment?

Someone who's a language polyglot choosing a programming language for a new system, without external constraints (legal requirements, client mandating tech, closed developer stack, etc).

They have the luxury of choosing the most mature ecosystem.

That kind of person, and there are a fair amount of these around, will look at this kind of enterprise/niche pricing and go that: that's crazy, I'll just use Java/C#/Go/Rust/whatever else.

On the page, commenting about LispWorks.

I assume you have some specific needs that couldn't be handled by open source Lisps like SBCL, CCL, etc?

No, his needs are probably better handled by Java or .NET or Go or whatever. And that's how Lisp atrophies. The complaint is a valid one.

Enterprise Java licenses are charged per developer seat, just saying.

Hasn't this just recently changed to per employee?

https://www.infoworld.com/article/3686611/oracle-per-employe...

$15/mo or $180/yr.

Lispworks for that same platform support would cost about $20,000 per dev the first year then a few thousand every year after.

You could buy 100 years of enterprise Java support for Jay one year of Lispworks.

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.

Plus, what even is success? Adoption after 1 year? After 10 years (https://www.joelonsoftware.com/2001/07/21/good-software-take...)?

What we can measure instead is the number of developers, jobs, projects started based on public announcements, etc.

And for that it's no contest. Java/C# >> Go >>>>>>> Lisp.

The reasons are less important than the facts on the ground.

Especially since Common Lisp was first proposed in 1982 (41 years ago), so a really long time ago. However, its rivals aren't spring chickens either, these days. Java was launched in 1995, 27 years ago (early Java devs are close to retirement, already), C# was launched in 2000, 23 years ago, heck, even Go was launched in 2019, that's 13 years ago.

So we're in a reality were we have multiple competing ecosystems that are big and developed and have been around for decades. So the mainstream ones will be major for a long time.

Oh wow so offering a paid tool when free ones are available is not the offense after all, as we are finding out!

I am also curious about this, what specific needs are better served by CL than Clojure or any Scheme / Racket?

Starting a CL project in 2023 seems risky to me given that most libraries are stagnant. I would love to be proven wrong.

Could it be that most of the critical libraries are stable? Can you give an example of a necessary library that is stagnant?

CLSQL, most graphics toolkits or lisp-stat.

for ORM people tend to use Mito. i think lisp-stat library is actually being developed. however one numerical cl library that doesnt get enough mention and is being constantly developed is petalisp for HPC

https://github.com/fukamachi/mito

https://lisp-stat.dev/

https://github.com/marcoheisig/Petalisp

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.

They know their locked-in customers, but they also know they don’t get many additional customers at those prices either.

The market is small anyway. Better have customers at all. Mabe the customers are not "locked in", but happy that there are remaining offerings.

See the pricing for commercial Smalltalk. Same thing.

The linux lispworks runs fine for me on Freebsd with linux_compat.

You wrote of LispWorks: “ The professional and enterprise licenses do not really make sense for anyone”

Perhaps a question I would ask is what are you trying to convey with this statement? It appears to be quite subjective.

You quote him saying "The professional and enterprise licenses do not really make sense for anyone"

your quote is the definition of "out of context", you left out his colon leading to the rest of his sentence where he explains what he means, i.e. what you are asking.

"The professional and enterprise licenses do not really make sense for anyone: you will have to buy separate licenses for every..." ...now, I'm not quoting the rest of it because while it's easy to engage with a substantive argument, you didn't say anything.

Still your move.

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".

*pedant.

;-)

Ouch. And thus, all my sophistry is discredited. ;-)

> I always like seeing Common Lisp links, but personally I was a bit put off by the very strong anti-commercial comments about LispWorks and Franz.

What? I found it informative - clear and to the point about what frustrations you can expect with the licenses.

I mean, FCOL, he even made the effort to search google for the cost of the licenses because Franz hides them.

What exactly in the following texts do you describe as "strong anti-commercial comments"?

------------------------------------------------------

> Moving to proprietary implementations; Lispworks has been around for more than 30 years and the company producing it still release new versions on a regular basis.

> While Lispworks supports most features you would expect from a commercial product (native compiler, multithreading, FFI, GUI library, various graphical tools, a Prolog implementation…), it is hampered by its licensing system.

> The free “Personal Edition” limits the program size and the amount of time it can run, making it pretty much useless for anything but evaluation. The professional and enterprise licenses do not really make sense for anyone: you will have to buy separate licenses for every single platform at more than a thousand euros per license (with the enterprise version being 2-3 times more expensive). Of course you will have to buy a maintenance contract on a yearly basis… but it does not include technical support. It will have to be bought with “incident packs” costing thousands of euros; because yes, paying for a product and a maintenance contract does not mean they will fix bugs, and you will have to pay for each of them.

-----------------------------------

Releases are uncommon, the last one being almost 6 years ago. But Allegro is a mature implementation packed with features not easily replicated such as AllegroCache, AllegroServe, libraries for multiple protocols and data formats, analysis tools, a concurrent garbage collector and even an OpenGL interface.

Allegro suffers the same issue as Lispworks: the enterprise-style pricing system is incredibly frustrating. The website advertises a hefty $599 starting price (which at least includes technical support), but there is no mention of what it contains. Interested developpers will have to contact Franz Inc. to get other prices. A quick Google search will reveal rumours of enterprise versions priced above 8000 dollars. No comment.

> 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."

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.

You wrote:

> Of course you will have to buy a maintenance contract on a yearly basis…

One does not have to buy a maintenance contract. It's entirely up to the customer if he/she does that.

> but it does not include technical support. It will have to be bought with “incident packs” costing thousands of euros; because yes, paying for a product and a maintenance contract does not mean they will fix bugs, and you will have to pay for each of them.

You don't have to pay for each of them. They clearly say that they "may" charge you money and they inform you if that is the case.

I have been reporting many things and for most fixes (for their bugs) I didn't have to pay anything additionally. For a lot of those I got patches immediately, sometimes they told me that it will be fixed in the next release, especially if it was in combination of a new feature. For example I once complained that the terminal listener/debugger wasn't supporting UTF-8. That feature got added in some release later. If I would have wanted to have it earlier, I surely would have had to pay for it.

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.

If you go as far as to the next sentence:

"…this policy reflects the reality that our engineers, quality assurance and support staff must spend time on providing expedited fixes outside of our normal product schedules."

You still get your bug fix for free with the next release/update unless you need it expedited.

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.

Heh, if you thought this post had very strong comments about LispWorks and Franz, wait till you read my rant from last year: https://www.thejach.com/view/2022/1/thoughts_on_writings_on_...

It doesn't bother me as much as maybe it seems from the rant, I don't think about them hardly at all. But when I do, it's frustrating, because just about every other ecosystem out there is better. The rant highlights IntelliJ from the Java world as an alternative. Somehow, JetBrains is able to cater to individual developers and incredibly giant enterprises just fine. They care about their IDE and associated software. LispWorks and Franz do not, to the same degree. That's fine, it's their businesses, but it's disappointing when you want to see Lisp succeed and you have two great proprietary IDEs and implementations that are effectively untouchable for a huge portion of Lispers and would-be-Lispers.

Keep in mind that IntelliJ was developed for a market which is three or four orders of magnitude larger: devs, investments, etc.

That is an entirely different business model then.

Compare for example commercial Smalltalk (VisualWorks, ObjectStudio Enterprise, Gemstone, VA Smalltalk ...):

https://gemtalksystems.com/licensing/

https://www.instantiations.com/vast-platform/pricing/

Yeah, I totally agree.

I only use Lisp as a hobby so I stick to the free implementations, but if I made money with it I definitely wouldn't mind paying for LispWorks or Allegro.

An $8k license fee really isn't that much for enterprise software.

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.

He's right, though.

If I'm a somewhat polyglot developer ambivalent to any language out there, why would I pay those licensing costs when I can just go elsewhere instead?

That's what regular devs do, they don't even bother writing articles or commenting on HN :-)

> 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.

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.

For https, we can now use the newer Lisp Package Manager: https://gitlab.common-lisp.net/clpm/clpm (or use a mitm proxy: https://hiphish.github.io/blog/2022/03/19/securing-quicklisp... )

It looks interesting, however this is a bit scary:

> WARNING: This software is BETA quality. I use it as my daily driver, but it is still a little rough around the edges and it may accidentally eat your files.

And for QuickLisp, this is scary:

https://github.com/quicklisp/quicklisp-client/issues/167#iss...

> It would be good to do, but there's no straightforward path to do it. Implementations do not all provide HTTPS support, it's not straightforward to make it from scratch or use HTTPS libraries on all supported platforms.

The fact that the package manager (!!!) isn't able to ensure use of HTTPS libraries as its own dependency on all platforms is... super scary.

LPM's warning is not surprising. It's common for libraries (dare I say open-source ones?), even if they work well. It's part of the stability game, once they are marked 1.0, they are stable. LPM works well (as reported by others).

QL wants to do it portably, there are easy workarounds, but yeah…

(just saw https://github.com/rudolfochrist/ql-https)

Looking at the price of the “Hobbyist DV” version, it is not out of line with what people often spend on hobbies like photography, music, and cycling.

Or just on beer and/or wine.

Or books.

Not to say people don’t spend less on their hobbies, just that a license is a less than a Sony A7R3 or a used Les Paul.

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.

> I struggle to preceive a critical advantage for Lispworks.

CAPI is the reason. If you want to develop a professional GUI application and you want to use Common Lisp, LW is pretty much the only option.

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.

> Small standalone executables with a tree shaker

How small? Are they static and hassle-free like Go/Rust binaries?

> you can also make small standalone apps with SBCL

Same question. Also what's the downside? Slower run-time?

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.

SBCL's save-lisp-and-die is my all time favourite function name. It's so unintentionally melodramatic :)

Reply on news.ycombinator.com