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

131–140 of 243 posts

Re: Common Lisp Implementations in 2023

#131

Post by ducktective »

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

Excellent. It's kinda like Janet, right (in terms of being a battery-included LISP)?

Re: Common Lisp Implementations in 2023

#132

Post by matrix12 »

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…

The linux lispworks runs fine for me on Freebsd with linux_compat.

Re: Common Lisp Implementations in 2023

#133

Post by vindarel »

ducktective wrote: post #131
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,…

Excellent. It's kinda like Janet, right (in terms of being a battery-included LISP)?

Yes, and kinda like Babashka for Clojure, in terms of fast starting scripting environment with one binary and useful built-in utilities.

Re: Common Lisp Implementations in 2023

#134

Post by hvs »

For a period much earlier in my career (think early 00's) I seriously desired to work in Common Lisp professionally. Through a series of life decisions and other opportunities, that never really happened. But I continued to work on Lisp projects on my own and use it for various things. I don't consider it a "superpower," and I don't think it makes me 10x more productive or anything like that. Most modern languages have stolen most of the thunder from Lisp (other than macros) so I would be hard-pressed to recommend it for greenfield development.

That said, I love working in it. I don't have any illusions that it will make a "comeback" or that I will ever make money writing it (I long ago switched to looking for job opportunities based on the problem domain rather than the toolset), but I continue to use it personally because it makes me happier than any other language.

Re: Common Lisp Implementations in 2023

#135

Post by ducktective »

vindarel wrote: post #133
ducktective wrote: post #131

Earlier quoted context omitted.

Excellent. It's kinda like Janet, right (in terms of being a battery-included LISP)?

Yes, and kinda like Babashka for Clojure, in terms of fast starting scripting environment with one binary and useful built-in utilities.

You are very active in CL community, vindarel. Thanks!

Re: Common Lisp Implementations in 2023

#136

Post by jgerrish »

oblio wrote: post #103
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…

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 everyone looking into or using QuickLisp, it uses http instead of https: https://github.com/quicklisp/quicklisp-client/issues/167

You can patch your version to fix this. I'd also recommend adding firewall rules to deny in case your patches roll back. And any other mitigation. Or stricter policies, such as not using it, if it makes sense for your organization.

And the AI bots? I hope there aren't people herding them who don't want to, that's how you get unloving brats and a crappy world.

Re: Common Lisp Implementations in 2023

#139

Post by oblio »

tmtvl wrote: post #119
oblio wrote: post #105

Earlier quoted context omitted.

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

I'm confused, is this about Quicklisp itself or about the packages it manages?

I.e. quicklisp 1.1 versus quicklisp 1.0 or libfoo 1.1 vs libfoo 1.0?

Re: Common Lisp Implementations in 2023

#140

Post by mark_l_watson »

vindarel wrote: post #125
ducktective wrote: post #117

Earlier quoted context omitted.

> 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, S…

Yes, compressed SBCL images load so fast that a few years ago I had a command line tool that I wrote using a compressed image. I think the load time for the tool was perhaps 100 milliseconds.
Post reply on HN