Naloe: A True Program Editor

TristanTrim

When I was younger and ever so slightly more idealistic I dreamed of making a programming editor that didn't suck. I was going to call it "Naloe" and provide many bacronyms to explain the name. In the nature of young idealistic programmers, I allowed the scope of the idea to creep horribly out of control. But I still love many of those ideas.

In responding to Is Building Good Note-Taking Software an AGI-Complete Problem?, I started typing out some of those ideas and it became so long I decided to post it as a stand alone post, so without further ado here is a list of ideas about Naloe, the first true program editor:

Programs are running processes. The text code is the thing that bootstraps the program into running, but it is not the program. As such, no (good) program editors exist today, and programmers are forced to work with text editors or integrated development environments to modify dead text that becomes a program. Bret Victor has a lot of related ideas, especially inspiring is "Stop Drawing Dead Fish", although it is obviously, as with Naloe, wildly ambitious and idealistic.
Question: Since the code is not the proper representation of a program, what is the proper representation? Answer: There is no proper representation. The program is coordinated transistor states. Anything you see is necessarily an abstract symbolic representation created to help you understand and control the dance of those transistors. These representations, in Naloe, are called "guises" and a programmer feel free and capable of switching guises on the fly to perform different operations understanding and altering programs.
This makes a clear distinction surrounding "booting", "recovery", and "running" programs. If a program is thought of as something launched from an executable or interpreted from code, then it is natural to think only of editing the program code, but once editing the running program becomes a part of programming, this creates a problem? How is the program supposed to start up again if it is terminated? The answer is that Naloe should focus on making the lifecycle of a program explicit. Programs are living and have living "recovery plans" as a part of themselves.
1. These "recovery plans" should be explicit and should be informed by the guise the programmer used to create the program they are now working with.
2. Alterations to a running program must explicitly modify or leave the recovery plan unchanged. This is true whether it is a programmer or other program modifying the running program.
3. A programmer should never lose a data structure they valued because the program they were working with crashed. This is true whether the programmer values that data because it took their computer time to make, took them time to make, recorded unrecoverable past states of reality, or just cause they think that data is cute and they want to keep it around.
Any guise can be put on any aspect of any program. It is up to programmers to determine which guises are appropriate for what programs and structures.
With no preconceptions on what guises are appropriate, understanding a program would be the same as reverse engineering it. So we might speak of tags and views.
1. A view is a program that coordinates guises giving a programmer a view into some aspect of some particular program or kind of program.
2. A tag is something attached to or referencing another part of a programs structure. Tags may be added by programmers, like comments, to inform programmers or views how which guises might be useful for examining programs or their data structures.
Tags, views, and guises are all themselves programs, and as such should be worked with using tags, views, and guises.
Programs run differently depending on how closely you're looking at them. They run slower. Hooks put in to feed guises have a cost. This is explicit.
1. As with everything in Naloe, increasing and decreasing the amount of hooks should be possible dynamically.
The interface is the most important program. The interface responsiveness should be sacrificed for another program only when the programmer explicitly requests it.
Since data can be viewed with different guises in cohesive views, all user applications could be views within Naloe, and as such, could be modified and worked with in the same ways accessible when working with any other program.
Programs do not exist on a single computer. What computers and hardware a programmer and their programs have access to, and where and how those programs are running, should also be represented and controllable with guises.

Programs are running processes.

Seems like a weird definition to make, when in the next paragraph you declare that programs have no proper representation? Seems like you are trying to take on a very generic view of what a program is, but then by assuming it's a process you are actually narrowing it a lot. (And e.g. excluding kernels or Arduino programs, since those are not processes.)

guises

This would benefit from some examples, e.g. are you saying that the "C language" is a guise, and this editor could decompile a running process to C code on the fly?

Tags, views, and guises are all themselves programs

Ok so a guise is a program, what does it do? Does it translate e.g. a "C language string" to a program and back? What are the representations for programs? I feel like you have to choose some representation if you want programs to be transforming programs.

Seems like you are trying to take on a very generic view of what a program is, but then by assuming it's a process you are actually narrowing it a lot.

Yeah, that's very fair. I am trying to gesture to a very abstract generic view of objects within the computer beyond the strict definition of a process. I was really meaning to gesture to the fact that the text that represents a computer program is not that computer program, and do some extremely fuzzy vibe extrapolation on that idea.

This would benefit from some examples

I think the idea I'm trying to describe with "guise" is more nested and fuzzy than what you are thinking. A byte, or word, could be encoding an ascii character or an integer or a float, or some other kind of thing. So first of all, just that imposition of calling it an integer is giving it a guise. I don't imagine there are many places where you would want to be changing such a low level guise on the fly, but I'm sure it does happen. So all datatypes are guises, but this is generally at a much lower level than I would want to focus on most of the time.

Going slightly higher level you could think of a byte we determined is an integer. How do you want to look at and affect that integer? You might want to see it as an arabic numeral written on the screen. Maybe you want to see it as a bar in comparison to other bars representing other things. Maybe you want to see it as part of a heat map, that could be as part of a literal bitmap image. There are many conceivable ways of looking at that byte and none of them are more true than any other, it depends on the context of what you, or the program looking at the byte, is doing with that byte.

Another small step up to higher abstraction, maybe I have two floats. Are they coordinates? Viewing and moving them on a graph is surely an easy an obvious way of working with them if they are. That should be built in to the way a programmer can edit their program, not an external library that needs referencing. Or rather, the external library should be easily accessible from within the view if the programmer decides that they want to look at those two floats as coordinates for a moment for whatever reason. But in some other specific context those two floats may represent something completely different and it would make sense to represent and work with them in a completely different way.

There are so many possible guises that it wouldn't make sense to try to pull them out of a flat list, which is why the idea of tagging and building views would be some important.

If this seems like an idea that may be general to the point of uselessness, that is because it may very well be that. It is based on a great deal of my frustrations in my experiences programming. I don't want to claim that I think it could really be possible to make the idea sensible or implementable.

About the "C language", it could be a guise, but the way I'm imagining it it would be more likely that code snippits would be used as guises than a whole C language program. I think decompiling a running process to C code on the fly would fit within the idea of what Naloe is and does, but probably isn't something I would expect anyone to actually do in almost all circumstances. Idea 7 "Programs run differently depending on how closely you're looking at them. They run slower. Hooks put in to feed guises have a cost. This is explicit." certainly applies here.

I feel like you have to choose some representation if you want programs to be transforming programs.

No, this is one of the things I really like about the Naloe concept is that there is no true representation. The data and programs are transistor states in constant modification by processing hardware. That is what is really there. Anything on top of that is to help you, or other programs, understand and work with that computer and use it to accomplish other things.

It is true that at any given time you can only be looking at any given object with a fixed number of guises and those guises need to be chosen based on what the object is for, but you don't need to always see that object with the same guise. It is useful to have conventional guises but nothing should ever be fixed to one guise in all contexts, and most importantly, it should be easy to switch to guises that make sense for what you want to do without needless friction.