[davemp]

Programs aren’t text that you run on a computer though. Programs are text that describe an abstract syntax tree which encodes the operational semantics of the thing you’re computing.

Maybe (likely) you could come up with a more convenient set of operations, but I don’t really see how expressing that as plain text ast is really holding things back.

[ajkjk]

Consider that when doing 3d modeling you usually do not work on the mesh data itself but on a visual representation of it. Sometimes you have to go under the hood of this representation to write e.g. shaders.. But you'd like to not do that at all for the daily work.

In particular, the syntax tree is also Just Another Representation of the functionality... But it's still way overspecified, compared to your intent, since it has lots of implementation details encoded in it. Actually it is the tests that get closer to an exact representation of what you intend (but still, not very close). (This is also why I love React and declarative programming: because it lets me code in a way which is closer to the model of what I intend that I hold in my head. Although still not that close).

So, programming seems similar to the mesh data for a model to me. The more you can get a representation which is faithful to the programming intent, the more powerful you are. LLMs demonstrate that natural language sorta does this.. But not really, or at least, not when the 'compiler' is a stochastic parrot. On the flip side it gets you part of the way and then you can iterate from there by other methods.

[ajkjk]

Incidentally, coming from a half-baked physics background: to me this feels very similar to how, as physics moved closer to the fundamental theories of GR and QFT, it was forced to adopt the mathematical framework of representation theory[1], which is to say, to reckon with the fact that

(a) a mathematical model like a group is a representation of a physical concept, not the concept itself

(b) this process of representing things by mathematical models has some properties that are inescapable, for instance the model must factor over the ways you can decompose the system into parts

(c) in particular there is some intrinsic coordinate-freedom to your choice of model. In physics, this could be the choice of say coordinate frame or a choice of algebraic system (matrices vs complex numbers vs whatever); in programming the choice of programming language or implementation detail or whatever else

(d) the coordinate-freedom is forced to align at interfaces between isolated systems. In physics this corresponds to the concept of particles (particularly gauge bosons like photons, less sure about fermions...); in programming corresponds to APIs and calling conventions and user interfaces---you can have all the freedom you want in the details but the boundaries are fixed by how they interop with each other.

all very hand-wavey since I understand neither side well... but I like to imagine that someday there will be a "representation theory of software" class in the curriculum (which would not dissimilar from the formal-language concepts of denotational/operational semantics, but maybe the overlaps with physics could be exploited somehow to share some language?)... it seems to me like things mathematically kinda have to go in something like this direction.

[1] https://en.wikipedia.org/wiki/Representation_theory