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

91–100 of 243 posts

Re: Common Lisp Implementations in 2023

#93

Post by vindarel »

147 wrote: post #35

There's a weird spike in new accounts with what appear to be AI generated comments in this thread. One problem I run into when learning Common Lisp is ASDF. For some reason I can't figure out how to use it properly. For example, when I open a system definition in a new REPL, what's the expected workflow? I'm using emacs and slime by the way. Maybe my environment is set up wrong. I also have to prefix the `defsystem`s…

This should help: https://lispcookbook.github.io/cl-cookbook/getting-started.h...

The workflow is:

- open the .asd file,

- compile it so that your Lisp image knows about it: C-c C-k in Slime, or (asdf:load-asd "project.asd")

- you are ready to "quickload" it.

The link shows how you can tell ASDF to find your projects at startup, so than you can "quickload" it directly.

Re: Common Lisp Implementations in 2023

#95

Post by vindarel »

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…

re CLHS, there is a new rendering, much more welcoming and practical! https://cl-community-spec.github.io/pages/index.html (a search box, syntax highlighting!!)

Re: Common Lisp Implementations in 2023

#98

Post by vindarel »

This LispWorks comment on reddit is very interesting:

---

[cite]

As a Lispworks user, yes it is super pricey, but it does make sense for certain people. Arguably, Lispworks provides features that aren't available in any other programming language, Lisp or not.

* Support for just about every platform I can imagine. Yes it's expensive, but if I want to port to a new platform I can pay Lispworks, and get it over with. It'll mostly work without too much changes. It works on Android, iOS, Windows, Linux, Mac, and some really obscure systems.

* Application delivery with tree shaking. May be there are other languages that do this, but I haven't worked with something like this before in my career. (Maybe proguard for Java, but that's very rudimentary compared to LW's delivery). The tool I work on delivers a binary that people need to download during the CI jobs for every run, so having it be 100MB is way too big. After compression, my LW delivered binaries come to around 9MB.

* You mention support being expensive. Actually, for simple support questions LW does a pretty good job of responding back to you. I've asked tonnes of questions over the years, and have not paid for a separate support contract apart from the yearly maintenance contract. I suspect they like people asking questions, because then they fix those bugs and it becomes even more rock solid.

* The documentation is glorious. And in the off-chance that I need to know something that's not documented, I just mail them and they'll respond usually by the next working day.

* Very stable Java support (although the API could be better), let's me use the entire Java ecosystem of libraries when I need it.

* The platform itself is rock-solid. Now SBCL is fantastic, but when I ran my servers on SBCL, I would have a crash every now and then. With LW, I can have my server running weeks (current uptime is a month) with reloading code multiple times a day, and everything is still super stable.

There's more, but I think the rest is more negotiable. For instance, the FLI is a lot more polished than using CFFI, which makes a huge difference in productivity when writing native code. Or the fact that its remote-debugger facility can be used as a very stable protocol to programmatically control a remote LW process. I don't use the IDE btw, so I'm not even considering that. I don't use CAPI either, but I mean to someday.

2023, Arnold @tdrhq of Screenshotbot (https://github.com/screenshotbot/screenshotbot-oss) on reddit: https://www.reddit.com/r/Common_Lisp/comments/11979q4/common...

[/cite]

Re: Common Lisp Implementations in 2023

#100

Post by oblio »

kgwgk wrote: post #12
galdor wrote: post #9

Earlier quoted context omitted.

The commercial aspect is not a problem in my opinion (but again english is not my main language so I might have conveyed the wrong tone). The issue is the pricing model which may work for established company ready to invest money from the start, but is simply out of touch with independant developers and small companies exploring the possibility of using Common Lisp. Open sourcing Lispworks and selling support contrac…

> The issue is the pricing model which may work for established company ready to invest money from the start, but ... That's a much more nuanced way to put it - compared to "The professional and enterprise licenses do not really make sense for anyone".

> That's a much more nuanced way to put it - compared to "The professional and enterprise licenses do not really make sense for anyone".

Where does he say that?

Post reply on HN