Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Lisp Implementations in 2023

n16f.net

Post reply on HN
Print view View original

191–200 of 243 posts

Re: Common Lisp Implementations in 2023

#191

Post by Jach »

mark_l_watson wrote: post #4

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

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.

Re: Common Lisp Implementations in 2023

#193

Post by blep_ »

SiVal wrote: post #169
lispegistus wrote: post #90

Earlier quoted context omitted.

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

recent events around Go show why, I am extremely glad that I never payed much attention to Go... What are you referring to? This is a literal question, not advocacy. I haven't been paying enough attention to know what you mean.

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.

Re: Common Lisp Implementations in 2023

#194

Post by Jach »

jlarocco wrote: post #154
mark_l_watson wrote: post #4

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

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.

Re: Common Lisp Implementations in 2023

#195

Post by hajile »

kgwgk wrote: post #147
_ph_ wrote: post #146

Earlier quoted context omitted.

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

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

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.

Re: Common Lisp Implementations in 2023

#196

Post by hajile »

lispm wrote: post #118
galdor wrote: post #9

Earlier quoted context omitted.

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

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

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

Re: Common Lisp Implementations in 2023

#197

Post by kgwgk »

_ph_ wrote: post #171
kgwgk wrote: post #147

Earlier quoted context omitted.

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

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.

Re: Common Lisp Implementations in 2023

#198

Post by aidenn0 »

galdor wrote: post #177
varjag wrote: post #162

Earlier quoted context omitted.

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

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

Re: Common Lisp Implementations in 2023

#199

Post by hajile »

lispm wrote: post #165
varjag wrote: post #160

Earlier quoted context omitted.

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.

Re: Common Lisp Implementations in 2023

#200

Post by aidenn0 »

l_theanine wrote: post #68

Are there any serious attempts at reworking the Common Lisp standard for more modern problems? I know the space is active, but when I see the old bright yellow CLHS linked to from documentation sites, I just frown a bit. The Lisp community very nearly goes out of its way to be unhospitable to the younger generation of coders, and downright dismissive of modern techniques like containers and DevOps practices. Not that…

> downright dismissive of modern techniques like containers and DevOps practices

The last project in CL I made for other people to use (several years ago now) included a Dockerfile people seemed to appreciate it and nobody seemed to dismiss it.

> Are there any serious attempts at reworking the Common Lisp standard for more modern problems?

There are many extensions for more modern problems either as a library or in individualCL implementations. Where the extensions are highly overlapping, there is a library that unifies the interface (usually named "trivial-FOO"). There are exactly zero paying customers that need to wait for a feature to be in the standard for them to adopt that feature, so there is zero impetus to update the standard.

Post reply on HN