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

81–90 of 346 posts

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

#81

Post by erik_seaberg »

em-bee wrote: post #52
TacticalCoder wrote: post #49

Earlier quoted context omitted.

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

you didn't necessarily change the result of (do-it first), you may have, but that just means you introduced another error. i think the approach here is to accept that you fixed the bug for the second call, but you will still have to go back and retest the first call.

Lisp used to specialize in offering extravagantly expensive features, maybe time travel debugging would be a good addition.

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

#82

Post by mathisfun123 »

xbpx wrote: post #75
mathisfun123 wrote: post #70

Earlier quoted context omitted.

> The repl driven workflow is amazing and the lisp images are rock solid and highly performant. do people not realize that basically everything vm/interpreted language has a repl these days? https://www.digitalocean.com/community/tutorials/java-repl-j... https://github.com/waf/CSharpRepl https://pub.dev/packages/interactive not to mention ruby, python, php, lua hell even c++ has a janky repl https://github.com/root-p…

A REPL isn't just a REPL. You are comparing modern day Toyota Corollas to a Spaceship sent from the future to the 80s. One is just different level radical. At least when it's baked by SLY or SLIME

here is the list of slime features on the slime webpage

>Code evaluation, compilation, and macroexpansion.

>Online documentation (describe, apropos, hyperspec).

>Definition finding (aka Meta-Point aka M-.).

>Symbol and package name completion.

>Automatic macro indentation based on &body.

>Cross-reference interface (WHO-CALLS, etc).

https://slime.common-lisp.dev/

and i'm still wondering which of these things i can't do in a python repl? note macroexpansion doesn't count because that's not a dimension of the repl.

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

#83

Post by mrcode007 »

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…

SBCL supports static builds by saving core with runtime into an executable file you can then copy around at will.

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

#84

Post by mathisfun123 »

rfrey wrote: post #74
mathisfun123 wrote: post #70

Earlier quoted context omitted.

> The repl driven workflow is amazing and the lisp images are rock solid and highly performant. do people not realize that basically everything vm/interpreted language has a repl these days? https://www.digitalocean.com/community/tutorials/java-repl-j... https://github.com/waf/CSharpRepl https://pub.dev/packages/interactive not to mention ruby, python, php, lua hell even c++ has a janky repl https://github.com/root-p…

The repls you mention are not like lisp repls. You're being downvoted because your comment makes it sound like you've never programmed a lisp but have strong opinions nonetheless.

>you've never programmed a lisp but have strong opinions nonetheless

i've written racket and clojure (and mathematica, which is a lisp). not multiple 10kloc but enough to understand what the big ideas are. claiming i just haven't written enough lisp is basically the logical fallacy of assuming the premise.

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

#85

Post by LispSporks22 »

mathisfun123 wrote: post #80
memefrog wrote: post #72

Earlier quoted context omitted.

Of course people "realise" this. But those REPLs are not actually REPLs. They are interactive language prompts. They aren't actually REPLs. As the joke goes, Python doesn't have a REPL: it lacks READ, EVAL, PRINT and LOOP. Being able to type in code and have it evaluated one line at a time isn't a REPL.

i have no idea what subtle or nuanced distinction you're trying to strike so what exactly do you imagine is the difference between a lisp repl and a python repl? Edit: people that aren't familiar with python (or how interpreters work in general) don't seem to understand that being able to poke and prod the runtime is entirely a function of the runtime, not the language. In cpython you can absolutely do anything you w…

In TFA, go to the “Try this in your favorite repl”, try that in your “repl” and that would be the fine distinction you’re missing.

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

#86

Post by mathisfun123 »

LispSporks22 wrote: post #85
mathisfun123 wrote: post #80

Earlier quoted context omitted.

i have no idea what subtle or nuanced distinction you're trying to strike so what exactly do you imagine is the difference between a lisp repl and a python repl? Edit: people that aren't familiar with python (or how interpreters work in general) don't seem to understand that being able to poke and prod the runtime is entirely a function of the runtime, not the language. In cpython you can absolutely do anything you w…

In TFA, go to the “Try this in your favorite repl”, try that in your “repl” and that would be the fine distinction you’re missing.

>The answer to that question is the differentiating point of repl-driven programming. In an old-fashioned Lisp or Smalltalk environment, the break in foo drops you into a breakloop.

do you want me to show you how to do this in a python repl? it's literally just breaking on exception...

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

#87

Post by lenkite »

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.

Isn't all this stuff a vector for malicious code and security vulnerabilities in production ?

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

#88

Post by lenkite »

em-bee wrote: post #47
dleslie wrote: post #41

Earlier quoted context omitted.

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.

Java supports live debugging and profiling.

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

#89

Post by moonchild »

lenkite wrote: post #87
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.

Isn't all this stuff a vector for malicious code and security vulnerabilities in production ?

No.

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

#90

Post by nine_k »

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)

Lisp is more of a meta-language than a mere language. Since it's homoiconic, you eventually end up developing a domain-specific language that works great for your subject area. It also may make it a bit harder to onboard new team members, because the level of abstraction which you can reach can be relly high, all while keeping performance reasonable.

Technically, you could run e.g. a Python program under pdb, break on certain exceptions, and fix things inside a living system. It's just not a customary way to do that.

Post reply on HN