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

211–220 of 243 posts

Re: Common Lisp Implementations in 2023

#211

Post by runevault »

taeric wrote: post #156
runevault wrote: post #149

Earlier quoted context omitted.

I thought Little Learner assumed you already knew Lisp/scheme. You'd probably want to go through at LEAST Little Schemer from same author first to get the basics.

The first chapter goes over everything you'd need to know of scheme to get running. And it has its own choices in how they are using scheme. In particular, they curry all of the functions, it looks. My understanding is that this is on purpose for things they do later in the book. Which shows I have not finished it, yet. :D I am finding it fun, already.

Huh interesting. And I've never seen someone make curryable functions in lisp, though I'm not surprised you can lol.

Re: Common Lisp Implementations in 2023

#212

Post by abudabi123 »

oblio wrote: post #176
varjag wrote: post #160

Earlier quoted context omitted.

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.

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.

Re: Common Lisp Implementations in 2023

#213

Post by taeric »

runevault wrote: post #211
taeric wrote: post #156

Earlier quoted context omitted.

The first chapter goes over everything you'd need to know of scheme to get running. And it has its own choices in how they are using scheme. In particular, they curry all of the functions, it looks. My understanding is that this is on purpose for things they do later in the book. Which shows I have not finished it, yet. :D I am finding it fun, already.

Huh interesting. And I've never seen someone make curryable functions in lisp, though I'm not surprised you can lol.

For machine learning, it makes a lot of sense. Effectively, training is a function that returns a function, after all.

Re: Common Lisp Implementations in 2023

#214

Post by rurban »

cellularmitosis wrote: post #123
mkh wrote: post #72

One should note that while it is true that the last CLISP release was a long time ago and there is not a lot of development going on right now, it's not dead. Bruno Haible just commited last week. The repository is now at https://gitlab.com/gnu-clisp/clisp

That is exactly the problem, there have been many commits to HEAD but no release for 12 years??? It isn’t dead, it is undead. Strange.

Not strange. The new generational GC does not work yet on Windows. libsigsegv esp. which signals out of memory conditions, which triggers a major GC. Any windows assembler help there appreciated.

Re: Common Lisp Implementations in 2023

#215

Post by lispm »

noloblo wrote: post #205
lispm wrote: post #183

Earlier quoted context omitted.

> the ability to integrate different languages in one image is unique Somehow. It should be possible to load a C, Prolog and Python implementations into one sbcl image. The Symbolics Lisp Machine emulator I use comes with C, Pascal, Fortran, several Common Lisp variants, Lisp Machine Lisp in one image. Kalman Reti once gave a demo how to debug mixed Lisp and C code in a REPL on such a Lisp Machine: https://www.youtub…

why is there a need to integrate many different languages in one image? [ in racket/sbcl]

In Racket the 'language orientation' is a part of the philosophy and the language & implementation & infrastructure is especially and prominently developed to support that. This can for example be used in education.

In SBCL it's just the case, that generally the Lisp language familiy is used for developing embedded languages: domain specific and general.

Re: Common Lisp Implementations in 2023

#216

Post by lispm »

louis771 wrote: post #206
kgwgk wrote: post #185

Earlier quoted context omitted.

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

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.

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

Re: Common Lisp Implementations in 2023

#217

Post by lispm »

Jach wrote: post #191
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…

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/

Re: Common Lisp Implementations in 2023

#218

Post by lispm »

Jach wrote: post #194
jlarocco wrote: post #154

Earlier quoted context omitted.

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

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.

Re: Common Lisp Implementations in 2023

#219

Post by lispm »

hajile wrote: post #199
lispm wrote: post #165

Earlier quoted context omitted.

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.

Re: Common Lisp Implementations in 2023

#220

Post by varjag »

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…

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.

Post reply on HN