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

It's 2023, so of course I'm learning Common Lisp

log.schemescape.com

Post reply on HN
Print view View original

21–30 of 346 posts

Re: It's 2023, so of course I'm learning Common Lisp

#21

Post by schemescape »

Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner.

Here's what I've liked about Common Lisp so far:

* The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts

* REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for example parsing data from a source you're unfamiliar with, you can just update your code and continue on instead of having to save, possibly compile, and restart from the very beginning

* Common Lisp has a lot of implementations and there's a good deal of interoperability -- I was able to swap out implementations to trade speed (SBCL) for memory usage (CLISP) in one case (multiple compatible implementations is one of the reasons I've been leaning towards CL instead of Scheme for learning a Lisp)

* Even as an Emacs noob, the integration with Common Lisp is excellent, and it works great even on my super slow netbook where I've been developing -- this isn't as big of an advantage these days with fast computers, VS Code, and language servers, but it's definitely retrofuturistic

There's also a few things I don't like:

* The most popular package manager (QuickLisp) is nice, but not nearly as featureful as I've become accustomed to with newer languages/ecosystems

* Since the language itself is frozen in time, you need lots of interoperability libraries for threads, synchronization, command line arguments, and tons of other things

* I really, really wish SBCL could support fully static builds, to enable distributing binaries to non-glibc Linux distributions

I'm sure there are more pros/cons, but that's what came to mind just now.

Re: It's 2023, so of course I'm learning Common Lisp

#22

Post by em-bee »

Blackthorn wrote: post #14
peanutz454 wrote: post #12

Earlier quoted context omitted.

This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)

It's questionable whether it's really much better than just a debugger with a core dump (what I usually work on, it's not any better). It is, however, a pretty snazzy feature.

with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required.

smalltalk can do the same btw. i had been working on a small website where a specific request from the browser would fail. instead of sending a failure message the request would just hang. in the mean time on the server in my pharo smalltalk window an error would pop up. when i fixed the error, the download of the request resumed in the browser as if nothing had happened other than a delay.

Re: It's 2023, so of course I'm learning Common Lisp

#23

Post by schemescape »

Blackthorn wrote: post #14
peanutz454 wrote: post #12

Earlier quoted context omitted.

This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)

It's questionable whether it's really much better than just a debugger with a core dump (what I usually work on, it's not any better). It is, however, a pretty snazzy feature.

In my experience, it's definitely better for prototyping because if you hit an error that is difficult to reproduce, you can update your code and try again, without having to try and create reliable steps to reproduce the problem.

Re: It's 2023, so of course I'm learning Common Lisp

#24

Post by em-bee »

paulddraper wrote: post #17
peanutz454 wrote: post #12

Earlier quoted context omitted.

This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)

Performance, approachability Someone's going to argue with me. Fair enough. Provide your explanation.

this is an age old argument, but given the popularity of other slower languages, i'd rather think that approachability is the more critical issue.

Re: It's 2023, so of course I'm learning Common Lisp

#25

Post by koito17 »

I use Clojure at work but wow do I miss just about everything about Common Lisp whenever I have to debug anything or want performant code. Being able to be in nested errors and click at any part of the stack to inspect lexical bindings is extremely useful, and more importantly, clicking on an object then pushing M- to copy it to my REPL is much nicer than what Clojure offers (tap>, which I consider a glorified pretty printer even if you use tools like Portal).

As for performance, well, Common Lisp lets you statically type things, and SBCL can emit really efficient code if you do this. I find it helpful to run DISASSEMBLE on my own code to see what exactly is being emitted and optimize from there. And more importantly, packages like SB-SIMD and Loopus are a god send for any number crunching application.

Re: It's 2023, so of course I'm learning Common Lisp

#26

Post by Blackthorn »

em-bee wrote: post #22
Blackthorn wrote: post #14

Earlier quoted context omitted.

It's questionable whether it's really much better than just a debugger with a core dump (what I usually work on, it's not any better). It is, however, a pretty snazzy feature.

with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required. smalltalk can do the same btw. i had been working on a small website where a specific request from the browser would fail. instead of sending a failure message the request would just hang. in the mean time on the server in my pharo smalltalk window an error would pop up. whe…

> with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required.

We like to make sure everything running in prod is verifiably built from source in-repo. So that's the thing, while it's a really snazzy feature for sure, the value over the rest of the world is on the questionable side. At least for our use case, but I think it's true for most use cases.

edit: Also really curious about your smalltalk and pharo experience. Sounds fascinating!

Re: It's 2023, so of course I'm learning Common Lisp

#27

Post by Zambyte »

schemescape wrote: post #11
Zambyte wrote: post #9

I don't see why the author says: > I had previously abandoned using Scheme because, frankly, I ran out of free time for exploratory programming. But they find Common Lisp acceptable. In what way are Schemes more "exploratory" than Common Lisp? Isn't that exactly what the author says they like about CL (REPL driven development)?

Sorry that was unclear. What I meant was: a while back, I was exploring Scheme (motivated by SICP) and then ran out of free time. Now, I’ve got some free time again and want to try Common Lisp because of the REPL-driven workflow. It wasn’t meant to be a comment on Scheme vs. CL.

I see, thanks for clarifying!

Re: It's 2023, so of course I'm learning Common Lisp

#28

Post by tikhonj »

peanutz454 wrote: post #12
nine_k wrote: post #4

The scoop: Scheme and Janet are great, but the author wants a more standalone language. What makes the difference is the breakloop, a full-blown REPL that opens when an error in a program occurs. Not a stacktrace, not a debugger; just build from the point where it's currently broken.

This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)

Because language popularity is, at best, loosely correlated with any intrinsic qualities of the language itself.

Re: It's 2023, so of course I'm learning Common Lisp

#29

Post by em-bee »

schemescape wrote: post #11
Zambyte wrote: post #9

I don't see why the author says: > I had previously abandoned using Scheme because, frankly, I ran out of free time for exploratory programming. But they find Common Lisp acceptable. In what way are Schemes more "exploratory" than Common Lisp? Isn't that exactly what the author says they like about CL (REPL driven development)?

Sorry that was unclear. What I meant was: a while back, I was exploring Scheme (motivated by SICP) and then ran out of free time. Now, I’ve got some free time again and want to try Common Lisp because of the REPL-driven workflow. It wasn’t meant to be a comment on Scheme vs. CL.

i found the repl driven workflow intriguing but i could never get into it. i am not an emacs user and the vim integration wasn't as good as slime promises to be and i couldn't really get comfortable running lisp from within vim. not ssure, i probably didn't try to hard.

smalltalk on the other hand made this a lot easier. not repl driven but having an actual UI to manage code and handling errors it provides the same ability to fix issues at runtime without restarting but with a nicer interface to manage the code.

Re: It's 2023, so of course I'm learning Common Lisp

#30

Post by gorjusborg »

schemescape wrote: post #11
Zambyte wrote: post #9

I don't see why the author says: > I had previously abandoned using Scheme because, frankly, I ran out of free time for exploratory programming. But they find Common Lisp acceptable. In what way are Schemes more "exploratory" than Common Lisp? Isn't that exactly what the author says they like about CL (REPL driven development)?

Sorry that was unclear. What I meant was: a while back, I was exploring Scheme (motivated by SICP) and then ran out of free time. Now, I’ve got some free time again and want to try Common Lisp because of the REPL-driven workflow. It wasn’t meant to be a comment on Scheme vs. CL.

Thanks for clarifying.

I recently went into the lispy rabbit hole for a while.

Scheme is so beautiful.

CL seems more willing to compromise for pragmatism.

Post reply on HN