Hacker News Reader

Comment by galdor | Hacker News Reader

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.

View on HN

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

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

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

Reply on news.ycombinator.com