If you wanted to make a machine (eg. the gearbox for a car), the plans you'd make would usually consist of a blueprint with all the different gears represented, and little notes for features which aren't obvious from the diagram (eg: "this one is rubber!").

In other words, you'd think up a simple way to represent the design on paper, and draw it.

Programs can be thought of as strange kinds of machines which process data -- they have many of the same properties as machines -- [wave hands a bit] -- however, when we write a program, the design is in a form that's optimized for interpretation by a compiler, not a human.

Instead of using the most humane representation of the information-processing machine, we write out a list of abstract steps that, if you follow them, will result in the machine. Also, abstract steps for how to construct each of the parts.

If you wanted to describe the design of a gearbox for a car using a programming language, the code would look like this:

box:
  hole1:
   * wall: 1
   * position: 3x, 2y
   * diameter: 0.3cm
  hole2:
   * wall: 2
   * position: 5x, 6y
   * diameter: 0.3cm
  hole3:
   ...etc...

gear1:
 * toothsize: 1.4cm
 * toothspacing: 3.2cm
 * diameter: 15cm 
 * position: x=37cm, y=58cm, z=12cm
 * center-hole: 0.3cm

axel1:
 * thickness: 0.3cm
 * length: 15cm

axel1.middle passes through gear1
axel1.end1 passes through hole1
axel1.end2 passes through hole2

gear2:
 * toothsize: 3.2cm
 * diameter: 19cm
 * center-hole: 0.3cm
 * position: x=37cm, y=58cm, z=12cm

axel2:
 * thickness: 0.5cm
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
etc,
ETC!!!!

Just a giant list of definitions.

Now, imagine that after your compiler finishes building the machine from your instructions, it's a sealed black box that you can't see inside. You have no idea what it actually looks like.

Now, imagine that if any of those sizes are off by a milimeter, the gearbox explodes when you try to build it.

Now, imagine trying to design an entire car that way.

That's programming.

Another frustrating aspect is that it'll take you weeks to figure out how a large complex machine (on the order of a car) works if all you have to look at is code -- even if you wrote the code. The meaning of code is forgotten about a month after you write it. If you're working on a machine with 50 gearboxes in it, you will quickly forget which gearbox does what, because they are all just large lists of very granular operations. There is nothing to that obviously distinguish them, aside from the many tiny variations in the parameters and the order of operations.

A major constraint that the developers of programming tools seem to have never been able to design around is human cognitive ability. The human mind is not built to hold thousands of variables in memory at once and simulate the interactions between them. An average person's short term memory can hold 7 things in it at once. This amount of memory's been enough in the past, since humans are usually operating on a universe that, itself, acts as a temporary memory. If you're hunting animals with a spear, you only need a couple variables -- the velocity/direciton of the animal, and the velocity/direction that you're going to throw the spear. Everything else is left to the brain's underlying hardware (distance/speed estimation, spear-arc calculus, etc.)

To contrast, when writing code, the brain has almost no built-in hardware for simulating the program. It's almost all done intellectually. And when you design a machine in your mind, if the phone rings, the machine is freakin' gone! The universe doesn't maintain the state of all the variables for you, like when you're hunting, or building a machine in the real world.

The language that I'm using to code this gearbox is actually more advanced than the run-of-the-mill programming language. It's what you'd call a domain-specific language, since it knows about the things in your problem domain: gears and axels. It also lets you specify declarative relationships, like "axel passes through gear". The common programming language is much more low-level -- you'd have to make each gear from a wheelbarrow full of iron ore, or buy a "library" of pre-cut gears. But, of course, the gears from the library don't all work with gears from another library, and you can only use them in certain kinds of gearboxes.

At this point, you might be considering the remote possibility that text is not the ideal medium for building machines. A medium with more than one dimension would be useful.

The solution to the programming-sucks problem will probably be an amalgum of ideas from Intentional Software, Subtext, Natural Language understanding, and a slew of clever ways of representing information structures and algorithms (eg. pictures from textbooks).

• Note to self: Insert examples of improved textual languages (eg. goal directed)

Pivotable Data Displays

This chunk of code is inside-out from the way a human would intuitively think about it:

box:
  hole1:
   * wall: 1
   * position: 3x, 2y
   * diameter: 0.3cm
  hole2:
   * wall: 2
   * position: 5x, 6y
   * diameter: 0.3cm
  hole3:
   ...etc...

A box doesn't contain holes which are associated with walls, a box is made of walls which contain holes! this would be a more intuitive representation:

box:
  wall1:
    hole1:
      * position: 3x, 2y
      * diameter: 0.3cm
   hole2:
      * position: 5x, 6y
      * diameter: 0.3cm
  wall2:
    hole3:
      ...etc...

In different contexts, a designer would want different "views" of this program. Maybe they just want to see all the gears connected to this crankshaft, or maybe they want to see everything touching this gear, or everything that connects this crank on one side to a wheel on the other side.

Programming perspectives could give the programmer these abilities.

Question:

Would it be possible to view your program in a way that displays convolutions like the one just described? And, if it's viewable, could it be transformable?

How would adding a 3rd dimesnion allow you to display convolutions?

Answer #1:

In a 2d programming language, the 3rd dimension could represent different possible views of the same relational data set, ordered along some dimension of correlated rotations (so that the rotations smoothly transition while scanning through this dimension).

• Could the aggregate correlated dimensions be determined by a convolutional net trained by humans?