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

111–120 of 243 posts

Re: Common Lisp Implementations in 2023

#111

Post by mikedelago »

serf wrote: post #83
galdor wrote: post #18

Earlier quoted context omitted.

In my opinion, the simplest way is to start with Common Lisp, with SBCL and the Practical Common Lisp book by Peter Seibel. Make sure you are comfortable with Emacs. It is possible to write Common Lisp without it, but Emacs and SLIME are so much better than anything else it feels like cheating.

>..simplest way >..make sure you are comfortable with Emacs. As an emacs user myself, I must say -- that's a high bar for trying to digest a new language.

Agree, it's kind of a pain. There is ALIVE for vscode and VLIME for vim which are fine for just getting started.

and more: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...

Re: Common Lisp Implementations in 2023

#113

Post by [deleted] »

oblio wrote: post #100
kgwgk wrote: post #12

Earlier quoted context omitted.

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

[deleted]

Re: Common Lisp Implementations in 2023

#114

Post by User23 »

serf wrote: post #83
galdor wrote: post #18

Earlier quoted context omitted.

In my opinion, the simplest way is to start with Common Lisp, with SBCL and the Practical Common Lisp book by Peter Seibel. Make sure you are comfortable with Emacs. It is possible to write Common Lisp without it, but Emacs and SLIME are so much better than anything else it feels like cheating.

>..simplest way >..make sure you are comfortable with Emacs. As an emacs user myself, I must say -- that's a high bar for trying to digest a new language.

On the plus side there is a fair amount of conceptual overlap between Elisp and Common Lisp.

Learning Lisp really is more learning a complete development environment; a development philosophy even. Sure you can write Lisp as you would C, editing in a basic editor and then compiling and running the complete program in a a shell, but it’s really missing the point. While that reduces the learning curve significantly, it reduces the benefits even more.

Re: Common Lisp Implementations in 2023

#115

Post by lispm »

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…

You need to have ASDF itself loaded into your Lisp.

Yes one can also load system definitions, they are Lisp code. But usually it is expected that they are found automatically, when calling a system operation (load, compile, ...), when registered correctly.

Re: Common Lisp Implementations in 2023

#116

Post by mikedelago »

I had a great time writing common lisp for the better part of 2022, including doing about half of Advent of Code in it. It's such an awesome language and once you get an understanding of macros, it really does feel powerful.

Unfortunately, I hit a bit of a wall. I don't really have any personal projects to work with CL, and if I used CL (or any lisp/scheme dialect for that matter) at work I'd be in trouble.

Nice to have in the back pocket though, and I'm excited to reach for it in the future.

Re: Common Lisp Implementations in 2023

#117

Post by ducktective »

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…

> Small standalone executables with a tree shaker

How small? Are they static and hassle-free like Go/Rust binaries?

> you can also make small standalone apps with SBCL

Same question. Also what's the downside? Slower run-time?

Re: Common Lisp Implementations in 2023

#118

Post by lispm »

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…

> 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 different license models / pricing, have gone. Left are Franz and LispWorks. Both are 30+ years in business.

Re: Common Lisp Implementations in 2023

#119

Post by tmtvl »

oblio wrote: post #105
u89012 wrote: post #3

I just spent months working on a large piece of software and could say without a doubt, Lisp is awesome! But I also want to say that most implementations are hashing out a spec written decades ago and not trying to improve what's obviously lacking -- a full modern standard library! Trying to piece together functionality from here and there (and Quicklisp which is an unversioned mess) will only take you so far and in…

> and Quicklisp which is an unversioned mess Quicklisp is the Common Lisp package manager from what I remember. It doesn't version its packages?

Not really, but there are ways around it: http://blog.quicklisp.org/2011/08/going-back-in-dist-time.ht...

Re: Common Lisp Implementations in 2023

#120

Post by oblio »

kgwgk wrote: post #108
oblio wrote: post #100

Earlier quoted context omitted.

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

https://www.n16f.net/blog/common-lisp-implementations-in-202...

I've read it and if you're referring to this:

> I do not have anything personal against commercial software, and I strongly support developers being paid for their work. But this kind of licensing makes Lispworks irrelevant to everyone but those already using their proprietary libraries.

is he wrong?

Go ask 100 random devs working for various companies. My money's on 99% on them avoiding those licensing terms in favor of probably anything else.

Post reply on HN