Making Your Computer Into a Parallel You

I have previously introduced my concept of gramlets which is a whole bunch of single function programs that do one thing only. They are standalone programs of a tiny size, and can be invoked to operate on anything and do what they do. One example is the Addition Gramlet For Integers that will add any integers given to it as parameters and return the sum. This is but a trivial example.

Where gramlets will come to shine, is in the evolution of the personal computer. Personal computers have come a long way, and soon your phone will be your personal computer. Or it might be in the fabric of your jacket, or stuck in your ear -- it doesn't matter. The personal computer will continue to evolve.

It will become smaller and smaller, and can even off-load large processing tasks to the cloud. Douglas Adams may not have been far off the mark, when he said in the Hitchhiker's Guide to the Galaxy that the Earth was one huge computer.

The operating system for the personal computer must evolve as well. Gone will be the days of the dumb desktop. Your personal computer will be a learning machine that will learn all about you, anticipate your needs and handle most of the digital aspects of your life autonomously.

To become a parallel you, the operating system of the personal computer will have to ditch the ancient Microsoft paradigm and turn into a massively parallel system, just like the human brain.

Input will be fed into your personal computer via any means (web, data entry by scanner, camera etc) and the computer will take care of it. The input will be fed into all of the gramlets. They will fire if they recognize that the data is meant for them and process it.

For example, an image is fed in. The word processor and speech processor gramlet ignore it. The Filing Gramlet puts it away with the rest of the pictures, but first it passes it to the ident unit which analyses the picture to see if it is a picture of you, friends, family or whatever. Then the image is passed to the ImageQualityGramlet which adjusts the white balance, removes the red eye and passes it back for filing in the appropriate place. In the process, every Gramlet saw this input, and if the threshold was met, the gramlet recognized the data and did its job on it.

A parallel system of gramlets that learn by watching you will be the hallmark of the new personal computer operating system.

Anyone dealing with you will not be able to tell if it is really you, or the parallel you embedded in your personal computer. This will be like the graphic at the top of this post. Are the lines parallel or not? The answer will surprise you.

Morning Gramlets

Gramlets are programlets. Take a software program and bust it into pieces making each method a standalone program. Can you imagine how memory efficient and fast a program like that would be? It is a programming methodology whose time has come. Read the blog entry immediately below this one for my introduction to gramlets.

To make gramlets work, you would need a persistent supervisor of menus (or gramlet supermen) program that was the menu director. It would discover all of the gramlets that you have loaded or available online and give you menu choices to call them.

Incorporated into the gramlet supermen would be the ability to create macros that strings gramlets together to form functions.

The neat thing is that there could be a gramlet exchange much like a stock exchange where one could buy individual gramlets or gramlets strung together by macros or a connector gramlet.

Half-Baked Gramlets

Warning: This idea is just half-baked, but I wanted to capture the meme before I lost it.

I was shocked with nostalgia to see a sample of BASIC programming lately. It was a very simple example and looked something like this:

10 REM BASIC Program

20 REM

30 PRINT

40 FOR I=1 TO 10

50 PRINT I

60 NEXT I

70 PRINT

80 END

This was way before Object Oriented Programming. It is a trivial example of the language. In BASIC programs that actually did real work there were sub-routines, goto statements and various loops and such all in one monolithic program.

These sorts of programs were the original layer of abstraction from programming a computer with wires. The programming of computers with a language sort of led us down the alternate path of programming in the same way that Alexander Graham Bell diverted us from our digital future with an analog telephone for all those years. I am not saying that programming with a language instead of wires was a mistake, just saying that with my newly-hatched idea, monolithic programs like BASIC heavily influences us today, and in perhaps the wrong way.

The huge monolithic programs like BASIC, COBOL and even AS400 were bulky and unwieldy. Subroutines provided the first reusable code, and perhaps are the beginnings of object oriented programming. Just maybe though, object oriented programming is not enough.

The legacy of the original monolithic programs still haunts us. For example, have you opened Microsoft Word lately. It is, I am sure, an object oriented program, and yet it is a huge accretion of objects that make it indistinguishable from the old huge BASIC programs of long ago. There are functions to spell-check. There are functions for mail-merge. There are functions to generate table of contents. When the change came from Word2003 to Word2007, I had to re-learn how to find the things that I wanted. It is so bulky, that if I want to capture some text, I just use Notepad, whereas before I used to use Word.

Then I started developing with Windows Mobile. Of course, you can't use the same memory-hogging techniques that go into programs like Word. With devices getting smaller and smaller, even with Moores Law still having room to expand, having processing power in all places is the goal. To do that, you have to have programs that are super memory efficient. Just like cars running on less gas, you have to have programs running on less memory.

That is where I was struck with the idea of Programlets, or Gramlets. (Like I say, this idea is half-baked, and I haven't yet Googled to see if anyone is doing it). Gramlets are mini-programs broken down into the smallest logical components. And each Gramlet has a method to invoke a Runner which invokes another Gramlet.

Just like Neural Nets, instead of firing up a large monolithic program like Word just to do one function, you fire up a program that does just one function. The stack and heap footprints would be very small, and the program would exit once you have finished the function. Here is an example in kiddie-scripting C# for the runner program:

class Runner

{

static void Main(string[] args)

{

System.Diagnostics.Process.Start(args[0]);

}

}

These are very trivial examples, but if you had to do mathematical addition, you would call the runner to call the adder and feed it two numbers:

class AdderInt

{

static int Main(int[] args)

{

return args[0] + args[1];

}

}

A more useful example, is lets say you have a gramlet to catch byte stream to create a document. The byte stream capture calls the runner to open a Notepad gramlet. Once the byte stream is captured, it exits. If you wanted to do a spellcheck, you would call a spellcheck gramlet. The spellcheck gramlet could be used anywhere -- in a browser, in a spreadsheet -- where ever it was needed.

Each gramlet is a standalone executable. This way, one could program by linking gramlets. This would be the ultimate manifestation Agile Developments.

This half-baked idea is going back into the oven for some more baking.