"The Common Lisp Condition System" wouldn't have been possible to create without help of TONS of people from the programming community.
The Hall of Fame chapter of the book is really massive and full of people - just take a look at https://plaster.tymoon.eu/view/1949#1949
@phoe @email@example.com Kudos! I read about the book yesterday on Hacker News, I didn't realize it was you!
@mdallastella @firstname.lastname@example.org well, now you do!
@phoe @email@example.com neat, I see my name there. Now I really have to buy the book. 😂
Not that I wouldn't have done it anyway.
@fnark @firstname.lastname@example.org Two reasons.
If one is a Lisp programmer, then it's fundamental to understand the functioning and use cases of the standard language facilities, such as the condition system in this case, in order to understand code written by other people and to know when and how to use the condition system in one's own code.
If one isn't a Lisp programmer, then I think it would be worth to give this book a read in order to understand an approach to handling exceptional (and not only exceptional) situations that does not require immediate stack unwinding on each erroring point in code, offers a possibility to dynamically add condition handling and recovery logic completely from outside a given program, and finally presents a combination of debugger-inspector-compiler built into the language to help fix issues on the spot in an interactive maner.
@phoe @email@example.com One interesting thing when reading comments from non-Lispers when they hear about how the condition system works.
In almost all cases, it boils down to some variation of "I can do that in X as well, just use facility Y to emulate it".
For some reason they are perfectly happy to apply this "because of Turing-completeness, all programming languages are equivalent" to this topic, while at the same time explain how superior some specific language is just because it allows you to type one word less than some other language.
The main issue that makes writing examples for this troublesome is the curse of knowledge. If I write that a condition system allows to recover from a type error, it's trivial to say, "just add a typecheck for that with a conversion routine"; if I write that a condition system allows you to recover from the format mismatch, it's trivial to say "but you can just stick an ifIsOldFormat(...) in the code to solve it". These solutions are no longer about exception handling; they are modifications to the standard control flow of the program. They aren't trying to fix the situation from outside; they are trying to fix the situation from the inside. And fixing it from inside isn't always viable or even possible at all.
While control flow deals with known knowns and known unknowns, exception handling is much more about situations where we deal with unknown unknowns: something explodes, we don't know what it is, none of our programmed recovery mechanisms have taken care of that situation, and we need means of gracefully recovering.
This is achieved first and foremost by allowing human intervention: the debugger is started, the stack information is preserved, so a programmer has all the information to try and debug the situation to let the program continue execution. Some of these fixes can then be easily added to code in by means of defining new programmatic condition handlers (hooks) and restarts (choices) in code.
@loke @firstname.lastname@example.org Also, another answer is, "of course that you can, the thing is that you don't. That's why you miss out on the fun."
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!