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

141–150 of 346 posts

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

#141

Post by mathisfun123 »

ohyes wrote: post #136
mathisfun123 wrote: post #126

Earlier quoted context omitted.

There's a person above saying that it's about being to able to mutate program state from the repl, which is a thing that's also possible in any repl for a language with managed memory.

Cl Condition system + repl = godmode. Your software crashes? Do you go back and set a breakpoint? No, because you’re already in the stacktrace in the repl exactly where the crash occurred. You fix the code, reload it, tell it to ether run where it left off, or restart from an earlier point.

Flask and Django have the exact same functionality - I've already said that this thing you guys keep talking is just a matter catching exceptions.

https://flask.palletsprojects.com/en/2.3.x/debugging/

https://docs.djangoproject.com/en/dev/ref/settings/#debug

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

#142

Post by mathisfun123 »

lispm wrote: post #140
mathisfun123 wrote: post #132

Earlier quoted context omitted.

> Another difference is that Mathematica does not expose the data representation of programs to the user all the time, where Lisp programs are also on the surface written as s-expressions (aka symbolic expressions) in text. I have already addressed this: FullForm https://reference.wolfram.com/language/tutorial/Expressions.... >Thus the computation is very different. Using a rewrite system for programming is quite clu…

> I have already addressed this: FullForm No you haven't addressed it. The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. > it's just that it's very good at beta reduction and not so good at compiling code... https://reference.wolfram.com/language/ref/Compile.html See "Details and Options"

>The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation.

I have no clue what you're talking about - it's an available primitive and I use it all the time.

>and not so good at compiling code...

Lol I am 100% sure that the majority of lisps cannot be aot compiled.

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

#143

Post by vkazanov »

mathisfun123 wrote: post #117
FPGAhacker wrote: post #113

Earlier quoted context omitted.

Can you connect to a running server or other running application, inspect live in memory data, change live in memory data, redefine functions and classes and have those changes take immediate effect without restarting the server or app? I think that is that is the big difference. It’s a triple edged sword bonded to a double barreled shotgun though, and the very antithesis of the idea of functional programming vs muta…

>Can you connect to a running server or other running application, inspect live in memory data, change live in memory data, redefine functions and classes and have those changes take immediate effect without restarting the server or app? The answer to all of these things, at least in python, is emphatically yes. I do this absolutely all the time. You can debug from one process to another if you've loaded the right ho…

The answer to all these things should be "just doesn't work in practise", not for real programs anyways. Unlike Lisp, Python doesn't lean itself well to this mode of development.

Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding, or REPL-driven development.

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

#144

Post by sussmannbaka »

chlorion wrote: post #65
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…

I have some cons! Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission. I think not supporting encryption or authentication for something as important as fetching source code makes QL a non-starter for me and hopefully for anyone else who…

> I have some cons

I’m sure you do :°)

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

#145

Post by bitwize »

schemescape wrote: post #78
matrix12 wrote: post #69

Earlier quoted context omitted.

I will give you a cons. https://cons.io Gerbil/Gambit scheme are fully static binary generating alternative to CL.

I’ll take a look, thanks! My biggest concern with Scheme is that each implementation seems to have its own ecosystem due to subtle incompatibilities. From an outsider’s perspective it seems a lot more fragmented than CL. Not necessarily a big deal if you have the libraries you want, but it gives me pause.

R7RS, which Gambit (mostly?) supports, helps mitigate this by making library code more portable across implementations. Gambit, in particular, can also very easily take advantage of the wide variety of C libraries; it has one of the easiest, most integrated FFIs of all Scheme implementations.

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

#146

Post by atemerev »

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)

“Avoid success at all costs”

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

#147

Post by asimovfan »

xedrac wrote: post #95
10g1k wrote: post #56

There are plenty of old business systems which are critical, can't be removed or turned off, and use LISP, COBOL, etc. Meanwhile, nothing important uses Clojure or other trendy flash-in-the-pan language. If you want an interesting project, sure, use Clojure or something. If you want money, learn COBOL.

I hear this a lot, but have never once seen a COBOL job posting.

https://de.indeed.com/q-cobol-entwickler-jobs.html?vjk=8d36a...

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

#148

Post by mathisfun123 »

vkazanov wrote: post #143
mathisfun123 wrote: post #117

Earlier quoted context omitted.

>Can you connect to a running server or other running application, inspect live in memory data, change live in memory data, redefine functions and classes and have those changes take immediate effect without restarting the server or app? The answer to all of these things, at least in python, is emphatically yes. I do this absolutely all the time. You can debug from one process to another if you've loaded the right ho…

The answer to all these things should be "just doesn't work in practise", not for real programs anyways. Unlike Lisp, Python doesn't lean itself well to this mode of development. Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding,…

>Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding, or REPL-driven development.

I swear you people are like ostriches in the sand over this - Django, pytest, fastapi, pytorch, Jax, all use these features and more. I work on DL compilers and I use those features every day - python is a fantastic edsl host for whatever IR you can dream of. So just because you're in some sector/area/job that doesn't put you in contact with this kind of python dev doesn't mean it's not happening, doesn't mean that python doesn't support it, doesn't mean it's an accidentally supported API (as if such a thing could even be possible).

Really what this convo is doing is underscoring for me how there really is nothing more to be learned from lisp - I had a lingering doubt that I'd missed some aspect but you guys are all repeating the same thing over and over. So thanks!

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

#149

Post by victorbjorklund »

opportune wrote: post #92

I see a lot of “coding” talk in the blog and comments from the author here, but few mentions as to what kind of software they’re building or what use cases they’re targeting. My hot take is that the reason functional programming never took off is that, while it certainly is fine for writing programs, most software these days is not “program running locally on my pc/server from the command line until it completes” and…

Whatsapp and discord runs on functional elixir/erlang. I heard they are pretty big and not hobby projects.

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

#150

Post by [deleted] »

koito17 wrote: post #79
schemescape wrote: post #77

Earlier quoted context omitted.

Quicklisp doesn’t use TLS or signatures? How have I not heard this before? That would be unbelievably irresponsible. Has this really not been addressed by the CL community? Edit: here’s the issue: https://github.com/quicklisp/quicklisp-client/issues/167 Thanks for bringing this up!

The reason for this is quite simple: portability. Quicklisp also uses plain TAR files to distribute dists. Why? Because quicklisp has a built-in TAR extractor written in 100% standard/portable CL. This allows Quicklisp to run on just about everything, from your computer to real LispMs and operating systems like Mezzano. TLS comes up every time someone discusses Quicklisp, but nobody bothers to go ahead and actually i…

[deleted]
Post reply on HN