[TeMPOraL]

> except programming is difficult and akin to magic for most people.

So is cooking to quite many of them, myself included. I find programming easier than cooking - because although it takes much longer to achieve anything, it also doesn't cost anything on the margin, you can pause the process at any time, and you don't risk hurting or killing yourself.

> is usually achieved by having a program that takes a lot of configuration parameters and then does the job according to them

The ultimate form of "configuration parameters" is the code itself. Phrased alternatively, configuration is just code in a non-turing-complete language. Code is data is code.

There is a gap in tooling, there are currently no good Hypercard-like tools that would allow to make "personal software" and share it as recipes. That's perhaps because computing is still in its inflation phase and there's too much platform diversity; hopefully that will change in some way in the future. But lack of necessary tooling doesn't mean the vision is wrong, especially a vision that was true in the past.

[UncleMeat]

> There is a gap in tooling

Understatement of the century.

Professional software engineers often struggle to get their development environment up and running quickly. My wife is a historian and does a lot of work with R. The process of getting the development environment working and keeping it working was a nightmare. "What the fuck does that error message mean? When I Google it nothing comes up. What do you mean I have the wrong version of python? What the fuck is a PATH variable?"

With cooking there are entire stores dedicated to selling you things that you can use. Almost every home comes with a working "cooking environment". Even just making it so you could recompile some software if you wanted to is way way way way beyond the expected capabilities for a typical person, especially since a tremendous amount of OSS code is not portable and built for linux while most people have windows boxes.

[cxr]

Philip Guo wrote a great post several years ago under the title "Helping my students overcome command-line bullshittery"[1] that seemed to get somewhat mixed but mostly positive reception. Much of the negative reception seemed to be chained to sophomoric arguments originating from folks stuck in the second panel of the glowing brain meme who wrongly thought of Guo being stuck in the first.

The real truth behind the mess we're in[2] is that there is a ubiquitous, universal runtime that almost every computer comes equipped with, and the problem lies with the folks responsible for those ecosystems who either don't see these things as problems, or somehow believe that what the future somehow holds is native support for R/Python/what-have-you in the browser.

Tooling is a massive problem, though, and one that the browser vendors themselves don't seem to care to get right. (Although there is the Iodide project, in part supported by Mozilla.) And it really doesn't help that the browser realm has come to be conflated with the NodeJS community because they share a common language.

I've written a fairly thoughtful post[3] before, tying these two topics together:

> After finding out where to download the SDK and then doing exactly that, you might then spend anywhere from a few seconds or minutes to what might turn out to be a few days wrestling with it before it's set up for your use. [...]

> the question is whether it's possible to contrive a system (a term I'll use to loosely refer to something involving a language, an environment, and a set of practices) built around the core value that zero-cost setup is important

1. http://pgbovine.net/command-line-bullshittery.htm

2. https://www.youtube.com/watch?v=lKXe3HUG2l4

3. https://www.colbyrussell.com/2019/03/06/how-to-displace-java...