dieggsy

tl;dr you just don't really do that.

99% of the time, you simply write the code or change in the sources first, then compile/run it in the runtime.

If you're modifying the runtime directly at the REPL without having sources, good luck? or you don't really care about persisting those changes. CL has pretty good introspection, so you could look at the source expression of a function defined at the REPL for example, if you really wanted to recover something (and happened to put the change in a function first), but this isn't always reliable.

I don't object to any of this. "Restart this system from initial state" is quite a bit more common than people imagine in CL. I was hinting at it perhaps being even more common than image-based development, though don't quote me on that. I personally don't even really create Lisp images in dev (save for creating executables that I don't then further modify, which are technically images in SBCL).

Incremental runtime modification is great for development, but I very frequently restart (from sources) every so often, and certainly at least before deployment to verify everything is working as expected. Sometimes because it's completely necessary, sometimes for my own sanity.

For production, I think it's a very "neat" thing to be able to do and I've heard some great stories (no personal experience), but it's definitely a foot gun if not used very carefully.

You may already know of these, but for others curious:

I'm also not a huge fan of quicklisp, though bundles[0] made it a little more bearable for me. You may also consider vend[1], ocicl[2] (heavily AI-assisted recently), or qlot[3].

  [0] https://www.quicklisp.org/beta/bundles.html
  [1] https://github.com/fosskers/vend
  [2] https://github.com/ocicl/ocicl
  [3] https://github.com/fukamachi/qlot

For macroexpansion, SLIME and SLY have macrostep functionality that lets you expand macros in place, which has helped me immensely on more than one occasion, though you can also manually expand with macroexpand.

As a Common Lisp developer, the intro about Lisp strikes me as sort of mostly(?) true.

I would say in my experience we do actually "compile and execute" code, we can just do this incrementally and with less context switching because of the described workflow. But quite often there are in fact separate compile and run steps, it's just not at the whole program level (say, compile a function and run it or a calling function).

And despite how often it's shown off as a strength, redefining code during actual execution isn't quite that common, I think. Yes, it is done sometimes, but lots of programs don't really fit that paradigm in the first place. It can work well for e.g. some games or long running servers.

As for working in an image without source code: this seems like a terrible idea. You might do this for trivial, one off experiments, but in general you benefit from writing out and organizing your code early. I'm not even aware of a particularly easy or clean way to write out source code from an image as described. It could be done, but all the ways I can think of sound like more of a pain or mess than anything. Could just be my experience or I'm missing some neat feature of a commercial Lisp or something.

mine is a new IDE that's part of the Coalton project, but is meant to be used for Common Lisp as well: https://coalton-lang.github.io/mine/

I have not tried it, I'm an Emacs nerd.

Oh yeah, way more fun :) I just kinda saw CL in the Clojure and was trying to make it look like that.

For me, the most effective way to read Lisp is to essentially forget the parentheses (I shadow them out in matching, low contrast colors) and go almost entirely by indentation. I find this makes it more similar to reading other languages, though granted not exactly the same.

You do have to keep up with the parentheses of course, but editor settings or extensions can make this automatic if not invisible.

CL also has pretty much arbitrarily extensible syntax:

- https://sr.ht/~dieggsy/whisper/

- https://dieggsy.com/json-literals.html

And could also be used to build languages, supporting more modern programming paradigms (though yes, I believe Racket does make this easier):

- https://coalton-lang.github.io/

I also might have written the Common Lisp example using reduce as well, which is in the standard library, but that's preference. Nice to have the option though:

  (defun calculate (instructions)
    (reduce
     (lambda (result op-value)
       (destructuring-bind (operation value) op-value
         (case operation
           (:add (+ result value))
           (:subtract (- result value))
           (:multiply (* result value)))))
     instructions
     :initial-value 0))

  (calculate '((:add 5) (:multiply 3) (:subtract 4))) ;; => 11

I use emacs --daemon with emacsclient for this. I always have a running emacs instance, and connect with the client. Opening and quitting a client is near instant.

Ha! I was going to disagree, but then I realized I force most monospace html entities to use a specific font in my browser (using a wildcard stylus stylesheet). This is quite nice to normalize things (and sidestep atrocious font choices) actually.

Anyway, turned it off; sure enough, misaligned.

Not sure if humor, but this is meant to make a distinction with a non-human readable compilation target, many of which aren't, even when using high level languages.

Just resubmit it, you'll probably get a new link. I get something different every time.

I love Wikipedia and think it's one of the greatest resources on the Internet, but there's absolutely a lot of bias in Wikipedia. Even within the same language, I think a lot of it has to do with how many people have or are contributing to a page, whether there's a recent event affecting it, how polarizing or political the subject, etc. But it's not hard to find examples of straight up opinions or very incomplete narratives.

I've also noticed huge differences between two different language versions of the same articles. (English/Spanish specifically). Sometimes they even feel independently written.

Of course, we should all do our part to improve these things when we spot them, if we're able.

This is fun. Is it not checking for previously submitted URLs though? I can seemingly re-submit the exact same URL and get a new link every time. I would expect this to fill the database unnecessarily but I have no idea how the backend works.

Agreed. Because of this (and regardless), archive everything:

https://web.archive.org/web/20260114140733/https://www.spark...

The top comment in the article mentions it, but chawan[1] is really quite neat. Many sites are still have their quirks (or may be broken), but I think it's the closest I've seen a text browser approximate a "real" browser. The support for CSS, JS, and images (depends on your terminal) is already quite impressive even if imperfect. To my knowledge it's an actual browser implementation rather than "cheating" by using an existing browser like browsh (which is still quite cool).

[1] https://chawan.net/

I love CHICKEN Scheme! Nice to see it mentioned. Though I think it's worth pointing out it compiles to something pretty far from handwritten C, to my understanding. I think this is true of both performance and semantics; for example you can return a pointer to a stack allocated struct from a foreign lambda (this is because chicken's generated C code here doesn't really "return", I think. Not an expert).

Of course you can always drop to manually written C yourself and it's still a fantastic language to interop with C. And CHICKEN 6 (still pre-release) improves upon that! E.g structs and Unions can be returned/passed directly by/to foreign functions, and the new CRUNCH extension/subset is supposed to compile to something quite a bit closer to handwritten C; there are even people experimenting with it on embedded devices.

Seriously. I do think people should spend enough time with bash or posix sh to be comfortable with it, but I'd recommend everyone at least just try fish. It's a lovely interactive experience out of the box with colors, completions, a great prompt, etc. Plus, the scripting language is quite comfy. Like, somewhere between bash and Python (if you find Python comfy, I guess). At least to me it makes more intuitive sense, once I got over the fact that "it's not bash/zsh."

It's written in Rust, if you care about that sort of thing (I switched before that was a thing). And for simple one-liners, compatibility actually has improved at least a bit (like you can do && now, which wasn't a thing before).

Write your shell-specific helper scripts or personal scripts in fish, write your portable scripts in Python or Bash. Look, I love standards. Sometimes non-standard things make sense though. Sometimes they even make more sense in the right context.

Or maybe you'll hate it. That's fine. People won't know until they try though.

For something newer and even more different, check out nushell. I don't have much experience with it, but a lot of its ideas are enticing.

I think I mostly agree with the thesis here, but I actually liked the point in the title at face value, too. We need both, I think. I guess I'll be another annoying Lisp guy, but:

> At this point, the right question to ask would be, well can you write a static-typing library for Scheme that then automatically checks your code for type errors? And the current answer, for now and for the foreseeable future, is no. No mainstream language today allows you to write a library to extend its type system.

The author seems to provide a counter example themselves(?):

> Racket and Shen provide mechanisms for extending their type systems...

I wonder if this is as clear-cut as the author is making it out to be. Coalton, which is effectively a library (and language) for Common Lisp, seems like it basically does this. Maybe that's not exactly what the author is referring to, because it is essentially a new language on top of Lisp using its meta-programming facilities, as opposed to merely extending the type system. Still, it can be used as a library right alongside Lisp code, so I think it's in the same spirit of of the first question of writing a "static-typing library that automatically checks your code" in a dynamic language.

Standard scheme may or may not be able to do this, but most Scheme implementations have unhygienic macros like CL's too, so I'd assume something similar would be possible. The fact that that these tend to be extensions from implementation designers might align with the article's point though. Also somewhat to the author's point, Coalton does rely strongly on CL's underlying type system, for which there's no real equivalent in Scheme. It also relies on implementation-specific optimizations alongside that.

For what it's worth you can (and indeed people have) written object systems in Scheme, despite the language not having one, though they tend not to be performant, which is likely another point towards using/writing a different language. CL also tends to allow fairly deep extension of its object system through the Meta-object Protocol.

I guess my point is that in my (probably biased) opinion, Lisps, or other languages with very strong meta-programming facilities, are pretty close to the language longed for in "Perhaps one day we'll have such a language." They aren't a silver bullet, of course. CL has no easy way to write performant coroutines/continuations, for example, even given all its extensibility. Scheme has no real type system, etc. etc.

I don't think any of this invalidates the articles points, I'm just not sure I agree with the absolutes.

Gmail is a product, but the comment wasn't saying "Gmail the product deserves to be shamed... ", more like "the Gmail team/devs/company deserves to be shamed...", which is why the plural still made sense to me (given the omission of an explicit "team"). The singular makes sense to me too.

In any case, I wasn't really interested in correcting or proving anyone right or wrong, just pointing out an interesting linguistic detail and where the grammar may have come from.

It's quite common in UK English (and maybe others, I don't know), to refer to "singular" or collective non-people entities (such as companies, I know Gmail itself isn't one) using the plural form of verbs.

This isn't in my natural speech, but I quite like it; it seems to kind of imply "the people behind [company]" rather than anthropomorphizing the company itself. ...generally though I think it's just colloquial convention and not that deep.

I think you're not wrong, but it's not necessarily a problem? I might argue that's actually part of the main point the article is making. The software is already written in C, well understood and optimized in that language, and quite stable, so they'd need very compelling reasons for a rewrite.

I think the "lingua franca" argument for C and the points at the end about what they'd need from Rust to switch do go beyond merely justifying a decision that's already been made, though.

I think I meant the same thing, but you said it much more clearly, thanks!

I'm not sure I'd say this is "the other way around"; Coalton strives to implement Haskell or ML-adjacent semantics (in the type system, for example) with Lisp syntax. "With" here meaning that it is both implemented in and written with Lisp syntax.

Edit: I think I see what you mean now. Lisp backend vs Haskell backend.

Anyway, Coalton is a joy to use and IMO a breath of fresh air in CL. It's quite easy start using as a library; go all-in or only use it in specific parts of the code. It's great to be able to choose between (or intermix)the flexibility of CL and the guarantees of a statically typed language (as well as some nice performance boosts with arguably less work). Some aspects are still young (some of the standard library, ecosystem, editor support), but it's quite thoughtfully crafted and I'm excited to see where it goes.

It seems okay to me to be upset with the system and also point out the specific wrongs of companies in the right context. I actually think that's probably most effective. The person above specifically singled out Google as a reply to a comment praising the company, which seems reasonable enough. I guess you could get into whether it's a proportional response; the praise wasn't that high and also exists within the context of the system as you point out. Still, their reply doesn't necessarily indicate that they're not upset with all companies or the system.

I found this, which looks like it's for an earlier version: https://tigerbeetle.com/blog/2023-07-11-we-put-a-distributed...

My eyes kind of glaze over as I read this but maybe it will be more helpful to you.

Are you by chance a Common Lisp developer? If not, you may like it (well, judging only by your praise of stability).

Completely sidestepping any debate about the language design, ease of use, quality of the standard library, size of community, etc... one of its strengths these days is that standard code basically remains functional "indefinitely", since the standard is effectively frozen. Of course, this requires implementation support, but there are lots of actively maintained and even newer options popping up.

And because extensibility is baked into the standard, the language (or its usage) can "evolve" through libraries in a backwards compatible way, at least a little more so than many other languages (e.g. syntax and object system extension; notable example: Coalton).

Of course there are caveats (like true, performant async programming) and it seems to be a fairly polarizing language in both directions; "best thing since sliced bread!" and "how massively overrated and annoying to use!". But it seems to fit your description decently at least among the software I use or know of.

While that would certainly be a factor, I think I'd argue it's less about where you're from and more about what your interests or experience are.

I actually think the title as it is now has more mass appeal; it's very general and might pique your curiosity if you're interested in either 3-D modelling or paper crafting.

On the other hand if it had the "SR-71 Blackbird" in the title, some readers might shy away due to either not knowing what that is, or thinking "well, I'm not really interested in planes".

Which would be kind of a shame, since I think the post has some nice points to make regardless of whether you're into the SR-71 Blackbird or planes; that's just the example chosen to paint the broader picture.

I quite like the sound of a theremin played well, but that particular example sounds out of tune to me too.

The comment in the other reply to the parent comment, as well as what I've heard of Carolina Eyck's playing, do sound pleasant to me though.