Hi all. I just finished listening to the episode, "Interpreting the Rule(s) of Code by Laurence Diver". I wasn't sure it was going to hook me, but am so glad it did. I had a few thoughts bounce around as I was listening, though dog-walking on a trail. Hopefully they make some sense now. Where Ivan was talking about the problem of a program only being able to handle conditions for which it was designed, with no escape hatch, I wondered about exposing something like the restarts that Common Lisp has in its REPL. This probably isn't something you would offer to a user that you didn't trust with a REPL, but perhaps encountering a problem could default to selections of alternate solutions that are offered to the user. When restarts are offered in CL, the program execution is paused, so the choices for the user have all the context of what is on the stack at the time. Rather than just aborting (which is one option), one might take an extra step back and try something different. Web checkouts typically have a weak form of this, but I thought that perhaps very binary conditional checks could often be replaced with "one of" or combinations of options. Don't have that right address? (RR 2, Pfff!). Include some other means of providing a location that is accepted. Maybe some form of fuzzy logic, albeit unfashionable these days, guides the programmer into accepting a combination of responses that satisfy their fraud-prevention algorithm when taken together. https://malisper.me/debugging-lisp-part-4-restarts/ Also, the whole concern makes me think of the eventual corporate destination, "Computer Says No" from Little Britain.

Glad you enjoyed the episode, and thanks for sharing these thoughts! One thought that I had meant to share in the show, but forgot to mention, is that there is actually one escape hatch available to us web developers — the browser dev tools! I'm sure we've all skipped a paywall or fixed a broken form by popping the hood and tweaking the HTML/CSS of some page. I'm not familiar enough with CL to follow the idea of "restarts" as you've described them. But I like the idea about fuzzy logic + allowing the user to specify data in a that satisfies some program in a format that works for the user. And yes — "Computer says no" — absolute classic!

I really should mess with the browser dev tools more; I am usually focused on back-end interactions, tormenting the services by proxying through Burp Suite and fiddling with the requests. On the CL side, that restart example looks at reading files with an invalid entry, and three basic options: skip the entry, skip the file, or provide some default value. A handler is added for each, and the caller can choose which one to use... or none of them, and call another handler function of its own choice. Choosing no handler, an interactive debugger gives the programmer the option to browse through the calling stack, look at local variables, and edit the definition of one of the functions in the chain. Sounds basic, except that it can be recompiled on the fly, and then the newly-edited function can be called again by restarting that stack frame, and continuing as if nothing had ever been wrong. I find this sort of thing very useful when it might be difficult to get to the specific state that triggered a condition. Maybe the browser debugger can do something similar?