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).
> 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.
> 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.
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.