Live data from Hacker News

Common Lisp Implementations in 2023

n16f.net

161–170 of 243 posts

Re: Common Lisp Implementations in 2023

#161
post #129
post #124

Earlier quoted context omitted.

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.

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

Re: Common Lisp Implementations in 2023

#162

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…

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

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

Re: Common Lisp Implementations in 2023

#163

Sad to see Clozure CL abandoned, that was my main squeeze back in my lisp days (I was on Windows and SBCL wasn't cut out for it at the time). How's SBCL on Windows these days?

CCL is not "abandoned". I recently brushed the dust off an application that I last released in 2014. It uses CCL on Windows. I was pleased to see there is a recent new version from 2021. I upgraded to that and did some new work, making new releases.

Well, that's good, but the article made it sound like it was no more. Maybe it's just that it's feature-complete.

Re: Common Lisp Implementations in 2023

#164
post #155

Earlier quoted context omitted.

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.

Re: Common Lisp Implementations in 2023

#165
post #160
post #102

Earlier quoted context omitted.

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

Re: Common Lisp Implementations in 2023

#166

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…

The GCL documentation (browsable with an info browser, like Emacs) contains a fairly complete reference of the standard.

Re: Common Lisp Implementations in 2023

#167

Earlier quoted context omitted.

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

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

Re: Common Lisp Implementations in 2023

#168

Earlier quoted context omitted.

CCL is not "abandoned". I recently brushed the dust off an application that I last released in 2014. It uses CCL on Windows. I was pleased to see there is a recent new version from 2021. I upgraded to that and did some new work, making new releases.

Well, that's good, but the article made it sound like it was no more. Maybe it's just that it's feature-complete.

There are bugs which have not been fixed, maybe they are - who knows. For example on ARM processor it dies in multiprocessing.

Next: CCL comes originally from the Mac platform (the original Coral Lisp started on the early Mac, Apple even owned Macintosh Common Lisp for a few years, that code was used to create OpenMCL, aka Clozure CL) and there is still no Apple Silicon port and there is no real progress to get there.

Re: Common Lisp Implementations in 2023

#169
post #6

Earlier quoted context omitted.

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

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.

Post reply on HN