Future of Coding History
A draft about my woes dealing with compiling a Rust + C codebase to WebAssembly: github.com/NicholasLYang/uptointerpretation/blob/master/content/posts/webassembly-woes.md
I’ve forked my Tofu experiment into a more production-ready subset, Soy! I’ll slowly expand its feature-set tofuwards:
We've had a bit of trouble communicating the flexibility of Clerk, so I'm very happy to see this short talk from my colleague Philippa Markovics talking about many use cases that aren't anything like one might expect from a Jupyter-style notebook:
Nice demos! What I like in particular, and wasn't aware of, is the nice migration path from local experiments to publishing a Web site. From the demo, I cannot judge how much effort (and learning curve) this implies, but the possibility alone is something hard to find these days.
Future of Coding • Episode 61
Peter Naur • Programming as Theory Building
:heart_hands: futureofcoding.org/episodes/061
What a bop! This paper offers a compelling explanation for many of the difficulties we encounter when maintaining large, long-lived programs. It makes us question the value of source code notation, commenting, documentation, and other artifacts of the programming activity, especially when it comes to communicating the ideas behind a program between different people working on it. When we work on our FoC projects, are we even understanding the right misunderstandings of our understandings? To make sense of that nonsense, we turn to the master of terrible bulls#$% (Ivan's take, not Jimmy's) — Gilbert Ryle!
Next month, we're honouring the recently-deceased Fred Brooks by dancing on (or, perhaps, with) Mythical Man-Month and No Silver Bullet.
I just started the download. I can't wait to have time to listen!
This was a great listen, and I think it's your best episode since the reboot. I've seen this paper and its thesis mangled many times and I think you both did a good job of putting in the work to understand it and find ways to explain it.
My boring response to Ivan's question about why one would treat a theory as a single object is that it is easier to talk about that way to try and explain the concept to someone who hasn't heard it before, much like all of the weightless massless pulleys one encounters in a physics class.
As usual, the best parts are those where you are working to understand and/or explain the author's intent and the worst parts are those where you criticize the author. Nobody's perfect, but very few of us who study the very best works of the brightest minds in our field will be qualified to distinguish the difference between an error and a point that we do not understand. Your discussions are both more enlightening and more respectable when you approach these masters from the perspective of students, rather than critics.
Im curious how the use of programming paradigms relates to theory building. Paradigms (particularly the combination of them) seem to be part of the foundation in which we build more domain-specific theories off of. 🤔
Christopher Shank I think that's a good example of Ivan's point about the theory of a program not being a single object, but rather an amorpheus and growing mass, assuming I understand him correctly.
I would speculate that the theory of any given program incorporates within it to varying degrees some portion of the theory of the associated language, paradigms, operating system, operating environment, and to whatever extent the program maps to objects in the real world, the theory of manipulating those real-world objects.
There was recently a great blog post linked to on Hacker News about the problems with on-demand learning. jernesto.com/articles/learning.html
One problem that I did not see addressed in that article is that if you just look up answers for specific needs, you will not tend to develop a theory of how to apply the language, libraries, paradigms etc. that you are using, and to borrow a phrase from Brooks that I'm sure we will hear in the next episode, without possessing your own theory your code is unlikely to possess conceptual integrity.