Programming Programming; Or, Notes On Making Program Structure More Informative

Foreword

I don't usually write about programming as it sounds like gibberish, but with with the availability of Language Model AI programming became more approachable.

It just needs one tiny little thing, a helpful 100 or 300 line WikiWiki that will host the description and corresponding code.

Writing a WikiWiki for the purpose of computer program description, and potentially automatic creation, is a great invitation into the world of programming.

It is learning programming by starting with creating your own, artificial intelligence based code editor.

Writing a WikiWiki of any flavor, makes for a wonderful and pleasant entry into the world of programming.

Programming Programming

The user interface is a massive unsolved problem in the world of programming, currently there are three levels in which application programming can work.

Level one, is the code editor level, where all the program files, are simply stored in a directory structure.

Level two, does away with the directories, and code is write atop a concept of a notebook, or a code journal.

Level three, a graphics based approach, where boxes with poperies represent functions, and are connected by lines, forming a graphical representation of a program.

(I want to clarify that Visual Programming, as it is used here, is not about drag and drop user interfaces, but flow based programming with a graphic user interface. Functions represented by boxes, and control flow represented by lines.)

Level one is the safest, there are no limits here, but even properly structures applications are hard to remember.

Level two, combines concepts of literate programming, WikiWiki, and documentation first approach, it is harder to get lost here.

And level three, is unfortunately a broken promise, as it requires a large ecosystem, multiple programmers, and a clear head to get it right.

All implementations of visual programming I have encountered, failed to deliver, and became bloated with confusion.

Visual programming done correctly, can almost become a perfect solution, however, a computer program must be represented from multiple angles.

And visual programming is a manual process, that only lays out one angle, one perspective, and it cannot be easily rotated.

Language Models or AI, could do it, but its non-deterministic nature, does not quite solve anything.

It is of some note, that the graphic user interface, should work on small screens, that multiples complexity of the codebase.

The problem with level one programming, the safest kind where everything is a text file in some folder structure.

Is that there is not enough meta information, or semantic data, about the program structure that the programmer holds in their mind.

Using cookie cutter structures, like model view controller based plugins, does not solve but rather deepens this problem, by adding more structure.

This leaves us with number two, Literate Programming, WikiWiki like Approach.

The function description first approach, allows for just enough metadata, to generate multiple graphic representations of the program.

Multiple angles, where for example only image processing related code, is plotted on a graph helping the user focus on what they need to see.

These graphs are much simpler than what Visual Programming normally delivers, they are read only, and are based on more metadata than note type.

Literate programming, or comment first programming, focuses on text first, code later.

The programming requires to create such a system is quite simple, as it is at its core a 100 lines of WikiWiki code.

I recommend using Code Mirror for the code editor, and Cytoscape-js for the automatic layout graphs.

Language Model AI be used to expand metadata, and in this context it’s non deterministic nature won’t be too much of a problem.

And the programming can be either JavaScript rich, where I would recommend svelte, or standard HTTP as the case was with the first WikiWiki.

I would like to note, that when we rise above level one, the line between code and code execution is allowed to blur.

Saving a function, can make it, and thus the program, immediately available for execution.

In something that can be viewed as transparent deployment, where the program is edited live and made available under new revision, or latest tag.

In another model, the program that is spread across a tree, of functions spanning multiple graphical nodes or WikiWiki pages.

Can be exported as a proper module, or a well formed standalone application, that is indistinguishable from what a level one programmer would create.

In conclusion, level two is the correct approach, as it has a small code base and encourages user to describe the program first.

This creates enough metadata, to interact with Language Model AI, that can potentially create the code in description. (And certainly contribute useful information, to the metadata it self.)