99% of humans think of code as a medium that is too difficult. I don't think the medium is the problem. I think it's the way we've been asking end-users to interact with it: So far, 99% of human-to-code interactions have been code-as-text, an interaction paradigm with unforgiving syntax and symbolic mental models. Investments in interaction paradigms for code have almost exclusively focused on code-as-text and code-as-export, but there are other more end-user friendly ways of interacting with code that we can explore. Let's break down the interaction paradigms for code (tell me if I missed any!): • Code-as-text (massively explored): You type, the code editor helps you type. Examples: IDEs, Low-Code • Code-as-export (mostly explored): Code is treated as a secondary source of truth via one-way export flows from some vendor-specific data you're editing. The tool cannot manipulate or understand the code it just exported, and the interaction ends here. Examples: Vector-based UX design tools, No-Code • Code-as-programming-portals (moderately explored): @Maggie Appleton wrote a great breakdown of this at https://maggieappleton.com/programming-portals • Code-as-data (largely unexplored): Direct manipulation of code ASTs/code visualizations/code output. The tool responds to non-textual interaction from the user and reconciles their intent with a corresponding change in the underlying code-as-text storage. • Code-as-executable (largely unexplored): A code engine/runtime executes code-as-data changes that result from user interactions to give the user instant feedback, closing the feedback loop of the interaction. Related to live-coding, but where live-coding is tied to code-as-text, code-as-executable can respond to changes from code-as-text as well as code-as data. • Code-as-source-of-truth (massively explored): IDEs, version control systems. The primary interaction consists of reconciling your code interactions with those performed by others, e.g. through merging, pushes, conflict resolution. There's so much unexplored territory outside the traditional code-as-text and code-as-export interaction paradigms! Would love to know what you think and whether I've missed any 😄

Under this framework, I guess I'm interested in code-as-executable. You do a thing, then you step back from the action, observing it, abstracting so as to apply in a new situation. Not exactly programming by example.

• where do tools like zapier / iffft / n8n.io fall into this? • what about the plethora of "app builders" in the low/no-code category? • unity / unreal / blender have some interesting shader flow tools, where you can see intermediary results in the calculation

@Tony Worm This "code-as-*" breakdown is not meant as a catch-all model that has to cover the types of creative tools you've mentioned. It applies when a tool has a direct or indirect relationship with code written in a specific programming language. Within that intended scope I see the following alignment to this model: • No-code is code-as-export since you're working with their abstractions for components, logic, etc. but they export/generate to code that fits the target runtime, e.g. HTML, CSS, JavaScript for WebFlow/Framer. • Low-code has the same properties as no-code but adds code-as-text/code-as-programming-portals depending on the specific tool • What I've seen of shaders so far, that's been a mix of a traditional and web-based IDE which falls under code-as-text. Do you have any links to share? • I'm not that familiar with zapier etc, so I don't know their relationship with code, and their specific infrastructure/implementations can vary significantly under the hood.

The approach Enso programming system tries, falls into the category code-as-executable, isn't it?

@Denis Kuniß Yep, I would say so. The dual representation (graphs and text) as well as as interactions with both representations giving the user instant feedback fits the code-as-executable interaction paradigm 🙂 It's a bit hidden in their site, so I captured a video (see attached). I would love to see more languages, including existing ones, get tools that allow for this type of dual interaction. You get the best of both worlds: The low barrier of entry for visual coding. The high ceiling of textual coding. You don't have to invent your own language to get these benefits (and struggle with the cold-start problem of an eco-system). We're creating this type of dual interaction on top of TypeScript at the moment.