I'm getting more and more into a new… idea? Let's see if I can explain it.
- There are programs, like photoshop, that are tools for artists. You can use them to make art. They're a digital equivalent of traditional art tools. The fact that they're digital has, just to give one example, enabled artists to easily do some things that used to be really hard. This has, in turn, changed the sort of art that gets made.
- There are programs, like flash, that are tools for ___ to make tools for artists. (I'm leaving a blank there because… I could have said "programmers", but I actually want you to not think of them as programmers for a sec. Just go with me.) For example, in the late 00s, I worked as a __ making tools for artists, and I used flash to do this, because it gave me a programming environment that was designed in tandem with a drawing environment. Really nice fit here. But flash wasn't really designed for people to make tools for artists. It was designed to be a tool for artists, but it was also programmable, which made it a good tool for making tools for artists.
- There are —————, that are tools for making tools for __ to make tools for artists. (I'm adding another blank. I could have said "programming languages", but I actually want you to not think of these —————s as programming languages for a sec. Just go with me.) For example, going to school, or reading books, or a good night's sleep, or taking a shower, or having a stimulating conversation with a friend. These are all —————, but they're outside the computer.
Just as the computer allowed artists to have a new kind of tool that changed the sort of art that got made, I'm interested in how the computer might give us new kinds of ——————, which would in turn make new kinds of _.
It's possible that FoC as a community is a —————. But I also think there's ————— software that's not a programming language.
I'm resisting the urge to…
- Photoshop: tool
- Artist: tool user
- Flash: tool and meta-tool (ie tool for making tools)
- _: meta-tool user, tool-maker
- ————: meta-meta tool (tool for making tools for making tools)
If any of us here make tools, then whatever tools we're using are meta-tools.
Who makes those? What do they use?
What could be done to make them better?
It feels so sniffing one's own farts to put the word "meta" twice in a row.
But it's not uncommon for us to talk about second-order effects, or look at consequences several steps downstream from some cause.
I once heard someone say that thinking about thinking about thinking about thinking is just thinking about thinking. You only need one level of meta to capture all of it.
In a similar sense, it might be possible to say that tools for making tools for making tools for making tools are really just tools for making tools.
I don't know if this idea simplifies or complicates your line of reasoning, but there it is in case you find it useful.
Yeah, that makes sense. But it's also glossing over the details, and the details are what I'm mostly thinking about. Like, what can we do with the computer as a dynamic medium, ~other than programming~ , to make tools for making tools better? Well, some of it probably doesn't depend on what kind of end-tools they are — project planning, remote work, open source, undo/redo, VCS, data vis are all broadly helpful. But what could we do if we had a more specific sense of what this end-tools were meant to be?
Eg: I look at the influence of game dev on the design of graphics cards. People who made game engines (tools for making games) worked with people who made graphics card APIs (tools for making tools) to make those APIs gradually more flexible. We went from fixed-function hardware to high level APIs to low level APIs.
I wonder how this might have gone differently if game design (the discipline concerned with the dynamic / interactive part of games) had been the more demanding of technological brute force, rather than graphics (the discipline concerned with emulating light)
The concept of self hosting might be relevant here. A tool powerful enough to implement a copy of itself is probably powerful enough to implement anything a computer can do.
Traditionally this means writing the compiler for a language in that language, but I'm not sure what self hosting would look like for a higher level tool, like Photoshop or Flash.
I'm also not sure what to call creating and manipulating dynamic behavior other than programming.
Good thoughts. It's hard for me to express, but I'll keep trying. I'm not interested in doing "anything". I'm interested in something very specific — I just want to find, like, one such thing. I just don't know what it is. I'm defining it by counterexample. I know that it fits in a coding-shaped hole. But it's not coding. It still uses the capability of the computer.
Before we had Photoshop, you could do coding to achieve similar goals. Before we had Flash (HyperCard, Dreamweaver, etc), you could do coding to achieve similar goals. Before we had Maya, or AutoCAD, Sketchpad, or other tools for visually expressing constraints, you could do coding to achieve similar goals. (I switched from saying "programming" to saying "coding" because Photoshop, flash, maya, etc are all still ~programming~ , they just quite different from status quo ~coding~ ).
We don't have ————, so you can do coding to achieve similar goals. In this case, the goal is making the next Flash, Maya, HyperCard, spreadsheet, desktop metaphor, etc (to the extent that making those involves coding. It also involves invention, but I see that part as essential and the coding as accidental)
Coding is a slightly more general way to do ————. So I want a subset of what coding does, specialized to a specific activity.
Ivan Reese I have been thinking along similar lines for a while, except that my target audience is not artists but scientists. But I only made progress once I enlarged focus from tools (at whatever meta-level) to the people using the tools, to the activities of those people, and to the knowledge embedded in the tools.
One conclusion from that perspective is that the number of meta-levels in tooling should be the same as the number of meta-levels in people's specializations (Conway's law). Which may of course evolve over time. In particular, new technologies/tools can lead to a new meta-level of specialization. That may or may not be a good thing. Specialization leads to higher complexity in social structures, increasing efficiency but reducing resilience and autonomy. Do artists value more new tools to have fun with more or less than tools that they can control and shape themselves? I don't know.
I conclude that computers are a new medium and that we need artists to explore new ways to create new things with the new medium. guitarvydas.github.io/2024/02/11/Computers-Are-A-New-Medium.html. Scientists could use the new medium to explore the things they think about, instead of remaining stuck with the old medium. I've seen someone do a very technical thing with Blender that is impractical to do with paper and pencil.
Various thoughts on making programming simpler, and, breaking programming down into several disciplines: Architecture, Engineering, Implementation. Concurrency is not parallelism and concurrency is not multitasking.
I wonder how this might have gone differently if game design (the discipline concerned with the dynamic / interactive part of games) had been the more demanding of technological brute force,
The medium as the message, baby!
Would another way to pose this same question be like:
- Do the tools we use to build new tools influence what we can produce?
Which could be maybe further made into:
- Do the tools we use to build new tools limit what we can produce?
This has me thinking about the distance (relationships?) between tools, meta tools, and meta meta tools (and onwards).
Like, you can make a jig out of wood while doing wood working (meta tool and tool are very close here)
It would be difficult to bake yourself a useful oven out of flour, water, and salt, or even a bowl and spoon, really, so, the meta tools for baking are of a totally different sort than the tools used in baking.
I run into a flavor of this in my professional life (batman music) where I help devs and designers build accessible interfaces usually out of fundamentally inaccessible tools — there has to be a moment where a leap happens across tools.
... It would be difficult to bake yourself a useful oven out of flour, water, and salt, ...
One can think of "baking" as requiring (1) heat, and, (2) mushy stuff that can be shaped.
If you incidentally want the baked thing to taste good, you make the mushy stuff out of flour, water and salt.
(I figured someone would point this out, but I struggled to come up with another example of distance)
* Do the tools we use to build new tools influence what we can produce? *
Yes.
- Do the tools we use to build new tools limit what we can produce? *
Yes, Yes, Yes.
It seems to me that it is difficult to do FoC until you upgrade PoC to PoC (Past of C, Present of C, resp.). Note that the ground rules for Present-of-C are now very different than they were when Past-of-C was first invented, e.g. we don't need time-sharing due to $$$ and we don't need to worry about about heaps/GC/malloc/memory-sharing due to $$$ and we are allowed to overlap cells (e.g. "characters" and beyond). Old-time notation uses the simplifying assumption of tossing out time to allow equations to be written down on papyrus. The new medium allows us to add back "t" and "z" and to explore phenomena that are inconvenient when stripped down to written equations on papyrus. We are indoctrinated - by 2000+ years of using papyrus - to think that we must use only papyrus and writing utensils, thus, we find it difficult to invent new ways to use this new medium.
I think one of the things that holds back these non-coding-but-capable-of-expressing-computations-typically-expressed-by-coding tools is that we almost always create them to be high level. We don't start with primitives of the system and design a system around that and then figure out a way to work our way up. Instead, we start from the beginning with all the capabilities of modern computers. Hosted on top of high level systems (more often than not today, in the browser).
Focusing on this high level setup first (flash is a great example of such a tool), creates a usable system faster, but fails to have the properties that generalize in the way that programming languages have. I don't think this is an accidental property. It took us a long time of working with lower level language to figure out good abstractions for the higher level ones. To figure out how they should be implemented, to figure out idioms, etc. We are still in the process of getting better at this.
I think, if we began at the lower level, we'd have a greater chance of over time. slowly, discovering those things. I think there is this temptation that because we want to get away from coding and all that we bring with it, we also want to get rid of the details of the computer. But I think that's a mistake. We don't even know what the assembly of coding-but-not is. We don't know how to go from a higher-level coding-but-not representation, into a lower level coding-but-not representation. So we are stuck relying on code when we want to make these systems fast, or interoperate with existing things.
Imagine a system that is coding-but-not, but can interop with the unixy-C world we have today. That can compete with C on speed. That can interact with the computer in any way coding-that-is-code can. Now we can start making the tools for others to make tools without needing to leave our ecosystem of coding-but-not.
