Eli Mellen12/29/2023, 12:54 AM
Jack Rusher12/29/2023, 2:17 PM
Eli Mellen12/29/2023, 3:19 PM
Jos Yule12/29/2023, 3:30 PM
Lu Wilson12/29/2023, 3:46 PM
Jack Rusher12/29/2023, 3:58 PM
programming, software engineering, and computer science are three different thingsYeah that is a good myth 😉
Personal Dynamic Media12/29/2023, 6:27 PM
Jason Morris12/30/2023, 9:30 AM
Josh Bleecher Snyder12/30/2023, 3:22 PM
Alex Cruise12/30/2023, 5:37 PM
Personal Dynamic Media12/30/2023, 5:59 PM
Alex Cruise12/30/2023, 6:36 PM
Marcel Weiher12/30/2023, 6:58 PM
Personal Dynamic Media12/30/2023, 11:13 PM
My favorite one of course was the one about the myth that programming is writing
procedures. The Gentle Tyranny of Call/Return one might call it
Oh it's not gentle! Tail calls enable entire architectures that are impossible when everything needs to be hierarchical.
Jason Morris12/30/2023, 11:50 PM
Personal Dynamic Media12/31/2023, 5:11 AM
Marcel Weiher12/31/2023, 7:57 AM
[The Gentle Tyranny of Call/Return] …is not gentle! Tail calls enable …Maybe I should have titled the paper “The Subtle Tyranny of Call/Return” instead? As in you are trapped by it even when you think you’ve escaped…
falsely generalizing her criticisms to all programming language researchers and implementers in all parts of history.I don’t think that is warranted. She is always clear that what she describes and criticizes is “typical”, not “all”. For example: “Traditional general-purpose programming languages, or at any rate the ones of most interest to programming language researchers…“. Next: “Mainstream languages are usually designed…“. And so on and so forth.
Personal Dynamic Media12/31/2023, 12:09 PM
Josh Bleecher Snyder12/31/2023, 5:28 PM
Konrad Hinsen01/04/2024, 8:12 AM
Eli Mellen01/06/2024, 5:33 PM
Lu Wilson01/07/2024, 9:01 AM
Konrad Hinsen01/07/2024, 10:05 AM
A general purpose language is, generally, these days, usually open source and outside the direct control of a specific company (laughs in Microsoft owning the entire stack, GitHub, npm, vs code, and type script) whereas a DSL or other sort of “less” powerful tool is typically bound up with a service subscription or licensing fee.Real programmers have agency over their tools. Second-class (vernacular) programmers have to live by the rules defined by (capitalism | real programmers). Interestingly, before Open Source, general purpose languages were already outside the direct control of a specific company, through standards bodies.
Eli Mellen01/07/2024, 1:49 PM
Konrad Hinsen01/07/2024, 7:51 PM
D. Schmudde01/17/2024, 7:44 AM
One aspect that takes a lot of room in the paper and in the episode is the PL research focus on correctness and mathematical rigor.The historical context is important. Partially because it directly impacts the vernacular programmer who comes to practice and starts wondering what’s the difference between a function, a method, and a procedure. The terms of art are directly situated in these (often long) historical contexts. I watched Shaw’s presentation at HOPL and I was surprised that she didn’t mention terminology as a barrier to tooling. Thus the podcast also didn’t discuss it. In my experience teaching, I can get pretty far with a REPL but the terminology creates immediate obstacles. The promise of associativity is a form of mathematical rigor that we all enjoy. But I’ve found folks grasping
well before they really understand why associativity is actually important.
At least mathematical rigor gives me (the teacher) a precise definition. But take the term function into the programming world and sometimes it means that I must always return one value, sometimes it means that can return multiple values, or sometimes it means I might return no values while modifying some other value in some other part of the system.
Beni Cherniavsky-Paskin01/31/2024, 8:06 AM
I didn't mean to say that individual real programmers have agency over their tools, only as a collective. In other words, software tools for real programmers are written by other real programmers. In contrast, spreadsheet users don't write spreadsheet engines. At best, they get a questionnaire for providing feedback.This gives me interesting perspective on Spreadsheets in Boxer paper 🤔 I first read it as deflecting the implicit criticism "spreadsheets' data-flow model is a proven road to give users computational agency; too bad Boxer doesn't include that" by showing "look, it's easy to build one inside Boxer, just write a re-compute loop doing
(p. 7) & if you really want attach a `modified-trigger`" (p. 18).
And I felt they completely missed the point.
There is a deep difference between having a language-level reactive model where you can just assume derived data will auto-update, vs. imperative model where you have to think about having to recompute, e.g. install
change cell.value tell cell formula
(and indeed the simplistic "spreadsheet" they built in the paper has limitations p. 18, single top-down left-to-right pass won't deal with other dependency orders...)
I still feel an ideal computational medium ought to support reactive behavior built-in.
But I guess I should re-read it because I see now they did not argue "being able to build it means we don't need it built-in". They merely used spreadsheets as a complex example to show off other strengths:
Writing a spreadsheet is not a toy problem, and yet in Boxer it becomes a reasonable exercise.and more relevantly here, their goal in building your own spreadsheet is not to so much to use one but to _understand what makes it tick_:
Boxer (1) supports a close connection between a conceptual model of a spreadsheets and a working implementation,
(2) provides a concrete, visible, working model that can be inspected, explored, and modified and
(3) eliminates distracting display and editing issues and concentrates cognitive load on the fundamental CS issuesHmm, I see now this is continuation of the SICP programme 😍 — that some core ideas in CS about structure & computation are worth learning, and that a great way to learn them is to understand and modify a substrate of computation. It's hardly realistic to teach school kids the later parts of SICP: how a LISP interpreter works and how to say tweak to support non-determinism with backtracking. Is is more realistic to show them how to build a (simplistic) spreadsheet, still teaching some great ideas about computation! 👏 With this goal, weaknesses like not cascading dependencies, not dealing with cycles etc. are not bugs — they are opportunity to do some "computational thinking"!
Konrad Hinsen01/31/2024, 9:13 AM
I still feel an ideal computational medium ought to support reactive behavior built-in.That question has been debated in the computational notebook community for years. Mostly among developers, much less among users, which often don't quite see the trade-off. Reactive behavior provides better feedback, but it's better only as long as update times remain reasonable. The question thus entangles UX, computational complexity, and hardware performance. It would help a lot if power-users-but-not-developers had a good understanding of these issues, if only for better communicating their preferences to the real programmers that wite their daily-use tools.