47 minutes till the 6th online-lisp-meet with:
⭐️Jan Moringen about the new McCLIM inspector
⭐️ Hayley Patton about Netfarm, a distributed trustless object system
All the details:
Thanks to @phoe for organising! 🎉🦎
Earth has blue skies and red sunsets. Mars has red skies and blue sunsets.
The sky on Earth is blue because gas molecules reflect blue light. Earth sunsets look red because all the blue light has already been filtered out.
The sky on Mars is red because dust particles reflect red light. Martian sunsets look blue because all the red light has already been filtered out.
Two planets. Opposite skies.
Playing with MCM/70 emulator from http://www.cs.yorku.ca/museum/collections/MCM/MCM.htm
Just wondering how many people would like to watch a stream with someone taking baby stems in #APL on that amazing machine
Next Tuesday at 13:00 CEST online-lisp-meets with
⭐️ Jan Moringen about the new and improved version of Clouseau, the McCLIM inspector facility
⭐️ Hayley Patton about ideas from developing the Netfarm distributed object system in common-lisp (concurrency)
links, titles, and abstracts: https://reddit.com/r/lisp/comments/i05dr1/online_lisp_meeting_6/
Thanks to @phoe for organising this wonderful series!
comp.lang.lisp has been banned from Google Groups, reports lwn: Historical programming-language groups disappearing from Google https://lwn.net/Articles/827233/
@enkiv2 I don't think so. The condition system has nothing to do with backtracking, I guess, aside from the fact that it can be used to implement an inefficient form of backtracking - see https://gist.github.com/nikodemus/b461ab9146a3397dd93e
@ioa Seems like a lot of inertia. The throw-and-destroy-the-stack approach is prominent almost everywhere in the programming world.
I don't know much about Dylan, but Smalltalk and CL are image-based programming languages that simply bundle everything required to debug on the spot - the debugger, inspector, compiler et al. Some other languages don't have these facilities in the output binaries.
There'll be a free supplement to my upcoming book that touches this topic a little bit.
Showing why conditions are a bad match for doing backtracking -- all you need is CATCH/THROW and a special variable. · GitHub https://gist.github.com/nikodemus/b461ab9146a3397dd93e
"Why companies struggle with recalcitrant IT" https://www.economist.com/business/2020/07/18/why-companies-struggle-with-recalcitrant-it
"Airlines are […] now advised to turn the plane off and on again every 51 days, to stop its computers displaying false data in mid-flight."
Love our glorious computerized future
@phoe @firstname.lastname@example.org 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.
@fnark @email@example.com 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.
logician programmer - lisper - igalian working on compilers (c++) and webassembly
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!