You are viewing archived messages.
Go here to search the history.

Ivan Reese 2024-02-26 04:05:44

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.

Ivan Reese 2024-02-26 04:12:06

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)
Ivan Reese 2024-02-26 04:14:08

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?

Ivan Reese 2024-02-26 04:17:25

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.

Personal Dynamic Media 2024-02-26 04:30:26

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.

Ivan Reese 2024-02-26 04:45:20

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?

Ivan Reese 2024-02-26 04:50:27

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)

Personal Dynamic Media 2024-02-26 05:02:50

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.

Ivan Reese 2024-02-26 06:09:08

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)

Ivan Reese 2024-02-26 06:10:51

Coding is a slightly more general way to do ————. So I want a subset of what coding does, specialized to a specific activity.

Konrad Hinsen 2024-02-26 08:06:43

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.

Paul Tarvydas 2024-02-26 11:49:17

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. 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.

📝 Computers are a new medium

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.

Eli Mellen 2024-02-26 12:33:24

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.

Eli Mellen 2024-02-26 12:36:57

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.

Paul Tarvydas 2024-02-26 13:17:29

... 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.


Eli Mellen 2024-02-26 13:18:49

(I figured someone would point this out, but I struggled to come up with another example of distance)

Paul Tarvydas 2024-02-26 13:43:46

* Do the tools we use to build new tools influence what we can produce? *


    • 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.

Jimmy Miller 2024-02-26 19:02:42

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.

Mariano Guerra 2024-02-26 11:25:57

Progress on the binary operations explorable: step through binary AND, shift left and shift right.



Mariano Guerra 2024-02-26 13:49:40

🚂 All onboard the shift operation train (showing intermediate results during stepping)


Konrad Hinsen 2024-02-26 13:53:38

Moldable development is coming to Common Lisp:

📝 clog-inspector

A moldable Common Lisp object inspector based on CLOG

Mattia Fregola 2024-02-27 00:15:43

Hi everyone,

I have a big question about a programming-related problem I only partly understand, hoping not to get an answer, but rather pointers to where I should be looking. Here it goes.

For the past two years I have been working on SplootCode wanting to make code more accessible to non-engineers. The initial product (as is today) is basically a structured editor with drag and drop a-la-Scratch capabilities, and some other things to help non-engineers see and understand what the code is doing. You can see an example tiny program here.

During the interviews I conducted with several people, I bumped into a non-native English speaker who revealed their frustrations with having to learn English in order to code.

After speaking to another dozen non-native speakers - some of whom teach programming in non-English speaking countries using their native language - I figured that this is a really big problem for a lot people, and I want to solve it.

Since I have been deep into SplootCode for over two years, I am sure that I am suffering from sunk cost fallacy like crazy, thus the reason I am asking the question here is to get some outside perspective.

So, to solve the problem for people, I am wanting to address the nested problem that – AFAIK – the vast majority of programming languages, with the exclusion of any purely symbolic ones, are effectively a subset of the English language.

My first train of thoughts was: “perfect use case for building on top of SplootCode! The structured editing part means half the work is done already since I can label keywords however I want”.

Followed by: “but wait! how can this be actually solved so that anyone can use their own tool of choice, which is what people will need?”

Thus my question is:

I believe that the proper solution is to add a layer * to code – call the tongue layer – that defines the label ** for each tongue .

What do I need to understand thoroughly, in order to build such a solution? Who should I speak to?

  • layer intended as a standalone structure that doesn’t interact with anything but the semantic label of any literal, variable, operator, or function (or any other atomic structure that may exist within a programming language)

** label intended as the human-readable part of an atomic structure of a program. For example, the if in the structure if () {} in javascript, would be se in Italian, and もし in Japanese.

Kartik Agaram 2024-02-27 01:52:38

One thought: maybe you need to understand the internalization process. As I understand it, there are libraries that let you wrap all string literals in your program in an annotation and then look up the literal in a language-specific list of translations.

So one lens here is that you "just" need to perform this internationalization process to a compiler codebase..

Paul Tarvydas 2024-02-27 02:14:56

It sounds - from my very biased perspective - like you are describing text-to-text translation. If so, then you want to dig into technologies that make text-to-text-transformation easy, e.g. PEG parsing, LLMs (large language models "AI"), macros (you can learn about macros in Lisp, but lisp uses Lists instead of Text for macros). For PEG, I would suggest OhmJS (pdubroy on ohmland discord, and and LLMs (elimisteve on ohmland and programming simplicity discords ( (and, TXL (Source Transformation Language by James Cordy) and the fields of Program Transformation and meta-programming. I have been dabbling in this sort of stuff and would be happy to elucidate (including a DSL for t2t for use alongside OhmJS). (REGEX and CFGs look tantalizingly close, but aren't as good at this as Ohm and PEG and LLMs). Note that OhmJS can do more than just t2t transformation.

📝 Join the Ohm Land Discord Server!

Check out the Ohm Land community on Discord - hang out with 142 other members and enjoy free voice and text chat.

Mattia Fregola 2024-02-27 02:20:18

Thanks Kartik Agaram, sounds inline with it, I’ll deep dive!

Mattia Fregola 2024-02-27 02:28:02

Indeed Paul Tarvydas , I will definitely leverage LLMs for the text-to-text translation part.

Thanks for the links on the transformations too, I’ll look dive into Ohm and read up on PEG parsing as well!

David Alan Hjelle 2024-02-27 02:42:32

You might be interested in this thread: 💬 #linking-together@2024-01-25T19:55:34.780Z

The language there has a graphical symbolic representation and a text representation that, as far as I can tell, is not language-specific.

I think WordPlay is also designed to be natural-language-agnostic?

None of that is probably all that useful to you for your own language except for inspiration. :-)

Mattia Fregola 2024-02-27 06:12:23

Thank you @David Alan Hjelle , inspiration is always awesome :)

Dan Swirsky 2024-02-27 08:14:13

I'm not sure that "their own tool of what people need". A billion spreadsheet programmers are just fine with their spreadsheet editor and can always export their spreadsheets if they want to use a different one. The point of your structured editor is to make programming easier by the very fact that it is a different kind of editor. If someone wants to program with a non-structured editor, you can give them their standard code without the tongue layer and they can go. And if someone else develops a different structured editor with something like your tongue layer, you can decide whether to export to their format.

Mariano Guerra 2024-02-27 08:50:49

Blockly and hedy are the best at translation that I know of:

📝 Localize Blocks  |  Blockly  |  Google for Developers

How to define blocks that are easy to localize.

Mattia Fregola 2024-02-27 09:24:13

Didn't know they did Mariano Guerra ! Thanks for sharing!

Mattia Fregola 2024-02-27 20:59:26

Dan Swirsky that’s one of the strongest conviction I had before seeing how people interact with computers 😅

Mariano Guerra 2024-02-27 13:53:21

Where are the nibbles?


Kartik Agaram 2024-02-28 04:36:56

Some doggerel while reading

If an Agile org and Private Cloud

put in a million sprints,

Do you suppose their OKRs

might start to overload Mars?

(With apologies to Lewis Carroll:

📝 Science Fiction Short: Hijack

Building a computer the size of a planet can have unexpected consequences

Tom Lieber 2024-03-01 22:11:24

Pictured: the equivalent of this WebPPL model

var clamp = function(num) {

  return num > 2 ? 2 : num


clamp(sum(repeat(3, function() {

  return flip()


What's new this time? User-defined functions! There's one anonymous, single-use function at the top (the one that's passed to repeat() ), and a function named clamp below that's written to be reused. Functions = Boxes. Lu took lines, but I think boxes are still available.

The writeup is here: If you want to know the whys and the hows, it's for you. I love how the lab notebook / experiment writeup format gives me places to hang all the random things I'd like to write about. Design vicariously with me. 🙂

(Even if you don't have the time to read the writeup, I want you to know that I do not like how the clamp function's source code looks. I'm not done. But I decided a few entries back that I was going to dump all the LEGO bricks onto the floor where I could see them before I started picking the ones I wanted in my spaceship.)

2024-02-21 clamped sum.gif

Maikel van de Lisdonk 2024-03-02 19:47:07

The last couple of weeks I've been mainly focussing on the editing/creating of composition nodes in the visual programming system that I am building, which is more work than I expected. At least it's now possible to add input and output ports dynamically for existing compositions.

Since I also wanted to have some fun (and procastinate) I decided to implement a zoomable mandelbrot fractal in the gl-flow app, which can be seen in this little video This also required some extra node-types and adjustments to the pull-based gl-flow engine. Like having support for a for-loop-node which can be breaked out of depending on a condition. I implemented both the for-node as the condition as containers due to the way the pull-based engine works.

To give some background on the implementation of the pull-based flow engine which is used in the gl-flow app: the nodes get executed backwards starting at an end node and their output is glsl-code which can be run by a fragment shader on the gpu. So, the nodes themselves are not executed by the shader but the generated output is.

The spatial placement of the "end-nodes" is used to determine which node gets executed first and then the input nodes are executed backwards. A container is also an end-node. So, the contained nodes are executed in a code block.

I think the fractal renderer works quite nicely but you can't zoom very deep because of precision issues. I might try to solve these in the future, but my goal is not to make the perfect visual shadertoy😊.

Kartik Agaram 2024-03-03 19:44:03

I have a friend lined up to try this out the minute you publish some code 🤘

Maikel van de Lisdonk 2024-03-03 19:56:02

Thanks, He'll need to have a little bit of patience, sorry 😊 . But no worries I'll post a link hopefully soon.. because I do think that's the only way to let my project grow. I just want to improve some thinks before I post a link to my project

Tom Lieber 2024-03-03 19:15:51

Catharsis: I finally don't have to lay code out (solely) by typing <x, y, z> coordinates. 😌

The write up is here, though it's more like a programming livestream this time because I didn't iterate on the language much: