Finally, a title with appropriate length given the duration and depth of its episode. May it swiftly be surpassed.
Alexander Repenning created AgentSheets, an environment to help kids develop computational thinking skills. It wrapped an unusual computational model with an even more unusual user interface. The result was divisive. It inspired so many other projects, whilst being rejected at every turn and failing to catch on the way Scratch later did. So in 2017, Repenning published this obit of a paper, Moving Beyond Syntax: Lessons from 20 Years of Blocks Programming in AgentSheets, which covers his findings over the years as AgentSheets evolved and transformed, and gives perspective on block-based programming, programming-by-example, agents / rule / rewrite systems, automata, and more.
This is probably the most “normal” episode we’ve done in a while — we stay close to the text and un-clam many a thought-tickling pearl. I’m saying that sincerely now to throw you off our scent the next time we get totally lost in the weeds. I hear a clock ticking.
I haven't listened to the show yet, but in the notes I see "Also couldn't find a good link for TORTIS. :/"
Is this the TORTIS from the Logo project? If so, you can find two papers about it at el.media.mit.edu/logo-foundation/resources/mit_logo_memos.html
Just from reading the description, I'm amazed I've never heard of it before, either here or elsewhere. Looks like it's come up just once here: akkartik.name/archives/foc/thinking-together/1571241687.398100.html#1571296934.435900
I loved y’all’s conversation around computational thinking and programming (active).
This is something I think about a lot in the context of array programming, especially APL and BQN. In a lot of ways the experience of programming with APL is similar to using Scratch, where you are combining and recombining a core set of well known pieces to build up to a desired effect, many times you have to build to an output you don’t really actually want, and then have sort of a clean up pass that filters a thing down to what you need.
I like APL because it feels like a billion million miles away from the computer. I thinking about it all as sort of transform rules to apply to data.
I wonder if a tripping stone for scratch and the things described in the paper is that they mimic too closely things that make you think about the computer while pretending to be obscuring that away, like they need to go harder in one direction or another?
Well, my FoC project is Blawx, which is a block-based version of a stable model open world constraint logic programming language. It is targeted at representing statutory "language", which has its own rules of interpretation, and so Blawx is using a block interface to support a legal semantics and a logical syntax. It is also designed with explanations for query answers that make the semantics of the execution more visible in the output (not using blocks, but still aimed at semantic "support"). Then, I'm working on different UIs that are designed to facilitate reasoning over imperfect information, so that you can ask questions like "in this hypothetical fact situation, is this additional fact relevant to answering this question, and if so, how?" Which seems like it may be an example of what the author calls pragmatics. Maybe not as directly targeted "for Jason" as the Driver paper, but still... eerily relevant.
I'm struggling with the definition of pragmatics, honestly. It feels like semantic support through the semantics-by-example seen in debugging tools.
The cognitive/affective challenge for lawyers of computational thinking about statutes is also the whole reason for Blawx to exist. So I relate to the author's motivations pretty severely.
I also struggle with an argument about whether lawyers want to "learn to code," and whether it is helpful to call using Blawx "programming" for the purpose of solving the cognitive/affective challenge, regardless of whether it is accurate. Both because programming is "scary", and because most people's experience of programming is dramatically different from logic programming knowledge representation.
I think that computational thinking is basically just an example of formalisms more generally. Attempting to apply a good formalism to your ideas will draw your attention to things that you might not otherwise consider. That has been enormously, dramatically useful to me in my attempts to understand laws. I regularly argue that Blawx will make you a better statutory drafter or client of a statutory drafter, even if no one ever runs the code. But I think it may be difficult for people who are not, like me, on both the law and coding sides of things, to recognize how fundamentally not-computational legal thinking is now, and how large and juicy the low-hanging fruit are.