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

61–70 of 243 posts

Re: Common Lisp Implementations in 2023

#62

Post by anta40 »

galdor wrote: post #9
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…

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…

I assume you have some specific needs that couldn't be handled by open source Lisps like SBCL, CCL, etc?

Re: Common Lisp Implementations in 2023

#67

Post by 147 »

galdor wrote: post #44
147 wrote: post #38

Earlier quoted context omitted.

I edited the comment to add some additional details. Am I not supposed to load or compile the contents of an `.asd` file?

No you do not have to. ASDF knows where to find your ASD files: https://asdf.common-lisp.dev/asdf.html#Configuring-ASDF-to-f... Personally I use the (:tree (:home "dev/lisp")) form.

Thanks a lot for this actually. I just gave it a shot and it seems to have been the piece I've been missing.

Re: Common Lisp Implementations in 2023

#68

Post by l_theanine »

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 the Scheme community is doing a radically better job, but at least the RnRS standard is marching forward at an acceptable pace.

A few years ago there was CL21, but it didn't really garner enough support from the community to really take form into anything worthwhile. I think we need a "Lisp for 20XX" council or something to gather up ideas and begin a reconstruction era for Lisp in this century.

Re: Common Lisp Implementations in 2023

#69

Post by abecedarius »

tmtvl wrote: post #2

No love for NPT ( https://github.com/nptcl/npt >)? Well, I get it, it is very, very new. One note about ABCL is that it doesn't support TCO, which the Common Lisp spec doesn't mandate. For people who want a Lisp on the JVM and really want tail calls, I would recommend checking out Kawa ( https://www.gnu.org/software/kawa/index.html >).

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