Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Lisp: 2022 in review

lisp-journey.gitlab.io

Post reply on HN
Print view View original

11–20 of 77 posts

Re: Common Lisp: 2022 in review

#11

Post by fredrikholm »

dgan wrote: post #7

Disclaimer: not a big Lisp user. Interesting how Lisp code is NOT littered with " if something != null, ...", unlike your average Java project (or even python, but it's less visible), and just works. My understanding is that busines-as-usual handling of nil (empty lists) implicitely confers to Lisp code monadic style which help to avoid tedious checks

It's littered, just hidden. Eg: if, if-let, when, when-let, unless etc. This makes it appear that the data is passed down in a monadic style, but it often isn't; *nil* is not an actionable value.

Re: Common Lisp: 2022 in review

#12

Post by crapaud23 »

dgan wrote: post #7

Disclaimer: not a big Lisp user. Interesting how Lisp code is NOT littered with " if something != null, ...", unlike your average Java project (or even python, but it's less visible), and just works. My understanding is that busines-as-usual handling of nil (empty lists) implicitely confers to Lisp code monadic style which help to avoid tedious checks

This is the way Clojure works too. Nil is treated as an identity/neutral element. This goes beyond lists: in contrast to Common Lisp who equates nil to the empty list, Clojure maintains a distinction and you're supposed to handle nils by correctly implementing functions. This is as easy as using clojure's core functions, they all have been tailored to handle nil as the neutral element.

As a consequence, in Clojure, nil's neutrality extends to other datastructures, for instance (hash)maps. (assoc nil :some :value) => {:some :value}.

Re: Common Lisp: 2022 in review

#13

Post by smcn »

galdor wrote: post #9
Insanity wrote: post #5

Earlier quoted context omitted.

I use CL for hobby projects and do love it. The main difficulty with “industrial strength lisp” is finding places in the industry that want to do so. :/

Talking about Common Lisp in the places I worked for in the past has always be met with mockery and disdain. But then again, I have seen this kind of reaction for every non-mainstream language, so it is not really surprising. I'm currently getting back to CL, hoping to do much more with it for 2023. Being able to develop incrementally in SLIME has been a joy. Hopefully I will manage to find the right project idea to…

I was /that guy/ at my last place and I agree that it's not well received.

Though once I was writing some lisp to fix a problem we were having and I had a developer beside me and he was blown away by what was happening. I think that the interactivity is something which must be experienced to be fully appreciated.

I use it at my current start up and could not imagine using another language. I've become too used to this kind of workflow.

Re: Common Lisp: 2022 in review

#14

Post by galdor »

smcn wrote: post #13
galdor wrote: post #9

Earlier quoted context omitted.

Talking about Common Lisp in the places I worked for in the past has always be met with mockery and disdain. But then again, I have seen this kind of reaction for every non-mainstream language, so it is not really surprising. I'm currently getting back to CL, hoping to do much more with it for 2023. Being able to develop incrementally in SLIME has been a joy. Hopefully I will manage to find the right project idea to…

I was /that guy/ at my last place and I agree that it's not well received. Though once I was writing some lisp to fix a problem we were having and I had a developer beside me and he was blown away by what was happening. I think that the interactivity is something which must be experienced to be fully appreciated. I use it at my current start up and could not imagine using another language. I've become too used to thi…

I just realised you were working on Feetr! I learned you guys were using Common Lisp on Twitter. Small world really.

What implementations are you using, and how are you running it in production, if it is not a secret? Any performance issue with the GC at large scale?

Re: Common Lisp: 2022 in review

#16

Post by dgan »

crapaud23 wrote: post #12
dgan wrote: post #7

Disclaimer: not a big Lisp user. Interesting how Lisp code is NOT littered with " if something != null, ...", unlike your average Java project (or even python, but it's less visible), and just works. My understanding is that busines-as-usual handling of nil (empty lists) implicitely confers to Lisp code monadic style which help to avoid tedious checks

This is the way Clojure works too. Nil is treated as an identity/neutral element. This goes beyond lists: in contrast to Common Lisp who equates nil to the empty list, Clojure maintains a distinction and you're supposed to handle nils by correctly implementing functions. This is as easy as using clojure's core functions, they all have been tailored to handle nil as the neutral element. As a consequence, in Clojure, n…

I like the idea, but JVM is a show stopper for me :/

Re: Common Lisp: 2022 in review

#17

Post by smcn »

galdor wrote: post #14
smcn wrote: post #13

Earlier quoted context omitted.

I was /that guy/ at my last place and I agree that it's not well received. Though once I was writing some lisp to fix a problem we were having and I had a developer beside me and he was blown away by what was happening. I think that the interactivity is something which must be experienced to be fully appreciated. I use it at my current start up and could not imagine using another language. I've become too used to thi…

I just realised you were working on Feetr! I learned you guys were using Common Lisp on Twitter. Small world really. What implementations are you using, and how are you running it in production, if it is not a secret? Any performance issue with the GC at large scale?

Tiny world!

CCL is used locally for two reasons 1) error messages are better and 2) it ensures that we're writing portable code. SBCL is used in production because it's much faster and it's constantly being updated, so we get cool things for free. I have been eyeing lispworks but I don't know that it offers much benefit right now. We do plan on mobile apps at some point and that's a conversation we'll have with them.

Production itself is pretty much just a live image, not much different than what you'd have when you're developing. We use slynk to be able to connect to it and play with the data. Can see that here [0].

GC hasn't caused an issue yet. I imagine we will run into issues latter half of this year when we roll out alerts but those are challenges which can be overcome. That might even be a lispworks thing honestly.

0: https://i.imgur.com/8ACxOXG.png

Re: Common Lisp: 2022 in review

#19

Post by galdor »

smcn wrote: post #17
galdor wrote: post #14

Earlier quoted context omitted.

I just realised you were working on Feetr! I learned you guys were using Common Lisp on Twitter. Small world really. What implementations are you using, and how are you running it in production, if it is not a secret? Any performance issue with the GC at large scale?

Tiny world! CCL is used locally for two reasons 1) error messages are better and 2) it ensures that we're writing portable code. SBCL is used in production because it's much faster and it's constantly being updated, so we get cool things for free. I have been eyeing lispworks but I don't know that it offers much benefit right now. We do plan on mobile apps at some point and that's a conversation we'll have with them.…

Thanks for the info. I'm also using both SBCL and CCL, both to stay portable and because it sometimes help finding issues detected by one and not the other.

If you end up blogging about CL (and tech in general) at Feetr, know that there will be at least one interested reader :)

Re: Common Lisp: 2022 in review

#20

Post by smcn »

galdor wrote: post #19
smcn wrote: post #17

Earlier quoted context omitted.

Tiny world! CCL is used locally for two reasons 1) error messages are better and 2) it ensures that we're writing portable code. SBCL is used in production because it's much faster and it's constantly being updated, so we get cool things for free. I have been eyeing lispworks but I don't know that it offers much benefit right now. We do plan on mobile apps at some point and that's a conversation we'll have with them.…

Thanks for the info. I'm also using both SBCL and CCL, both to stay portable and because it sometimes help finding issues detected by one and not the other. If you end up blogging about CL (and tech in general) at Feetr, know that there will be at least one interested reader :)

That honestly means the world to me, thank you so much!
Post reply on HN