Sad to see Clozure CL abandoned, that was my main squeeze back in my lisp days (I was on Windows and SBCL wasn't cut out for it at the time). How's SBCL on Windows these days?
Common Lisp Implementations in 2023
151–160 of 243 posts
Re: Common Lisp Implementations in 2023
#152CLISP is excellent for learning Common Lisp; it has a readline-based REPL with editing and tab completion, so you don't need anything other than the CLISP installation.
The licensing server back end for the Tankan kanji learning application runs on CLISP.
Re: Common Lisp Implementations in 2023
#153Sad to see Clozure CL abandoned, that was my main squeeze back in my lisp days (I was on Windows and SBCL wasn't cut out for it at the time). How's SBCL on Windows these days?
CCL is not "abandoned". I recently brushed the dust off an application that I last released in 2014. It uses CCL on Windows. I was pleased to see there is a recent new version from 2021. I upgraded to that and did some new work, making new releases.
Re: Common Lisp Implementations in 2023
#154I 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…
Yeah, I totally agree.
I only use Lisp as a hobby so I stick to the free implementations, but if I made money with it I definitely wouldn't mind paying for LispWorks or Allegro.
An $8k license fee really isn't that much for enterprise software.
Re: Common Lisp Implementations in 2023
#155Earlier 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…
I assume you have some specific needs that couldn't be handled by open source Lisps like SBCL, CCL, etc?
I am also curious about this, what specific needs are better served by CL than Clojure or any Scheme / Racket?
Starting a CL project in 2023 seems risky to me given that most libraries are stagnant. I would love to be proven wrong.
Re: Common Lisp Implementations in 2023
#156Earlier quoted context omitted.
If you are not looking at a specific project to get going, https://mitpress.mit.edu/9780262546379/the-little-learner/ was just released and is a very fun treatment of both lisp and machine learning.
I thought Little Learner assumed you already knew Lisp/scheme. You'd probably want to go through at LEAST Little Schemer from same author first to get the basics.
The first chapter goes over everything you'd need to know of scheme to get running. And it has its own choices in how they are using scheme. In particular, they curry all of the functions, it looks. My understanding is that this is on purpose for things they do later in the book.
Which shows I have not finished it, yet. :D I am finding it fun, already.
Re: Common Lisp Implementations in 2023
#157Earlier quoted context omitted.
I assume you have some specific needs that couldn't be handled by open source Lisps like SBCL, CCL, etc?
I am also curious about this, what specific needs are better served by CL than Clojure or any Scheme / Racket? Starting a CL project in 2023 seems risky to me given that most libraries are stagnant. I would love to be proven wrong.
Could it be that most of the critical libraries are stable? Can you give an example of a necessary library that is stagnant?
Re: Common Lisp Implementations in 2023
#158Earlier quoted context omitted.
In case it was not clear I was referring to this literal quote from the linked article: "The professional and enterprise licenses do not really make sense for anyone" which does indeed convey a more negative tone than this literal quote from the comment that I replied to: "the pricing model which may work for established company ready to invest money from the start"
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.
I think it's a prior that anyone considering the choice of a Common Lisp implementation for production has a preexisting commitment to Lisp.
Re: Common Lisp Implementations in 2023
#159Earlier 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…
You wrote of LispWorks: “ The professional and enterprise licenses do not really make sense for anyone” Perhaps a question I would ask is what are you trying to convey with this statement? It appears to be quite subjective.
You quote him saying "The professional and enterprise licenses do not really make sense for anyone"
your quote is the definition of "out of context", you left out his colon leading to the rest of his sentence where he explains what he means, i.e. what you are asking.
"The professional and enterprise licenses do not really make sense for anyone: you will have to buy separate licenses for every..." ...now, I'm not quoting the rest of it because while it's easy to engage with a substantive argument, you didn't say anything.
Still your move.
Re: Common Lisp Implementations in 2023
#160Earlier quoted context omitted.
I assume you have some specific needs that couldn't be handled by open source Lisps like SBCL, CCL, etc?
No, his needs are probably better handled by Java or .NET or Go or whatever. And that's how Lisp atrophies. The complaint is a valid one.
Enterprise Java licenses are charged per developer seat, just saying.