My Idea Sucks - A Small List of Problems with My Idea

I have been the advocator of my idea so far, but here are a few problems I am currently working on, to ensure that the system will work as a coherent whole.

1. Security - security is, believe it or not, very important. We can further divide security up to
1. Encryption of information
   
2. Secure network/information transfer
   
3. Secure deletion of information - our system keeps everything you ever give it. You cannot delete anything really, so we need ways to delete information, references to and from that information easily and securely.
2. Provable correctness. It is important that we can show that what we are doing is actually being done - because we are using a more complex system, proving things may be more complex
3. Coherence - the computer/os/program pair makes the entire operating system on one hand a loose set of tools, but also a monolithic seeming program. This may make coherence a large issue
4. Scalability - well, CS has always been plagued by prophets that make things that work at the small scale, and then totally cr*p up when you try to scale it up. THis relates to coherence, time space complexity.
   
5. Support for newer things - I have tried to support the ability to make new inventions still compatible with the model by enumerating the current ideas, and extending them as far as possible. For example, I have suggested the ability of viewers to be more than 2d - to 3d or 3+1 d, I have suggested the ability for meta-viewers to be able to arrange spatially, temporially, or use other spatio-temporal methods to arrange things. I have also abstracted the computation into functions, which any turing machine shouldbe able to do. However, there are often unforseen circumstances. For example, quantum computers, different chips might not support lazy function fusion or lazy evaluation etc, different output methods that do not rely on sight or sound (smell, touch, taste, direct brain manipulation of senses a la matrix?)
6. Speed - believe it or not, speed matters in the real world. I have tried to fix this by saying that the code will all be high level intent based code, that will be rewritten (like JIT compilation) to use optimisations, like code morphism (e.g. if a=0, then the code can be so much simpler.. etc)
7. Simplicity - while I try to adopt the onion-layer-knowledge approach, where only when you want to know about something do you have to know about it, it might be inevitable impossible
   

Viewers, Players and Naked Objects

1. A viewer is something that takes information of any sort, and generates a physical type of information. For example, a text viewer would take information of letters, and convert it into a 2d graphics. A text to speech viewer would take information of letters, and convert it into a 1+1d sound. Alone, this idea is pretty stupid, but if you include it with the concept of metaviewers, that are placed to view structure, and then structure other viewers physically. An example of a metaviewer is a windowing system, like X windows which take sound and puts it into a 2d structure, or a sound mixer, that takes sound and then puts it in a time structure. Other prominent examples include classes, list/array, tree, other data structures.
   
2. Video players, such as windows media player, vlc player, video-lan players are all great examples of viewers, because these programs do not do the playing. Instead, the playing is moved out of the program itself into the codecs. This makes it a flexible system, where new file formats are able to be accepted. Also, the use of containter formats makes this system even more flexible, as the containers can support interleaving, various codecs, various meta-data that is possibly orthogonal (techies love this word) to the main intent of the information. [These concepts of containter formats could be supported by either a in-file juxtaposition.....]
   
3. the naked object approach is when you can directly access information via editing a direct representation of the object on the screen. This can be seen as a simplified version of the
   viewer approach.
   

Userinterface - Just undetermined functions?

Well, the purpose of user interface is two fold. Firstly, we need the user interface to display information, and secondly, we use the interface to input information. Now, I will take this concept of the interface a little further, and abstract it from just the user, but to all interfaces - they are basically where the computer interacts with the outside world.

Now how does this relate to functions? Well, functions take information from a variety of sources, and then does things to it, and spit out answers. We have so far assumed magic tubes that feed the information from sources to the function. Although, we have discussed how the information will be outputted. I envisioned a system of viewers, which allow any structured information to be placed into meta viewers wihch convert structure to layout, and then viewers that convert information into textual/graphic representations. I have also envisioned that this entire structure of functions, viewers can be controlled by the user, after all the function composition is just some handy metainformation kept in the computer, that can be viewered.

But what about more complex things like interaction at an interface? FOr such a more complex thing, we have to take a look at how we often do things normally (I dont like that word). Well, we basically generally use a structure that would be called a event loop, which triggers linear series of actions (maybe a tree instead of a line). WHat do I mean? Well, when you click a button, that is triggered on the event loop. Then stuff happens and other interactions exist. We ask, what is the intent of htese event loops? The intent of these loops are to make choices.

How to do this in a lazy, function based world? Basically set up a function that processes events (event function), make it take input from the user interface, and then the lazyness takes care of the looping etc. But there is more. We can actually get the user interface for free, based on the event function, because we already know what information the event function wants, so we can generate a user interface for it.

However, I feel like this is just a interesting effect, not someting that you would like to know about. It would be kept at the bottom most level of the knowledge sphere. So a user will not be able to interact or even know about it until they decide to peel away the abstractions. In the end, however, when you have peeled away all the abstractions, you will reach the tao of computing.