Hacker News Reader

Comment by jgerrish | Hacker News Reader

> 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 everyone looking into or using QuickLisp, it uses http instead of https: https://github.com/quicklisp/quicklisp-client/issues/167

You can patch your version to fix this. I'd also recommend adding firewall rules to deny in case your patches roll back. And any other mitigation. Or stricter policies, such as not using it, if it makes sense for your organization.

And the AI bots? I hope there aren't people herding them who don't want to, that's how you get unloving brats and a crappy world.

View on HN

Is support costs for a language actually worth it? I've used Python professionally for about 10 years now and never hit an actual python runtime bug or needed to contact the PSF for support. A language vendor telling me about the faith I should have in their support sounds like I shouldn't have faith in the language.

I've never learned a lisp because every runtime and tooling set up seems 20 years behind modern. I'd be interested in learning with a good lisp variant, but not if I have to pay.

It's like how Adobe doesn't really do anything major to prevent piracy. And because of that hobbyists learn their tools and then companies have to pay for those tools because it's the dominant tool in that industry.

Support at this level can also include help making something perform well. Or help understanding bugs in your code. That is, it isn't just a "prove we are at fault and we will fix it thing" which plagues a lot of moderate sized projects online.

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.

LPM's warning is not surprising. It's common for libraries (dare I say open-source ones?), even if they work well. It's part of the stability game, once they are marked 1.0, they are stable. LPM works well (as reported by others).

QL wants to do it portably, there are easy workarounds, but yeah…

(just saw https://github.com/rudolfochrist/ql-https)

Reply on news.ycombinator.com