Future of Coding History
I found myself explaining how bare CPU hardware works and waving my hands in front of the camera, at this week's online Torlisp meeting. Later, I drew the pictures in draw.io and created a Keynote (Apple's version of Powerpoint) slide deck. FWIW, here it is (with some AI for generating the narrator's voice): youtube.com/watch?v=_RSOHszYP1g
Future of Coding • Episode 75
A Case for Feminism in Programming Language Design
In the academic field of programming language research, there are a few prestigious conferences that you must present at to advance in your career. These conferences are rather selective about which presentations they’ll accept. If your research work involves proving formal properties about a programming language, you’ll have their ear. But if your work looks at, say, the human factors of language design, you might as well not bother applying — and thus, not bother pursuing that work in the first place. Why is the formalistic, systems-focused work elevated, and the human-focused work diminished? And what are the downstream consequences, the self-reinforcing feedback loops that come from this narrow focus?
In this episode we discuss a paper by Felienne Hermans and Ari Schlesinger titled, A case for Feminism in Programming Language Design. It applies the lens of intersectional feminism to reveal a startling lack of “Yes, and…” in academic computer science, where valuable avenues of inquiry are closed off, careers are stifled, and people are unintentionally driven away from contributing to the field, simply because their passions and expertise don’t conform to a set of invisible expectations. Through heartbreaking personal anecdotes and extensive supporting references, the paper makes the case that there’s a lot of high-value greenfield work to be done, and people who would love to do it — but we will need to collectively identify, understand, and then fix a few broken incentives before it’ll happen.
Functioncharts are a new kind of diagram for programs, with the audacious goal of being as expressive as any textual programming languages. It supports creating abstractions, and first-class iteration and recursion. The first version of this diagram is for a Javascript-like language, but it could be adapted for others (WebAssembly?) It was inspired by and borrows ideas from the Statechart formalism.
This editor project started as a specialized drawing tool to allow me to explain the ideas. But I found that trying to build actual programs was the only way to find out what worked and what didn't. The GitHub pages are the documentation for now. The editor is usable but unstable. There is no code generation or iterpreter yet.
github.com/billbudge/WebEditorFramework/tree/main/examples/functioncharts
Read the doc first. You can try the editor at this link (warning, it is a buggy prototype)
billbudge.github.io/WebEditorFramework/examples/functioncharts
As a warm-up for this project, I also developed a Statechart editor.
github.com/billbudge/WebEditorFramework/tree/main/examples/statecharts
