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
40 FOR I=1 TO 10
50 PRINT I
60 NEXT I
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:
static void Main(string args)
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:
static int Main(int args)
return args + args;
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.