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

121–130 of 243 posts

Re: Common Lisp Implementations in 2023

#121

Post by runevault »

galdor wrote: post #18
account-5 wrote: post #14

I would like to learn Lisp but am easily confused with where to start. What implementation do I use? On a general level do I start with CL, schema, racket, etc (apologies I know this thread is about common lisp). It's all very confusing. I'm like this with most things, like I want to learn Forth too but have that same problem. I learned vanilla JavaScript because I didn't know where to start with the 1000+ frameworks…

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.

I didn't feel like relearning Emacs when I started diving back into CL so I've been using VSCode with the Alive extension and once I got it fully up and running with Quicklisp etc my SBCL has run great.

Re: Common Lisp Implementations in 2023

#122

Post by cellularmitosis »

vindarel wrote: post #88
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…

I quite agree, so I'm making a meta-library to have useful libraries available out of the box: https://github.com/ciel-lang/CIEL/ It's CL, batteries included. You can use it as a library, as a core CL image (loads up faster), and as a binary to have a REPL, and to run scripts: ciel --script myscript.lisp (edit) or just ./myscript with a #!/usr/bin/env ciel shebang. where you have access to HTTP clients, JSON parsers,…

I’ve noticed many lisps and schemes are not set up to simply accept a single file name as the sole command line argument, which is something common to nearly every other platform. Seems like an easy target for reducing friction for newcomers.

Re: Common Lisp Implementations in 2023

#123

Post by cellularmitosis »

mkh wrote: post #72

One should note that while it is true that the last CLISP release was a long time ago and there is not a lot of development going on right now, it's not dead. Bruno Haible just commited last week. The repository is now at https://gitlab.com/gnu-clisp/clisp

That is exactly the problem, there have been many commits to HEAD but no release for 12 years??? It isn’t dead, it is undead. Strange.

Re: Common Lisp Implementations in 2023

#124

Post by kgwgk »

oblio wrote: post #120
kgwgk wrote: post #108

Earlier quoted context omitted.

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

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"

Re: Common Lisp Implementations in 2023

#125

Post by vindarel »

ducktective wrote: post #117
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?

With SBCL, the bare-bones image would be ±100MB, with core compression (a single flag to set in the .asd file) I get apps at ±25MB. The startup time of the latter is ±0.30s, the bigger executable is faster. My app would be a web app, with the webserver, templates, and many libraries. This binary also contains the Lisp debugger and compiler, which is useful to interact with it when it's running.

In a latest version, SBCL switched to compression with zstd, which makes the compression process 4 times faster, decompression around 2 times, and it saves around +10% more space.

On reddit (link below), a user speaks about LispWorks binaries of ±9MB.

Re: Common Lisp Implementations in 2023

#126

Post by vindarel »

cellularmitosis wrote: post #122
vindarel wrote: post #88

Earlier quoted context omitted.

I quite agree, so I'm making a meta-library to have useful libraries available out of the box: https://github.com/ciel-lang/CIEL/ It's CL, batteries included. You can use it as a library, as a core CL image (loads up faster), and as a binary to have a REPL, and to run scripts: ciel --script myscript.lisp (edit) or just ./myscript with a #!/usr/bin/env ciel shebang. where you have access to HTTP clients, JSON parsers,…

I’ve noticed many lisps and schemes are not set up to simply accept a single file name as the sole command line argument, which is something common to nearly every other platform. Seems like an easy target for reducing friction for newcomers.

Thanks for the feedback. I'll look into it, it's early enough to change.

(edit) forgot to mention we can simply call ./myscript with the right shebang line. Gets as succinct as one can.

Re: Common Lisp Implementations in 2023

#127

Post by arethuza »

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…

As a former "good old fashioned AI" researcher who used Lisp (LispWorks) between '89 and '95 this seems oddly appropriate!

Re: Common Lisp Implementations in 2023

#128

Post by tmtvl »

abecedarius wrote: post #69
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.

The documentation (B1_Using) does explain that:

> npt was developed with the intention of embedding it in the C language.

Kind of like Guile, but Common Lisp rather than Scheme.

Re: Common Lisp Implementations in 2023

#129

Post by oblio »

kgwgk wrote: post #124
oblio wrote: post #120

Earlier quoted context omitted.

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

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.

Post reply on HN