Live data from Hacker News

Common Lisp Implementations in 2023

n16f.net

221–230 of 243 posts

Re: Common Lisp Implementations in 2023

#221
post #176

Earlier quoted context omitted.

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

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

Re: Common Lisp Implementations in 2023

#222
post #129

Earlier quoted context omitted.

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?

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.

Re: Common Lisp Implementations in 2023

#223

Earlier quoted context omitted.

> That's what regular devs do, they don't even bother writing articles or commenting on HN :-) I'll take the bait, and roll up several of my comments into one. First, the support contract costs from the commercial vendors can make sense. It's one of the most expensive parts of software. We joke about fixing relatives' printers, but it's not false. Support costs introduce a counter-balance. Second, a message to everyo…

For https, we can now use the newer Lisp Package Manager: https://gitlab.common-lisp.net/clpm/clpm (or use a mitm proxy: https://hiphish.github.io/blog/2022/03/19/securing-quicklisp... )

It looks interesting, however this is a bit scary:

> WARNING: This software is BETA quality. I use it as my daily driver, but it is still a little rough around the edges and it may accidentally eat your files.

And for QuickLisp, this is scary:

https://github.com/quicklisp/quicklisp-client/issues/167#iss...

> It would be good to do, but there's no straightforward path to do it. Implementations do not all provide HTTPS support, it's not straightforward to make it from scratch or use HTTPS libraries on all supported platforms.

The fact that the package manager (!!!) isn't able to ensure use of HTTPS libraries as its own dependency on all platforms is... super scary.

Re: Common Lisp Implementations in 2023

#224
post #176
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.

Oh wow so offering a paid tool when free ones are available is not the offense after all, as we are finding out!

Re: Common Lisp Implementations in 2023

#225

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…

SBCL's save-lisp-and-die is my all time favourite function name. It's so unintentionally melodramatic :)

Re: Common Lisp Implementations in 2023

#226
post #187
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…

> I would like to be able to really evaluate the product before spending a significant amount of money on it, but with the limits of the personal edition, it immediately quit on the first attempt of starting my back-then tiny hobby project. Usually one contacts the vendor and asks for a time-limited full version of the product for evaluation. > On the other side, with SBCL I have a really strong Lisp implementation.…

> Usually one contacts the vendor and asks for a time-limited full version of the product for evaluation.

Yes, if there is already the deep desire to acquire Lispworks, this would be the way to go. But I never arrived at that point. It is also a bit odd to have a personal edition which supposedly is usable for evaluation, but it really isn't. As I said before, I might not be their target customer, but on the other side, my experiences might be more common, so I am presenting them here.

Re: Common Lisp Implementations in 2023

#227
post #195
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.

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

Okay but why would you do that in a large company, you don't need every single developer triple booting. You've got 150 people and 25 of are RHEL, 25 are macos and 100 are windows.

and also the 5k license is a one time fee. over the course of say 5 years its

    5100 [first two years] 
  + (1125 * 3) [next three]
  = 1695 a year [asymptotically approaching 1125]
if you want to target both mobile runtimes

  + (5 * 2000)[the mobile runtimes *are* annual although as with desktop you wouldn't actually need everyone to have both, or either] 
  = 3695 a year [asymptotically approaching 3125]
That's before any volume discount (I dunno lispworks but as a point of comparison Sicstus goes from 2550/seat to 1510/seat for just 20 seats) and unlike say Dyalog, distribution is free so only the devs need licenses not any one else in the org.

I'm not saying it's cheap mind you but even at 3700 a year * 100 devs, if your bumping up against sharp edges in SBCL: 370000 only gets you 1-2 devs to work on those edges.

At the size of a Google adding developers works out to be cheaper than licensing software for all the existing devs. But a lot of companies don't have high 3-4 digits worth of devs such that they can break off a team to work on support technology instead of core internal business apps or products.

Re: Common Lisp Implementations in 2023

#228
post #196
post #118

Earlier quoted context omitted.

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

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.

Re: Common Lisp Implementations in 2023

#229
post #195

Earlier quoted context omitted.

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

Okay but why would you do that in a large company, you don't need every single developer triple booting. You've got 150 people and 25 of are RHEL, 25 are macos and 100 are windows. and also the 5k license is a one time fee. over the course of say 5 years its 5100 [first two years] + (1125 * 3) [next three] = 1695 a year [asymptotically approaching 1125] if you want to target both mobile runtimes + (5 * 2000)[the mobi…

No matter how you slice it, Java enterprise would only cost $180/yr which is almost 10x better than your best estimate

Let's say you have 25 devs on a 5-year project. 5 of them are mobile focused, 5 are windows focused, 5 are mac/Linux focused, and 10 are focused on the cloud/server side of the project.

We'll make the (probably bad) assumption that you don't need enterprise licenses for the desktop app portion. We'll further assume that windows devs use only windows and backend devs use only Linux while mobile and mac/Linux devs use both the systems they work on.

    First 2 years (because we get a discount on year 1 maintenance)

    $17,000 for 5 64-bit windows professional
    $51,000 for 10 64-bit linux enterprise
    $37,000 for 5 64-bit mac professional and 5 pairs of mobile for 2 years
    $34,000 for 5 64-bit mac professional and 5 64-bit linux professional

    $139,000 for first 2 years

    Next 3 years (maintenance and mobile annual fees)

    $11,250 for 5 64-bit windows professional
    $33,750 for 10 64-bit linux enterprise
    $41,250 for 5 64-bit mac professional and 5 pairs of mobile for 3 years
    $22,500 for 5 64-bit mac professional and 5 64-bit linux professional

    $108,750 for next 3 years

    $247,750 for project.
Now let's do Java at $180/yr/dev. We'll even throw in IntelliJ Ultimate for 5 years.

    First 2 years
    $9,000  - 25 devs for 2 years of enterprise Java
    $14,975 - 25 devs for year 1 of IntelliJ Ultimate ($599/yr/dev)
    $11,975 - 25 devs for year 2 of IntelliJ Ultimate ($479/yr/dev)

    $35,950 for first 2 years


    next 3 years
    
    $13,500 - 25 devs for 3 years of enterprise Java
    $8,975  - 25 devs for year 3-5 of IntelliJ Ultimate ($359/yr/dev)

    $22,475 for next 3 years

    $58,425 for project
Drop the non-enterprise devs from support reduces Java cost from $22,500 to just $9,000. Dropping subsequent years of the new IntelliJ would cut that cost from $35,925 down to $14,975 reducing our total expenses to just $23,975.

I'd calculate these for LispWorks, but they don't even provide that option at all. If you forego maintenance entirely, you're still stuck with $115,000 the first year and $40,000 for the remaining 4 years of subscription to mobile meaning your absolute minimum here is $155,000 and exceeds even the top-end budget for a Java project. If you turn out to need the Enterprise version for the non-backend devs and want maintenance, that cost goes up to $267,875.

The difference in money is enough to provide every team member with a new $4,000 laptop year 2 and again year 4 OR to increase their yearly bonus by $1600.

Re: Common Lisp Implementations in 2023

#230
post #213

Earlier quoted context omitted.

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.

Oh yeah not disagreeing with that, just interesting because I'd never seen anyone rig up curried functions in scheme/lisp before as it obviously isn't default behavior in a traditional lisp. I'm assuming using some sort of wrapper function or macro.
Post reply on HN