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

201–210 of 346 posts

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

#201

Post by mathisfun123 »

versteegen wrote: post #187
mathisfun123 wrote: post #179

Earlier quoted context omitted.

The other guy up above claims this is a feature unique to calling functions, rather than all error states, and that the lisp runtime specifically guards against this. If that's the case then my answer is very simple: it would be trivial to guard function calls (all function calls) to achieve the exact same functionality in python. I'm in bed but it would literally take me 5 minutes (I would hook eval of the CALL_FUNC…

Thank you, you're very helpful despite this raging flame war. I'm glad to hear you can hook opcodes like that, then you really can do anything. And I really need to give "set a defensive breakpoint and then step through the function" an honest go. Now that you say it, I realise I haven't.

>I'm glad to hear you can hook opcodes like that, then you really can do anything

Just in case someone comes around calls me a liar: the way to do this is to spread the bytecodes out one per line and set a line trace. Then when your bytecode of choice pops up, do what you want (including manipulate the stack) and advance the line number (cpython let's you advance the manipulate the line number).

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

#202

Post by kgwgk »

mathisfun123 wrote: post #182
lispm wrote: post #178

Earlier quoted context omitted.

> It works in code compiled from c++ too: define and associate a signal handler for sigkill, call a function whose symbol can't be runtime resolved by the linker, sigkill is sent and caught, define your function (in your asm dejure), patch the GOT to point from the original symbol to wherever the bytearray is with your asm, and voila. I don't need to do anything like that in Lisp. I just define the function and RESUM…

Do you think the magic fairies are doing it for you? Your interpreter/runtime is still doing it whether you're aware of it or not. My point is very simple: I can do it too, in any language I want, and so there's nothing special about lisp.

https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

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

#203

Post by lispm »

mathisfun123 wrote: post #198
lispm wrote: post #186

Earlier quoted context omitted.

I thought you know Lisp? Now you are surprised that Lisp often looks up functions via symbols -> aka "late binding"? How can that be? That's one of the basic Lisp features. Next you can find out what optimizing compilers do to avoid it, where possible or where wanted.

At no point in time did I claim to know lisp well. I stated my familiarity at the outset. But what you all did was claim to know a lot about every other interpreted runtime without a grain of salt. >Next you can find out what optimizing compilers do to avoid it, where possible or where wanted. But compilers I am an expert in and what you're implying is impossible - either you have dynamic linkage, which means symbol…

> But compilers I am an expert in and what you're implying is impossible

> it is either resolved statically or at runtime

Just tell Lisp which calls to statically resolve, inline, optimize. Overwrite the global default.

  (defun foo (a)
    (declare (inline +)
             (optimize (speed 3))
             (type (integer 0 100) a))
    (* 10 (+ 3 a)))
Above tells Lisp to inline the + function, optimize for speed and declares the type of a to be an integer in the range 0 to 100.

  * (disassemble #'foo)
  ; disassembly for FOO
  ; Size: 32 bytes. Origin: #x7006DC8544  ; FOO
  ; 44:       40190091         ADD NL0, R0, #6
  ; 48:       5C0180D2         MOVZ TMP, #10
  ; 4C:       0A7C1C9B         MUL R0, NL0, TMP
  ; 50:       FB031AAA         MOV CSP, CFP
  ; 54:       5A7B40A9         LDP CFP, LR, [CFP]
  ; 58:       BF0300F1         CMP NULL, #0
  ; 5C:       C0035FD6         RET
  ; 60:       E00120D4         BRK #15    ; Invalid argument count trap
As you can see in the machine code, Lisp then uses the native machine code ADD and MUL instructions.

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

#204

Post by vindarel »

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…

> lots of interoperability libraries

That's true. For cases when you want to start with a good set of libraries (json, csv, databases, HTTP client, CLI args, language extensions…), I am putting up this collection together: https://github.com/ciel-lang/CIEL/ It can be used as a normal Quicklisp library, or as a core image (it then starts up instantly) or as a binary.

It can run scripts nearly instantly too (so it isn't unlike Babashka). We are ironing out the details, not at v1.0 yet.

> handling a runtime error by just fixing the broken code--in-place, without any restarts [from the blog]

Also (second shameless plug) I should have illustrated this here: https://www.youtube.com/watch?v=jBBS4FeY7XM

We run a long and intensive computation and, bad luck, we get an error in the last step. Instead of re-running everything again from zero, we get the interactive debugger, we go to the erroneous line, we compile the fixed function, we come back to the debugger, we choose a point on the stackframe to resume execution from (the last step), and we see our program pass. Hope this illustrates the feature well!

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

#205

Post by anonzzzies »

I love CL and I really miss it when i'm doing something else. I mean, many things are such a pain in 'modern' languages that it's not even funny, when you compare it to the Lisp experience of even decades ago.

There are many cons, but those are simply not as bad as most of the pure technical language/dev env cons in almost everything else. Sure Python & JS have more uptake, more libraries etc, but the experience of developing for them is so much worse. IMHO of course. I have been doing a lot of languages over the years including C#, TS, Py, Hs and more esoteric ones, but I keep coming back to CL (SBCL + emacs + Slime) when I get seriously angry about stuff that is missing or plainly bad in those languages. It makes me relaxed and convinced there is some good in the world after all.

I am currently raising for a product we (foolishly so) bootstrapped in Typescript but now we will, for a launch version, redo it in CL. Meaning I get to work with / in CL (and all of the fun stuff; implementing DSL, code generation, working with macros, implementing a static type solver etc) for the coming 3-5 years before we launch. Lovely.

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

#206

Post by jokethrowaway »

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's hard to maintain and read. There you go.

I'm not a huge fan of lisp, but I do like the language. Unfortunately, it's way too hard on 90% of the developers. They need some more structure so they can think about one thing at a time, which is why C-like syntax won in the end.

All the best developers I know are into Lisp or Haskell (or both). They can crank out ridiculous code which then goes unused because maintenance would be too much of a burden. Sometimes I write some really complex one-liners (which are like 5-10 lines long) to do some tasks using all the possible hacks to avoid having to type an extra character. I might be able to do that, but most developers wouldn't be able to see how the data get transformed and keep all of that in their mind. Whatever I wrote is unmaintainable by most people.

The reality is that the majority of people can't grasp their mind around complex concepts. Which is ok, most developers write a few API endpoints and some UI components, they don't need much to create value.

We can get some good concepts from the functional world and transfer them to C-like syntax languages though. We can even have some of the programmability of Lisp (but not all of it) via macros.

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

#207

Post by pjc50 »

anonzzzies wrote: post #205

I love CL and I really miss it when i'm doing something else. I mean, many things are such a pain in 'modern' languages that it's not even funny, when you compare it to the Lisp experience of even decades ago. There are many cons, but those are simply not as bad as most of the pure technical language/dev env cons in almost everything else. Sure Python & JS have more uptake, more libraries etc, but the experience of d…

> There are many cons

Can't have Lisp without cons. (sorry)

What do you miss in Lisp when working in C#?

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

#208

Post by vkazanov »

mathisfun123 wrote: post #148
vkazanov wrote: post #143

Earlier quoted context omitted.

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

Listen, I've been on many sides: Lisp stuff, Python stuff, C stuff, etc. I don't think that "something has to be learned". Lisp has many good ideas, Python has good ideas. But REPL-driven development is not one of them. But let me explain.

You see, it's not about how REPL in Python just does not allow something (even though it is rather primitive). Python makes it superhard to tweak things, even if you can change a certain variable in memory. Here's why.

Think about Lisp programs, including OOP flavours. These fundamentally consist of 2 things: a list of functions + a list a variables. If you replace a function or a variable then every call will go through it. And that's it. You change a function - all calls to it will be routed through the new implementation. Because of REPL-centric culture of things people really do organise their programs around this style of development.

Python was developed with an dynamic OOP idea in mind where everything is an object, everything is a reference. Endless references to references of references to references. It's a massive graph, including methods and functions and objects and classes and metaclasses. There is no single list of functions where you can just replace this name-to-implementation mapping.

TL;DR Replacing a single reference doesn't change much in the general case. It does work in some cases. But that's not enough for people to rely on it as main development driver.

Python fundamentally makes a different tradeoff than your average lisp.

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

#209

Post by vkazanov »

darthrupert wrote: post #177
vkazanov wrote: post #143

Earlier quoted context omitted.

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

Am I some kind of a python unicorn? I do those things with python just about every time I write new python code. The thing Common Lisp does that python doesn't (so far) is outputting well-performing code.

No, you're fine. For certain things Python REPL-like live development is ok indeed. Say, if your program boils down to a list of functions. Think request handlers or something.

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

#210

Post by lukego »

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…

Nix has a really convenient new CL libraries packaging upstream now. That verifies everything with sha256. It's quite complete because it's seeded from Quicklisp and had more packages added on (aswell as their native library dependcies.)

Nix isn't to everyone's taste but it demonstrates that you can treat security/reproducibility/etc as orthogonal to Quicklisp and Sourceforge (and to Lisp native tooling in general.)

Post reply on HN