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

41–50 of 346 posts

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

#41

Post by dleslie »

db48x wrote: post #35
dleslie wrote: post #19

Earlier quoted context omitted.

Eventually you need to work with other people, and using a common time-shared or multi user session is unlikely. Now consider that lisp images generally can't be easily diff'd or merged. And with that the edit-and-continue paradigm loses much of its value. If you have to commit changes to a shared source file anyhow then you'll be not much worse off with debugging a core dump.

People say this a lot, but they fail to take into account that you can debug your server live as it continues to handle normal traffic. Even if you don’t deploy changes via the REPL, merely debugging the problem in a REPL without restarting anything is a huge win.

Lots of languages that are not lisp have this ability.

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

#42

Post by winrid »

ilrwbwrkhv wrote: post #3

Steel Bank Common Lisp is the workhorse which led me to build profitable software companies. I don't think I would be as productive without it. The repl driven workflow is amazing and the lisp images are rock solid and highly performant.

Care to share the companies for those curious?

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

#43

Post by em-bee »

behnamoh wrote: post #31
em-bee wrote: post #22

Earlier quoted context omitted.

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…

I am really curious about your experience with Smalltalk and Pharo!

i am really just a beginner with smalltalk and CL. as a vim user i didn't really have a good integration of the CL repl with the editor (there were tools, but they weren't as straightforward to set up as slime would have been). and when i encountered the breakloop i didn't really know what do to and just tried to get out of it as quickly as i could. (exiting vim is easier ;-) the thing that bothered me was that when i change code in the repl without an integrated editor, then how do i keep track of the changes and make sure i don't loose them? but then, i just never tried to set up a proper environment.

in smalltalk on the other hand you get a nice IDE with all the comforts of a GUI. you have your windows where you browse your code neatly structured in classes and methods. there is a window where you run your app and manage your tests which light up red or green if they fail or pass, another which logs error or other print messages, and if an error happens while an app is running a new window pops up, showing you a trace of what was running and a text field with the code that failed, like in a debugger, and right there you can edit the code and resume.

the code is written to your class, and when you go back to your code browser the change is reflected there, and you can commit it to a version control system. pharo btw has pretty good integration with git, and already a few years ago it almost acted like a git gui. it's probably even better now. the primary downside is that the text editor in pharo is simple, like a browser text area, and not a sophisticated editor like emacs or vim.

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

#44

Post by 0xcde4c3db »

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)

It probably didn't help that a bunch of key Lisp people were leaning hard into proprietary $80,000 minicomputers right around the time that commodity(ish) microcomputers were about to massively explode in popularity.

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

#46

Post by belmarca »

schemescape wrote: post #40
belmarca wrote: post #18

Earlier quoted context omitted.

This is standard in Gambit Scheme as well.

It supports modifying code in the middle of an error and continuing on? I hadn’t found that in a Scheme before!

I'm sure you can find differences, but here's an example adapted from the docs[1]:

  Gambit v4.9.5
  
  > (let ((x 10) (y (- 1 1))) (\* (/ x y) 2))
  \*\* ERROR IN (stdin)@1.30 -- Divide by zero
  (/ 10 0)
  1> ,e
  x = 10
  y = 0
  1> (set! y 2)
  1> ,(c y)
  4
  >
[1]: https://gambitscheme.org/latest/manual/#Debugging

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

#47

Post by em-bee »

dleslie wrote: post #41
db48x wrote: post #35

Earlier quoted context omitted.

People say this a lot, but they fail to take into account that you can debug your server live as it continues to handle normal traffic. Even if you don’t deploy changes via the REPL, merely debugging the problem in a REPL without restarting anything is a huge win.

Lots of languages that are not lisp have this ability.

examples please, because so far i have only seen this from common lisp and smalltalk. there is also pike where i can reload classes or objects at runtime, thus avoiding a full restart, but it's not as closely integrated as in smalltalk and you actually have to build your app in a way that allows you to do that.

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

#48

Post by tgbugs »

schemescape wrote: post #21

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

For static builds, if you're willing to run a slightly older version of sbcl daewok's work on building and linking sbcl in a musl environment might be solution you're looking for. I've tried to port his patches to more recent versions but there are segfaults due to changes in upstream.

https://www.timmons.dev/posts/static-executables-with-sbcl.h... https://www.timmons.dev/posts/static-executables-with-sbcl-v...

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

#49

Post by TacticalCoder »

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.

That sounds intriguing as a Clojure dev but what happens in the following case (not very lispy code but it's just to show what I don't get):

    (do-it (do-it first))
What if (do-it first) works fine, but it's the call to (do-it (do-it first)) that fails?

I get control right where it's broken, so I can fix the do-it defun. Great, I like that. But by fixing it, this means I changed the result of (do-it first).

So the point at which the machine (?) is is a point that's unreachable anymore by the current code.

I hope my example is clear enough.

I really don't understand how that works when fixing what would allow you to continue would change the state at which you're given control to fix things?

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

#50

Post by mark_l_watson »

schemescape wrote: post #21

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

Thanks for your write up. I am looking forward to the next installment.
Post reply on HN