rauhl

The spec’s at https://www.superlogical.com/rex/docs/build/program-status

Have you seen Common Lisp’s condition system? It’s a step above exceptions, because one can signal a condition in low-level code, handle it in high-level code and then resume back at the lower level, or anywhere in between which has established a restart.

https://gigamonkeys.com/book/beyond-exception-handling-condi... is a nice introduction; https://news.ycombinator.com/item?id=24867548 points to a great book about it. I believe that Smalltalk ended up using a similar system, too.

> It would need to be the case that code that doesn’t want to handle errors (like Max’s simple website) doesn’t have any error handling code, but it’s easy to add, and common patterns (e.g. “retry this inner operation N times, maybe with back off and jitter, and then fail this outer operation, either exiting the program or leaving unaffected parts running”) are easy to express

Lisp’s condition system can handle that! Here’s a dumb function which signals a continuable error when i ≤ 3:

    (defun foo ()
      (loop for i from 0
            do (if (> i 3)
                   (return (format nil "good i: ~d" i))
                   (cerror "Keep going." "~d is too low" i))))

If one runs (foo) by hand then i starts at 0 and FOO signals an error; the debugger will include the option to continue, then i is 1 and FOO signals another error and one may choose to continue. That’s good for interactive use, but kind of a pain in a program. Fortunately, there are ways to retry, and to even ignore errors completely.

If one wishes to retry up to six times, one can bind a handler which invokes the CONTINUE restart:

    (let ((j 0))
      (handler-bind ((error #'(lambda (c)
           (declare (ignore c))
           ;; only retry six times
           (unless (> (incf j) 6)
             (invoke-restart 'continue)))))
        (foo)))

If one wants to ignore errors, then (ignore-errors (foo)) will run and handle the error by returning two values: NIL and the first error.

> The unattended workaround is to have the tmux daemon spawn at login via `start-server` + enable some tmux settings like `exit-empty` plus some I can't recall regarding environment handling, but nobody does that.

I just have my terminal emulator spin up tmux when it starts, and I start my terminal emulator from my desktop, so it always runs in a clean environment.

> Ctrl+a from my cold dead fingers

That conflicts with the standard Emacs binding to move to the beginning of the current line. Many years ago, I switched to C-z instead, on the theory that it is really easy to type C-z C-z when I really want to suspend whatever is currently running.

Pity that (AFAICT) terminals have no concept of Super and Hyper (USB doesn’t know about Hyper, either, but at least X11 does).

> But it solves a really important problem: How to exchange markdown documents that include attachments like images, video etc. in a standard way?

Oddly enough, I was recently thinking of using RFC 822 messages with CommonMark bodies and MIME attachments as a way to store blog entries on disk, so I was considering this exact problem earlier this week (small world!). RFC 2046 specifies multipart messages, RFC 2392 specifies URI schemes for linking from the body of the message to other parts; and RFC 7763 specifies the text/markdown MIME type. There’s already a ton of tooling out there which deals with MIME, so one needn’t reinvent the wheel.

Really neat! It runs on the DM42 calculator from SwissMicros (no relationship other than being a happy customer): https://www.swissmicros.com/product/dm42

That’s a minor thing I dig about Lisps: variables can be named foo-bar-baz, with nary a shift to type.

I forget where I first saw it, but I’ve been persuaded that the correct word is ‘confabulation,’ not ‘hallucination.’

Maybe it was this paper: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10619792/

The authors’ statement that ‘unlike hallucinations, confabulations are not perceived experiences but instead mistaken reconstructions of information which are influenced by existing knowledge, experiences, expectations, and context’ is pretty compelling.

I think that it is. The article does raise some good points to consider, but at this point in my experience with it I believe that a lot of the complexity of Kubernetes is not something it introduces but rather something it exposes: it was already there, just maybe not explicitly. Likewise with a lot of the operational costs and so forth.

OTOH, I do think that now that it has shown the way, there is room for both improvement and replacement.

A door. No Internet-connected camera. No doorbell. Not even a knocker. Just a door. No batteries. No hype cycle. No upgrades. No WiFi. Just a door. When someone is at the door, he knocks with his knuckles. It works. We’ll probably get a knocker at some point, but we don’t need one.

Mechanical watches. I came very close to getting into so-called ‘smart’ watches awhile back, but decided that would have been a pretty foolish waste of my money. Quartz would be more accurate, of course, but I like the sweeping hands and the clockwork.

The modern version would be https://www.omniglot.com/, which has tons of real and constructed writing systems. It’s a reminder of when the Web was a bunch of neat people sharing neat things.

No affiliation with it, just been happily reading and sharing it for years.

> I conjectured that it's Kubernetes. Just like XML, Kubernetes solves a problem, but it doesn't solve EVERY problem.

Like XML, Kubernetes does a lot of cool things which were not common before it came around (unlike XML, I think K8s actually manages to improve on the state of the art a bit, too). But just as XML was largely replaced by JSON, I am really excited to see what replaces Kubernetes.

Then the user is stuck with the macOS UI and macOS software.

I have a very custom desktop UI based on a tiling window manager (WM); I tend to run it with one or two windows per screen, so that I can focus. I have a suite of synchronised colour schemes between the WM, my editor, my browser (with custom styles for commonly-used sites), my terminal, my PDF reader and my screen locker, so I see one unified colour theme across everything I do on a computer (with separate themes for work and personal computers, so I instantly know what context I am in). I have as few distractions as possible from the work I am doing. I have a fairly consistent set of keybindings across my environment, with custom keybindings for custom work.

Since it’s written in Common Lisp, I can dynamically reprogram my WM as it runs. What I mean is that I can connect to it from my editor and open a REPL; I can define, replace and debug live code in the running instance. It’s not quite as powerful as a real Lisp machine would be, but it’s better than any other desktop environment I’m aware of.

My Compose key setup is much more powerful than macOS’s Option key. I have a pair of true Hyper keys dedicated specifically to my own cross-application tooling, unused by any specific program.

I believe that switching to macOS, Windows, GNOME, KDE or any other setup would be a step back, or at the very least require a significant investment of time and effort to begin to approach parity.

Then there is the issue of freedom. Just about every line of code I run is free software, which I may inspect, learn from, debug and change. It’s not there to make Apple more money.

Then there is the issue of privacy. Apple claim to care about privacy, but with free software I can actually examine code to see if it does anything I don’t want it to do, and I can hire someone to do that for me, or rely on others I trust who have done that. You can’t do that with proprietary software.

The developers of GNU/Linux and the other software are more aligned with my own interests, wants, needs and desires than the developers of macOS are. It’s not perfect alignment, of course (Mozilla is a good example where improvement really is needed, as are the systemd developers), but on the whole the free software community are reasonably well-aligned with me.

I care about privacy, freedom, customisation and productivity. When I use my system, it does what I want it to do and nothing (or at least very little …) else. It gets out of my way and enables me to be effective in my job and in my computer-based hobbies, and gets out of my way so that I have time for my non-computer-based hobbies and the rest of my life.

GNU/Linux and other free software afford me much more privacy, freedom, customisation and ultimately productivity than does macOS.

Pretty neat! I see that you’re using Hunchentoot — are you concerned that it interns HTTP header names in the KEYWORD package? It means that a malicious client can use up all your RAM by submitting requests with random header names.

> Good to see that the good old "laptop doesn't go to sleep on linux" problem has never truly gone away.

FWIW, I have a spare Windows laptop, just over a year old, whose WiFi does not recover upon waking from sleep about eleven times out of a dozen.

OTOH, I have had both Windows and Linux laptops which have gotten uncomfortably warm when ‘asleep.’ And right now I have a Linux laptop which very rarely hangs on sleep and turns into space heater, not even turning off the monitor but becoming completely unresponsive.

Sleep is apparently a lot trickier a feature than it looks.

Weird, I submitted the exact same link yesterday and the dupe detector didn’t trigger: https://news.ycombinator.com/item?id=32477938

No worries, it’s a great article and I’m glad folks are reading it!

This comment from a few days suggests implementing ed: https://news.ycombinator.com/item?id=32015912

That strikes me as an excellent idea: it’s a pretty small tool, but it is useful and has just enough complexity to test the language and its standard library. Note, however, that I have not done so myself!

This is a great example of why Emacs is so powerful: the activation energy to go from ‘gosh, that sounds neat’ to ‘cool, I implemented that’ is so incredibly low.

> Also knowing that the thing will last forever, take care of it and it will probably outlive you. Can't say that about an Apple Watch.

I don’t know how many mechanical watches really will last a lifetime, but they will easily last longer than a so-called ‘smart’ watch.

Six years ago I seriously considered purchasing a ‘smart’ watch. Eventually I realised that they were just another money sink and attention leash, and put the money into a couple of automatic watches instead. I still have them, and wear them regularly. Had I bought an Apple or Android watch, I would have replaced it multiple times by now.

That’s the plus side. The minus side is that I don’t wear one of those two every single day because … I gotten bitten by the watch bug, and now I have a pile of other watches, and I wear those too! I still think that I am ahead of the game, though.

BTW, I write ‘smart’ watch because I don’t think they are really that smart; if anything, they should be called unwise watches, because they are an unwise expenditure of resources, money and attention. Also they just don’t look good. I predict that in thirty years we’ll look back on them much as we do digital watches: as a fad.

> accidentally coding Bubble Sort with no prior knowledge of algorithms

Heh, I did that when I was a kid. I was so proud of myself, right up until I learned how bad it was.

If only there were some way for the tech world at large to learn that sort of lesson.

Heh, I did that with Emacs! It already has sunrise & sunset, so the rest of the math was easy.

Excel & Emacs: two things starting with E which let anybody program anything.

> I consider being unable to post or even read comments to be a major functional breakdown.

For a blog? I disagree, because the point of a blog is to read the author’s comments, not those of third parties.

> Comments are non-interactive text, there's no justifiable reason why I should need JS to read them.

I kinda agree. The issue is that it is very rare to find a static site generator which can interface with a dynamic comment storage. To be honest, I don’t know that one exists, although of course it is completely possible. I can understand as a pragmatic matter why someone might have a static blog, want to add comments and not be willing to run his own dynamic comment system, esp. if that would entail writing said system.

All that being written, it would be awesome to have a static site generator which were called by a hook in a dynamic comment server. I actually would like to write one someday!

Modern Tcl may be big, but it is not too big to embed. I know, because I embedded it into a Go system at a previous employer. Unfortunately, it is proprietary, so I may not point you to the repo, but it required remarkably little glue code.

I also evaluated Python and Lua. As others have noted, Python appears to be a right royal pain to embed. I actually had more experience with Lua prior to that project, but that experience leads me to believe that Lua is, generally, the wrong language.

Looking back on the project, I would not hesitate to do the same thing again, ideally as open source so that other Go projects can embed a scripting language. It got the job done, and did it well. Non-programmers on our team were able to write both configuration and logic successfully & productively, and apparently enjoyed the experience. Tcl itself ended up being a pleasure to use. While I personally would have enjoyed something like Embeddable Common Lisp, I think that would have been to much to ask of the rest of the team.

Interestingly, the four languages Lua, Python, Tcl and Lisp each can be said to take one idea and run with it. Lua is everything-is-a-hash-table (well, almost everything); Python is everything-is-an-object; Tcl is everything-is-a-string; and Lisp is everything-is-a-list (well, in theory: in practice it is really everything-is-an-object). I don’t know if this says anything deep about scripting languages, but it is at least interesting — right?

> That doesn't apply to web applications, which of course use JavaScript heavily

I propose that rather than ‘Web applications’ these be called ‘browser applications,’ because they are applications that run within the browser runtime. It is basically a coincidence (and a convenience) that they happen to rely on the same technology used for the Web.

What I don’t understand is why folks write browser applications for things that the Web platform already handles well. The Web is pretty cool! Not perfect, but then nothing is.

As others indicated, CASE was more about code generation rather than smart IDEs. My recollection from the time is that the industry really strongly believed that almost no-one would write actual textual lines of codes and that graphical programming was going to be where it was at.

Looking back, it’s a remarkable delusion: mankind went from pictures to pictograms to text, not in the reverse. The career path everyone expected (mentioned elsethread: go from a junior guy-who-writes-lines to an architect guy-who-draws-pictures) doesn’t really make sense. If anything, while a high-level architectural document needs to have some diagrams, even more than that it needs to have text: text to describe the problem being solved, the context, the potential solutions and the reasons to choose one solution over the rest. Likewise, it’s striking how many PowerPoint slides could be effectively replaced with short point papers … but that’s a discussion for another time.

I am not 100% sure of why the industry had this wrong-headed idea, as I was too young at one point in time and too junior at another to really have good context. Maybe it was the rise of GUIs which led folks to think, ‘gosh, if pictures can enable folks to use a computer easily, then they will enable folks to program a computer easily!’ Or maybe it was the unfortunate habit non-experts have of not really understanding an expert’s field. As I recall, it also had a very strong correlation with the rise of OOP.

> The difference between this and a full lisp like Clojure is that this must be turing-incomplete.

Sure, but one could still implement a Turin-incomplete language in S-expressions. It would be more readable and more succinct, too.

> Can you think of another way to do this that doesn't rely on using JsonLogic or something like it (or a cleaner method for doing it in JSON)?

This strikes me as nice:

    (parsing-matrix
     (if (or (= (var "credentialData" "rapidSarsCov2PCRTest" "testResult") "negative")
             (= (var "credentialData" "covid19Vaccination" "hasVaccination") "negative"))
         "valid"
         "invalid"))

> Does the Common Lisp standard need to be revamped?

Probably. It has been nearly twenty years after all!

> I remember seeing stuff about CL21 a while back...

That was mostly one guy’s thoughts, and didn’t meet with universal approval.

Here are this guy’s thoughts:

- Retain case sensitivity. Remove case-folding. Use lower-case for all symbols in the common-lisp package. Basically, Allegro’s modern mode is the right mode.

- Improve, don’t eliminate, pathnames. Standardise their semantics for Unix and Unix-like systems. Bonus points to integrate URLs and pathnames, although … that way may lie madness.

- Expand the standard. In 1994 Common Lisp was derided for being a huge language, but compared to languages like Go or Python the library portion of the standard is pretty small. It is probably time to add some TCP & UDP primitives. It is time to settle on some concurrency primitives. And then there are the higher-level things 21st-century programmers take for granted: HTTP clients and servers, Base64, that sort of thing. Maybe specify them in separate optional packages for smaller environments?

- Consider CLOSing all the things. Caution: this could be a terrifically bad idea, but …

- Consider breaking backward compatibility and settling on one argument order to rule them all. (nth 1 list) and (elt list 1) is a wart. Switching to lower-case raises the possibility of retaining the entire COMMON-LISP package for backwards compatibility here …

Improvements are awesome! That’s why I linked to the text/enriched RFC. I really wonder if anyone who downvoted actually read it, or just emotionally reacted.

I don’t think that HTML emails are really an improvement: full-fledged HTML engines bring in too many opportunities for exploits and privacy loss. They definitely add capability, but at too high a cost IMHO.

In general, I think that our industry would benefit from asking ‘can we?’ less and instead asking ‘ought we?’ more.

> I caved in and replaced mutt with Thunderbird personally. Not only for properly displaying HTML, but it was a big reason. Thunderbird sucks massively for composing plain text emails though, and no simple way to integrate an external editor...

Have you considered emacs with notmuch and the Gnus renderer? It displays most HTML emails well, and when it doesn’t then a browser is just a quick ‘. b’ away. And of course there’s no need to integrate an external editor, because it’s integrated within the editor!

As a plus, it is simply amazing how quickly one can search local email.