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

171–180 of 243 posts

Re: Common Lisp Implementations in 2023

#171

Post by _ph_ »

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.

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.

Re: Common Lisp Implementations in 2023

#172

Post by _ph_ »

noloblo wrote: post #170

if sbcl significantly faster than racket why and when do practitioners use racket?

What do you mean by that? A lot of people use racket, a lot of people use SBCL, which is indeed significantly faster. They are actually completely different software for different purposes and very different strengths.

Re: Common Lisp Implementations in 2023

#173

Post by _ph_ »

brudgers wrote: post #150
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…

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.

Re: Common Lisp Implementations in 2023

#174

Post by abecedarius »

tmtvl wrote: post #128
abecedarius wrote: post #69

Earlier quoted context omitted.

So, say what's promising about NPT? The readme doesn't try to; neither does the first page of the docs.

The documentation (B1_Using) does explain that: > npt was developed with the intention of embedding it in the C language. Kind of like Guile, but Common Lisp rather than Scheme.

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.

Re: Common Lisp Implementations in 2023

#175

Post by oblio »

tmtvl wrote: post #148
oblio wrote: post #139

Earlier quoted context omitted.

I'm confused, is this about Quicklisp itself or about the packages it manages? I.e. quicklisp 1.1 versus quicklisp 1.0 or libfoo 1.1 vs libfoo 1.0?

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

Oh, so it's actually a carefully curated limited list? Because otherwise the combinatorial explosion would make this unmanageable super fast.

Re: Common Lisp Implementations in 2023

#176

Post by oblio »

varjag wrote: post #160
oblio wrote: 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.

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.

Re: Common Lisp Implementations in 2023

#177

Post by galdor »

varjag wrote: post #162
lelanthran wrote: post #33

Earlier quoted context omitted.

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

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.

Re: Common Lisp Implementations in 2023

#178

Post by blue039 »

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…

This is just not true...

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

This is how documentation has been FOREVER. The newer documentation is not necessarily better. In fact, I find the "forced by the compiler" type docs that come from Rust et al to be infuriating at times. PyDoc is no better. I much prefer the terse documentation when I need to know something for sure rather than just copy-pasting examples out of docs.

> downright dismissive of modern techniques like containers and DevOps practices.

Citation needed? Lisp containerizes just fine. Unless you mean hand-holding-via-blog-post which yeah, I guess the community can be hostile. If you hang around the IRC people are often very helpful. The greybeards in the field are very experienced and very intelligent. To be crass, many of these "modern" developers you refer to need a LOT of handholding. CL doesn't provide this handholding. Honestly, it is no harder than getting actual work done in Haskell. You spend a lot of time in documentation and not a lot of people can help you. Of those people that can, your problem is not hard enough to interest them because they are VERY good. That being said I had no problem at all getting help from the community IRC and mailing lists.

As far as I can tell CL is fine for the 21st century. A more streamlined package system would be nice but quicklisp and ASDF aren't that complicated.

Frankly, I dont think you've spent any time working in CL at any real size. You could argue it doesnt scale well across large teams and that'd be fair. Your other criticisms though...don't make sense and don't align with my experience at all.

Re: Common Lisp Implementations in 2023

#179

Post by lispm »

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…

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.

Re: Common Lisp Implementations in 2023

#180

Post by noloblo »

_ph_ wrote: post #172
noloblo wrote: post #170

if sbcl significantly faster than racket why and when do practitioners use racket?

What do you mean by that? A lot of people use racket, a lot of people use SBCL, which is indeed significantly faster. They are actually completely different software for different purposes and very different strengths.

what are strengths of sbcl over racket?

what are strengths of racket over sbcl?

if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl?

what purposes does racket uniquely serve not served by sbcl?

Post reply on HN