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.
> 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.
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).
Our finger memory for ^a is now ^a-a. In all apps, everywhere. Mostly that just results in something like select-all+select-all, but occasionally it's awful
> 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.
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.
Automatic mechanical watches don't get enough hype. They're examples of incredible engineering. Somebody shrunk a grandfather clock down so it could fit in a pocket, then someone else not only shrunk it down further, but made it so _the damn thing wound itself!_
They are examples of understandable engineering. A modern smartwatch is orders of magnitude more complicated and impressive but people can’t intuitively grok how they work like you can with a mechanical watch.
Even a basic digital watch like a Casio F91W is a much more impressive feat of engineering than the most expensive mechanical watches.
There may be some truth in this. I have basic understanding software and hardware. I was (and still am!) impressed at how my Amstrad drew graphics on the screen, but am considerably less impressed by the much more complicated graphics we have today.
Though this is likely partially as you said — a degree of separation by understanding — it's also because it's not all "one piece". Many different people in many different teams, departments, countries, are necessary to create something like a smartwatch. None of them can do it alone, and that has something to do with it for me.
But how will a VC make money off your "door" ?? Isn't that the purpose of modern technology: lock-in, enshittification and subscription fees? I would go so far as to say your stingy insistence of not giving money to one of my portfolio firms brands you as decidedly anti-american.
</snark>
Though there are times I think my co-workers do think like that.
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.
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:
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:
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.