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

181–190 of 243 posts

Re: Common Lisp Implementations in 2023

#181

Post by _ph_ »

noloblo wrote: post #180
_ph_ wrote: post #172

Earlier quoted context omitted.

What do you mean by that? A lot of people use racket, a lot of people use SBCL, which is indeed significantly faster. They are actually completely different software for different purposes and very different strengths.

what are strengths of sbcl over racket? what are strengths of racket over sbcl? if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl? what purposes does racket uniquely serve not served by sbcl?

> what are strengths of sbcl over racket?

SBCL is a Common Lisp implementation, racket implements variants of Scheme. SBCL is natively compiled, creates standalone executables.

> what are strengths of racket over sbcl?

It implements various scheme dialects, the ability to integrate different languages in one image is unique. It offers an integrated enviroment with a lot of libraries included, that is why it is popular in academia.

> if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl?

First of all, they implement different programming languages, that means they are not competing directly with each other and are very different beasts as discribed above. Racket seems to be very popular in academia, while SBCL is more used for practical software development. At least that is the impression I have.

> what purposes does racket uniquely serve not served by sbcl?

I think I have answered that above.

Re: Common Lisp Implementations in 2023

#182

Post by wk_end »

noloblo wrote: post #180
_ph_ wrote: post #172

Earlier quoted context omitted.

What do you mean by that? A lot of people use racket, a lot of people use SBCL, which is indeed significantly faster. They are actually completely different software for different purposes and very different strengths.

what are strengths of sbcl over racket? what are strengths of racket over sbcl? if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl? what purposes does racket uniquely serve not served by sbcl?

They're completely different languages. Common Lisp isn't Racket. Racket is "a Lisp", but it's not Common Lisp (or even Scheme, which it's much more closely based on). You're writing something like:

If Java raw speed > TypeScript raw speed wouldn't most expert curly-bracers by default choose Java?

Differences include all the differences different languages have: features (hygienic macros, continuations, conditions, CLOS, ...), libraries (standard or otherwise), tooling...

Re: Common Lisp Implementations in 2023

#183

Post by lispm »

_ph_ wrote: post #181
noloblo wrote: post #180

Earlier quoted context omitted.

what are strengths of sbcl over racket? what are strengths of racket over sbcl? if sbcl raw speed > racket speed wouldn't most expert lispers by default choose sbcl? what purposes does racket uniquely serve not served by sbcl?

> what are strengths of sbcl over racket? SBCL is a Common Lisp implementation, racket implements variants of Scheme. SBCL is natively compiled, creates standalone executables. > what are strengths of racket over sbcl? It implements various scheme dialects, the ability to integrate different languages in one image is unique. It offers an integrated enviroment with a lot of libraries included, that is why it is popula…

> the ability to integrate different languages in one image is unique

Somehow.

It should be possible to load a C, Prolog and Python implementations into one sbcl image.

The Symbolics Lisp Machine emulator I use comes with C, Pascal, Fortran, several Common Lisp variants, Lisp Machine Lisp in one image.

Kalman Reti once gave a demo how to debug mixed Lisp and C code in a REPL on such a Lisp Machine: https://www.youtube.com/watch?v=o4-YnLpLgtk

Re: Common Lisp Implementations in 2023

#185

Post by kgwgk »

_ph_ wrote: post #171
kgwgk wrote: post #147

Earlier quoted context omitted.

> As an enthusiast, I would be happy to spend a few hundred € for private usage, but not thousands. Note that the cost for private usage starts at a few hundred €. You only get to "thousands" if you include multiple platforms or several support incidents.

Well, it starts at €480 (Linux) - €720 for the Mac for a pure IDE, without the ability to produce executables. You are limited to run your programs inside the development environment, this limits its applicability a lot. You can't write a simple command line utility this way, just to name one example. You cannot give it to a friend etc. The HobbyistDV edition is in my eyes the first really usable one. It is already o…

> The HobbyistDV edition is in my eyes the first really usable one. It is already over €1400

Less than 1000 if you can live with 32 bits but I wonder if someone goes for that option nowadays.

> and that is for a single OS, a single CPU architecture.

The MacOS version supports both Apple Silicon and Intel.

Re: Common Lisp Implementations in 2023

#186

Post by vindarel »

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.

Just don't put a node_modules/ in there!

Re: Common Lisp Implementations in 2023

#187

Post by lispm »

_ph_ wrote: post #146
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…

I am convinced that Lispworks is a great product. From what I can see it comes with a nice IDE and some nice libraries. I would have loved to give it a try, but unfortunately I was never able to do do so. And that is where the critique of the licensing scheme comes from. I am sure there are quite a few professionals for whom Lispworks has great value and the license costs are just a non-issue. But despite being a pro…

> I would like to be able to really evaluate the product before spending a significant amount of money on it, but with the limits of the personal edition, it immediately quit on the first attempt of starting my back-then tiny hobby project.

Usually one contacts the vendor and asks for a time-limited full version of the product for evaluation.

> On the other side, with SBCL I have a really strong Lisp implementation.

That's one of the advantages of a language standard with multiple competing / complementing implementations.

Re: Common Lisp Implementations in 2023

#188

Post by vindarel »

jgerrish wrote: post #136
oblio wrote: post #103

Earlier quoted context omitted.

He's right, though. If I'm a somewhat polyglot developer ambivalent to any language out there, why would I pay those licensing costs when I can just go elsewhere instead? That's what regular devs do, they don't even bother writing articles or commenting on HN :-)

> 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 everyo…

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... )

Re: Common Lisp Implementations in 2023

#189

Post by galaxyLogic »

lelanthran wrote: post #33
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…

> 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. What? I found it informative - clear and to the point about what frustrations you can expect with the licenses. I mean, FCOL, he even made the effort to search google for the cost of the licenses because Franz hides them. What exactly in the following texts do you describ…

I don't think the licensing model is wrong but I think it is stupid, because it keeps new customers away.

There should be a way to charge for the produced value. If many users are using the produced programs, charge for that. For instance keep the basic development environment reasonably priced but charge for the ability to create executables.

My favorite IDE (Integrated Development Environment) at the moment is WebStorm by JetBrains. It is about $60 (?) for personal license with updates per year. I can develop JavaScript programs and run them on any JS platform. It is a nice product which truly adds to my productivity. And I can afford it. And I read that JetBrains is doing financially great.

Re: Common Lisp Implementations in 2023

#190

Post by _ph_ »

kgwgk wrote: post #185
_ph_ wrote: post #171

Earlier quoted context omitted.

Well, it starts at €480 (Linux) - €720 for the Mac for a pure IDE, without the ability to produce executables. You are limited to run your programs inside the development environment, this limits its applicability a lot. You can't write a simple command line utility this way, just to name one example. You cannot give it to a friend etc. The HobbyistDV edition is in my eyes the first really usable one. It is already o…

> The HobbyistDV edition is in my eyes the first really usable one. It is already over €1400 Less than 1000 if you can live with 32 bits but I wonder if someone goes for that option nowadays. > and that is for a single OS, a single CPU architecture. The MacOS version supports both Apple Silicon and Intel.

> Less than 1000 if you can live with 32 bits but I wonder if someone goes for that option nowadays.

Right. I don't count the 32 Bit versions as serious contenders.

> The MacOS version supports both Apple Silicon and Intel.

That is good news. For pure Mac users this is interesting, still very expensive. Personally, my development time is split between MacOS and Linux.

Post reply on HN