Future of Coding History

Paul Tarvydas 2024-07-17 20:08:31

Thinking about Schematics vs. Code. [This began as a short reply to Stefan Lesser regarding my take on electronics schematics in another thread.]

open.substack.com/pub/programmingsimplicity/p/2024-07-17-thinking-about-the-game?r=1egdky&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

📝 2024-07-17-Thinking About The Game Of Pong In Hardware And Software

In aircraft and flying terminology, there is induced drag and parasitic drag. Induced drag is the kind of drag that you want, while parasitic drag is a side-effect that you wish weren’t there. For an airplane, we want lift which is a kind of drag. We push the plane faster through the air to make a good kind of drag (lift) on the airfoil-shaped wings. As we push the plane forward faster, though, we get unwanted drag (friction) against things like the landing gear. The good kind of drag is called “induced drag”, while the unwanted kind of drag is called “parasitic drag”.

Konrad Hinsen 2024-07-20 16:07:04

Thanks Paul Tarvydas for this detailed explanation with a nice example!

There's one aspect I find missing from the discussion: CPUs. Early CPUs, the ones for which our languages, compilers, etc. were designed, have no accessible parallelism (and the very early ones no parallelism at all). There's a single instruction stream. In that universe, function-based programming did not any additional synchronicity constraint.

Today, all CPUs and GPUs have some level of parallelism, but it's not under the control of the software. If I have a four-core processor, I can run up to four independent threads. That's a pretty severe constraint on asynchronicity in software as well.

So I wonder how we could possibly get to your dream situation of "as many asynchronously working subsystems as our design requires" with today's processors and no software layer for multithreading on top of them.

Paul Tarvydas 2024-07-21 09:43:33

The issue of CPUs is addressed, but, maybe not with enough brutality

There’s approximately 60+ truly-asynchronous processes on the 1972 Pong schematic, but no CPU. The design employs massive parallelism and real internal asynchronousity.

In 2024, we consider 8-ish cores to be a marvel. The cores share memory, so they cannot even be truly asynchronous.

That’s some 50 years later. Something is wrong with this picture.

A CPU was originally meant to be a simple sequencer circuit that was not reentrant. There is no reason to make CPU’s multi-threaded, other than co$t. In 1950, it was too expensive to own more than one CPU, so human brain-power was wasted on inventing and adding software to make CPUs multi-threaded. Today, we have access to very cheap hardware actors - Arduinos, Rasberry Pis, etc. (cheaper yet, if you discard Linux and reclaim internal chip space).

N.B. “central” is a bad word these days. We probably want DPUs (distributed processing units).

I previously tried to write about hardware actors in guitarvydas.github.io/2024/02/17/Hardware-Actors.html.

So, one might imagine a reprogrammable electronic machine (avoid the use of the word “compute-er”) to be a collection of 1,000s of cheap hardware actors on-a-chip, where only one of them is a big honking Linux blob for running existing bloatware and for backwards compatibility.

Konrad Hinsen

📝 Hardware actors

Oops! Your browser doesn't support PDFs! Download Instead

Adam Davidson 2024-07-19 16:35:00

Just a random thought that has been rattling around in my head while listening through podcast episodes and Ivan’s visual programing points. I am new here so apologies If all this has been said before, or covered in podcasts I haven’t gotten to yet.

I want to propose a slightly different framing for what it means to say that a representation of a program is visual / spatial or not

I think that textual programming is visual . It’s a series of symbols laid out on a screen in rows, and the spatial/visual relationship between the tokens does actually correspond to aspects of the operation of the program. For example an assignment statement has the thing being assigned to on the left, and the value on the right, parentheses group things together spatially on the screen, statements that appear above others within a block (usually) execute before the ones below (goto considered harmful breaks that down which I think you talked about). And good code formatting is mostly about making these visual analogies stronger. Zig plays with this by allowing you to release memory the line below where you have allocated it, which breaks down the time <-> up down analogy since the deallocation actually happens after the lines that follow, in favor of being able to spatially group two very semantically related statements in the program. That shows that there’s a lot to be played with within the context of textual programming if you think about in terms of spatial analogies to your program.

To explore this more though, it’s interesting to think about how a program could be represented completely non-spatially or non-visually , and how these two things might differ.

You could imagine being read the textual code for some program aloud, without seeing the text at all, that would be a non-spatial, and non-visual representation of the program

You could also imagine seeing a single visual element, like a black circle on a screen or something, blinking on and off in morse code to transmit the code to you. To me that would be a visual representation that is not spatial, since the spatial dimensions of that single visual element don’t matter at all to the information being transmitted. It could be an array of dots or an image of some crazy person’s pure data patch or anything at all blinking on and off and the program being transmitted would be the same.

So what would a representation of a program look like that is minimally spatial ? Maybe you could imagine two dots on the screen that encode a two bit piece of a textual program encoded in unicode, one two bit portion at a time? They flash on with the first two bits for a second, then the second two bits for a second blah blah blah (so practical!) Is this spatial?

There is a lot to explore here actually I think. Technically the particular spatial relationships of the pixels on the screen does need to be considered in order to decipher the program in the two dots scenario, and that is qualitatively different from the one dot scenario, where no information is gained from examining any spatial relationships.

But I am skeptical of whether or not this is actually minimally spatial. It seems like we should define a spatial representation of a program to mean that some meaningful part of the program is represented spatially, and I don’t think “a two bit portion of a unicode character making up a textual program” meets that criteria. But Is this “meaningful vs non meaningful part of a program representation” a distinction that can even be clearly drawn? It seems obvious that there is at least a real quantitative difference if not a qualitative difference there. If the difference is only quantitative, then this two bit program would have to be a minimally (if highly unsatisfying) spatial representation of a program, but maybe there is some way to formally filter out non meaningful parts of a a program’s representation that are only essential to the representation of the program and not to the program itself?

But like was pointed out in the No Silver Bullets episode, there are a huge number of different ways to visualize the same program. I think that we are stuck in a single way of visualizing our programs - which is the code, and to me the problem is not that code is bad, but that we are missing out on a huge number of different ways we could visualize and “reason about” (lol) our programs, so I’m not disagreeing with the actual takeaway, it’s more a critique of the hard division between textual and visual programming.

Scott 2024-07-19 17:26:21

Going to need to take some time to digest this, but I wanted to say I really like thinking about "how could a program be representated non-spacially or non-visually, and the comment that "I think that textual programming is visual"

One thing that comes to mind - there have been some esolangs that have explored this idea a bit, though I don't think it was from this particular starting point. Velato (velato.net) for example, encodes programs as midi files, so you could have an audio representation of a program...

Jasmine Otto 2024-07-19 17:32:28

Fwiw, a relevant piece of math lore is the informal distinction between algebraic thinkers' and geometric thinkers'. All of the most useful mathematical machinery, of course, may be represented either algebraically in terms of symbols, or geometrically in terms of diagrams. So these two modes are isomorphic, but not trivially so. This yields many productive conceptual moves.

You've described a situation where every representation , I think, is both useful and arbitrary. So that at the limit you get that minimally spatial' vision of the essence' from which which the universe of diagrammatic, symbolic, etc. forms may arise.

Kartik Agaram 2024-07-19 17:34:35

This overlaps a lot with some stuff I've been trying out recently to allow us to create new "characters" in our programming environments that string together more spatially than just a linear sequence.

My inspiration for a minimally spatial notation is the mathematical notation for summation: en.wikipedia.org/wiki/Summation#Capital-sigma_notation. It's a character, and you have a few places to add characters above and below it (in addition to the right)

The direction my thoughts have been going with this is, what if we had a way to just draw new such characters, specify holes around them where other characters go. And then use them transparently in an otherwise textual screen of code.

The primary use case in my mind is function calls, making them more visually distinct.

Links to my posts, all in #devlog-together over the past few weeks:

💬 #devlog-together@2024-06-30

futureofcoding.slack.com/archives/C03RR0W5DGC/p1720015836688779

💬 #devlog-together@2024-07-11

futureofcoding.slack.com/archives/C03RR0W5DGC/p1720750642619629

Adam Davidson 2024-07-19 17:34:47

@Scott this is a cool esolang! definitely an example of a completely non spatial representation if you were to listen to the midi

Kartik Agaram 2024-07-19 17:45:23

@Scott on the subject of esolangs, one earworm I have never been able to free myself of is, "what if Befunge but readable?"

akkartik.name/archives/foc/thinking-together/1681698511.039269.html

akkartik.name/post/2020-03-13-devlog

Adam Davidson 2024-07-19 17:47:36

Kartik Agaram this is almost exactly where my thoughts went - that thinking about textual programming visually could give you a path to a sort of incrementalist way of getting more and better spatial metaphors from where we currently are with textual programing - I will have to read through some of these threads. there is a lot of cool discussion to read through in this slack

Adam Davidson 2024-07-19 17:56:04

@Jasmine Otto That divide in math does maps to what I am talking about here I think, I am reading through sipser’s computation textbook right now and he gives the formal algebraic and graphical representations for finite automata, pushdown automata turing machines etc, and it’s always easier and quicker to understand the graphs. But the algebraic definitions are still are spatial when written down on paper, in my mind, so maybe it’s not exactly the same thing? not sure though

Scott 2024-07-19 17:59:31

Kartik Agaram hah! First I loved this line: "Now you can imagine a reduce operation as a series of solar systems that the spaceship visits one by one."...going to have to play with this a bit...I think there might be something here - I've been noodling around about new types of interfaces for AI agents...and a fully 2d/spatial metaphor for building/interacting/observing them seems worth digging in to...

Daniel Buckmaster 2024-07-20 00:09:51

This is really thought provoking. As someone who is a big fan of text, it's really interesting to think of it as a visual medium.

It reminds me of a friend who I did uni with, where we took a course programming 6800 microcontrollers in assembly. And of course being the types we were, we decided that we needed to build a better IDE for assembly to make the course tolerable. One of the first things we tried was just changing the lines' background colour at each basic block boundary. That's playing with the visual nature of the text representation.

There wasn't anything profound about that, I'm just reminiscing and saying thank you for this post!

Scott 2024-07-20 00:21:47

Ahh! That’s a great point, that must be what resonated with me about the “text ~is~ a visual medium” line…years ago I suggested to a new developer on my team that he turn syntax highlighting off on his ide for a few months to start to build the muscle of being able see the structure of the code he’s working with rather than the details…it’s the inverse of what you’re saying, but still points to this idea that we do treat text visually without really talking about that aspect of it

Daniel Buckmaster 2024-07-20 01:06:46

Syntax and code formatting is so often and hotly debated because it deeply affects the visual quality of our textual representation of the program!

Adam Davidson 2024-07-20 01:37:11

Very true, it’s a way we can have control over the visualization of the program within the textual paradigm

Dany 2024-07-20 06:30:49

Don't forget syntax highlighting, Remove all colors from a piece of code and find yourself disoriented.

quote: ".. meaningful part of the program is represented spatially "

I think that is exactly the question, what parts should be visually / spatially represented. The big one in textual code is, top to bottom is execution order. We are giving one dimension to basically procedural programming.

Kartik Agaram 2024-07-20 06:41:33

Not always, which complicates things. a, b, c executes from left to right, but a(b(c)) executes from right to left. As those variables grow long they also take up the vertical axis (top to bottom and bottom to top respectively).

Don Abrams 2024-07-20 12:51:31

I had a similar question and reduced it down to "what would an audio-only programming language sound like?" My guess was a lot more subgoals, markers for "filling in later", and fine scoped tests/examples.

📝 What are subgoals?, SUBGOALS

What are subgoals? A common problem in introductory programming courses is the expert-novice gap between instructors and students.

Hayden 2024-07-20 13:53:50

Loving all of the orthogonal thinking prompts throughout this thread. My perspective is that text-based programming is more characterized by the interaction model of essentially being equivalent to typesetting a document. Also worth considering is that many people interact with textual programming strictly non-visually through the use of text-to-speech. In my mind, things move to being more "visual" or "spatial" programming as the document interaction model goes away and the mapping to audio-only interface becomes less clear.

Adam Davidson 2024-07-20 17:40:20

Ok so sorry for posting a super long thing again but what @Jasmine Otto brought up about Geometric vs Algebraic representations got me thinking. So if you define an “Algebraic” representation to be a representation of some formal object that can be expressed as a sequence of symbols, and a “Geometric” representation to be one that has a set of symbols that can be oriented anywhere in 2d space in relation to one another, then I think you can actually draw a pretty clear distinction between the two. Maybe the distinction is better defined as 1 dimensional vs 2 dimensional, but I will stick with this Algebraic vs Geometric thing.

say the formal object we are representing is the fully connected graph of 3 nodes a, b, c. With a geometric representation, you can have three nodes laid out as an equilateral triangle, with 3 edges connecting them. Very simple. You have 4 different symbols, a, b, c, and <line>, which represents an edge. In the standard algebraic representation, where you have a pair (V,E) of vertices and edges, the representation is ({a,b,c},{(a,b),(b,c),(c,a)}). The symbols used are (, ), {, }, a, b, c, “,”, which is 8 different symbols. And the total number of symbols in the representation, counting repetitions is 29 (if I counted right).

Let’s say we just want a representation that can distinctly express any graph with just 3 nodes to simplify things a bit. For the fully connected graph you can think of a sequential representation that has the same number of symbols and symbol instances as the geometric representation: “a-b-c-” the “-” at the end could be interpreted to mean that there is a connection back to the first node in the sequence. Or you could simply do “abca”, where two nodes have an edge between them if they are next to each other in the sequence. In this case, we have a repeated symbol “a”, but fewer symbol types than in the graphical representation.

But then you could similarly eliminate the <line> symbol from the geometric representation by saying that nodes are connected if the symbols representing them are touching. Maybe you replace each symbol a, b, c with that symbol inside a circle to imagine this better. Now I think you reach a point where there is a real difference. In the case of the geometric representation, you can differentiate between the fully connected graph between nodes abc, with only 3 symbol types, and 3 symbol occurrences. Whereas in the sequential graph, there is no way to differentiate between the two with only three symbol types and 3 symbol instances. With only “abc” you don’t know if the a is connected to the c or not.

Textual programming is purely sequential in nature. No matter how you format your code visually, the one dimensional sequence of characters fully determines the program. So you will need either more symbol types, or more symbol occurrences to represent programs textually than we might if we use 2d space!!

Ivan Reese 2024-07-20 20:47:17

Shorter version of the previous:

In visual programming, spatial arrangement of objects doesn't have to be meaningful. But it can be. That part is open to design.

Now I'll add:

In a good system, the programmer would get to choose whether spatial arrangement is meaningful or not.

In a good system, the movement of objects through time is just as significant as relative positions, connections, visual representations, etc.

There are physical dimensions we haven't explored. If you live in text, you won't feel the pull to explore them.

Dany 2024-07-21 08:10:41

@Adam Davidson Reading your post,.. you know, writing down geometric and algebraic problems like this is sort of a prompt for an AI? That makes me realize why I dislike AI for coding, it's like we un-invented algebraic notation and went back to writing prose. Instead I want to go into the other direction.

Dennis Hansen 2024-07-21 20:57:32

Love this train of thought. I like to think of visual programming as a 'superset' of textual programming.

In general the following roots my thinking in a broader context but beware: This definitely has im14andthisisdeep energy:

Perhaps the stark divide between computation and physicality is an illusion as all computation is physical in nature, with much of it being observable- some through a representation on an interface (the 'visual' component), or some so hidden in patterns of electricity. So we might say minimizing the visio-spatial element of a computation is either compressing the representation of the code (Now you don't need semicolons!) or leaving information out (No more writing explicit types!).

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

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