Dreaming my life away.

"People say I'm Crazy, dreaming my life away.." John Lennon.

I woke up with a couple of strange dreams the last two mornings. Yesterday I dreamed that Jesus touched me, and I felt a surge of peaceful relief.

Today I dreamed that I presented my thesis topic before a commitee at Tech. It didn't go as well. I got shot down. Definitely less enjoyable than the Jesus dream. With Rich leaving Tech I wonder if I will ever even get to a thesis defense. I think that's what this dream was about.

Last couple of weeks I've been playing with software. I like it. I enjoy writing software for a living, so when I get a taste of development, I starting thinking all about building up my consulting software company, and not worrying about gettting a Ph.D. On the other hand, I don't want to leave CycleFree work, and I can see no viable way of advancing it without joining academia. To join academia I need a Ph.D., and I have to get a topic.

My biggest problem is that I never have been very disciplined at tackling a small problem and seeing it through to the end. I keep thinking about software in the large, and spread my thought a million miles wide and only a few inches deep. Software has become so specialized. I still believe in a better generalized approach, but to solve specific problems you have to use the existing tools and embrace the philosopical methodology on which these tools were built.

So, if I am to complete a thessis, what would be the topic? I will list some of the areas that I think about.

1) Formalize CycleFree model.

This is probably what my thesis should be. This would involve learning the pi calculus, and all of the other theoretical ways of reasoning about software. Consuming the Pierce and Van Roy books, becoming proficient at UML speak, and becoming a general purpose programming language theory guy. I could probably do this, but I'm not real enthusiastic about it. I like building things, not so much theorizing about things. Perhaps I'm not intellectually deep enough to really make a big difference as a theory guy. My greatest assest is my honesty, and my admission that software is too complex to handle in its current form, I'm constantly searching for simplicity, and the programming theory guys can get real impressed with being able to express complexity mathematically. Maybe I'm full of crap about this. I tend to deride the importance of things, until I understand them. Maybe if I just did this stuff, it would all work out okay in the end.

I think CycleFree is a big thing that fixes the major problem in software today, but there is a lot more work to be done in this area. I am more enthusiastic about doing something that would advance CycleFree, but this might not be the direct path to getting a Ph.D. So maybe I get the Ph.D. first, get set up in an Academic position, and then work on the stuff that interests me. However, maybe one of these ideas that interest me would make a thesis topic itself.

Here are some of these other ideas.

2) Memeory management. CycleFree gets rid of the thread abstraction, but to really clean things up we need to tackle memory visibility. Abstractly, it is real simple to do. Don't allow data access to items that have the potential fo concurrency problems. Start with encapsultating all data in objects, and initially only the member methods of the object are allowed to access the variables. If there are no event routines defined for the object (no sources of potential concurrent) access, then the user of one of these objects would be able to access public atrribute members directly. If there are event routines, perhaps it is necessary to examine what data is potentially exposed to concurrent access, and then this data is limited to access by member methods only.

The biggest problem with enforcing strict memory visibility shielded against concurrent access is the overhead that would result from having to copy memory to get data to flow from one context to another. I think there is a way to fix this problem. The solution is to have a return type that allows the object to be "exchanged" with the caller's object. We could express this explicitly at the langauge level, but I like these sorts of things to be done by the complier/environment. It really is only needed on the "return." Something like

Class Example()
{
BigObject x;

method1()
{

return x;
}

method2()
{
return x.attribute;
}
}

If BigObject is a couple of K big, wouldn't it be nice to simple exchange memory pointers rather than copy the data? The compiler should be able to figure out what size object it would make sense to exchange pointers rather than copy data.

At the language level we would have to change the meaning of the return statement, to say that a returned obejct becomes "undefined." So, for instance, method 2 might need a check to see if Big Object were defined before it could test an attribute.

Being able to exchange objects provides a way to maintain encapsulation and still support efficient memory passing from one context to another. I think this could be expanded into a topic on its own merits.

3) Build time optimizations

Another area I have been thinking about for a while is a three step compile/build/link process to support efficient memory utilization in small memory processors. Something like the MSP 430 or the 8051. People still write in C instead of C++ because theyt don't want the extra overhead that comes from making data access releative to the object pointer instead of direct. For instance, the logical OO way to support a COM driver is to write an class to do this function. If you use two COM ports, then you have two instances of this class. However, many small memory model devices may only use one instance of the COM driver. With only one instance, more efficient direct memory addressing could be used. There should be no need for less memory efficient addressing just because the code was written as a class in C++. I think there are a number of "build time" optimizations that could be deployed. Theory people may tend to view this as Master's level work, but I'm interested in it, and think there could be a thesis in this stuff alone.

4) Killing Exceptions

The CycleFree model provides an "event" mechanism that allows lower level contexts to signal higher level contexts when an event occurs. This mechanism is similar in form to exceptions, and the traditional exception mechanism could be eliminated. I think it could be much improved, in fact. The current exceptiuon mechanism allows "termination semantics" with handlers defined on the call stack. There is no reason that the event mechinism couldn't double up for this exact same purpose. An "until" statement could indicate the higher level object desire to use termination semantics to handle an event. One immediate benefit of this approach is its flexibility as compared with traditional exception handling. Traditional exceptions FORCE the higher level to use termination semantics to handle exceptions, while the CycleFree approach allows the higher level context to determine how to handle the event. Events could be handled by contexts OUTSIDE of the current call chain.

There is something intuitively pleasing about changing exception semantics. Low level code should not dictate how higher level code should handle things. Higher level code knows more; it should be in control.

5) Killing contexts.

Killing objects off is often a big problem. In a traditional program, Destructors or Finalizers must be run to clean up things before obejcts are deleted. And programs must release resources, and junk before they are terminated. In my CycleFree view of the world, the distinction between an "object" and a "program," would disappear, and when you kill something, you kill everything it "encompasses." This "encompassing relationship" is a little fuzzy, even in my own mind, but then again I haven't had a second cup of coffee yet this morning. I think there is a thesis in just managing the killing of things.

I would like to put all of these ideas together, (along with CycleFree) and define a new language, and build process targeted for small memory model processors. Why small memory model? Because we can maybe get some adopters in this market. The CycleFree stuff has its best benefits in large component oriented projects, but there is no way we can get a foothold in this market. The whole chicken before the egg infrastructure thing that Szyperski alluded to in his Software Ecosystems book that depressed me for a couple of months.

Should I get a Ph.D. to do this stuff? I'm still on the fence about this one, but taking baby steps down this path. I'm going to have to start running soon if I ever expect to finish before I'm sixty.

I would still prefer to work for Mirosoft and be paid a living wage to work on the things that interest me, but unless Jim Allchin comes down from the mountain and rescues me from the hellish pit I have dug, this will be unlikely.

Maybe I can get a reality T.V. show like Paris Hilton...

DirectShow

I've been away from thining about a thesis topic for a few weeks. I have been working on a project for a client in New Mexico that wants a multi-windowed application displaying streaming video. This has taken me into digging through Microsoft's architecture for Low Level Video and Audio support, show called "DirectShow." This stuff is based on the COM model, and Microsoft has yet to replace it with a .NET equivalent.

This is a good project as it is stimulating some parts of my brain that haven't been used for a few years. I keep translating everything into how it would be if it were CycleFree. It would be better!

CycleFree Language

If CycleFree is going to catch on, there needs to be a CycleFree Language. This has occupied my thoughts for a while.

Other day, in the bookstore, I flipped through an interesting book on game programming for Windows. When I get a spare $60, I'll buy it. Looking at the code, it is a messy way to program. I wanted to highlight a bunch of stuff. One remark was the author's fondness for global variables. "Because they are fast." Being fast is still relevant. But why can't the compiler/lanugage environment support high level abstracts and data hiding without sacrificing speed? If all data is encapulated in an object, it's a good thing. But if there is only one static instance of a class type, why can't the code generation figure out to use direct memory addressing.

Currently the compiler makes that decision at compile time, and it does not know how many clients there will be to use a Class. For this reason data references are calculated relative to the object data pointer. Slower. But what if the traditional two step compile/link process was replaced with a three step compile/build/link process in which compile process only operated on Classes, and the build process defined the instances to be used in a program. These are my thoughts this morning.

Concepts, techniques and Models of Computer Programming

This is the title of the Peter Van Roy and Seif Haridi book I have been reading.

The book is well written. There is a clarity of thinking about different programming models that is expressed, (declarative, functional, dataflow, object-oriented) in which Van Roy and Haridi break down the computational model based on what key element is required in the abstract kernel language to implement the feature. I think this is a good way of thinking, and I should model this approach for the CycleFree Stuff.

The abstract kernel language is higher-level than assembly (or virtual machine code), but it lower-level than the programming language itself. For instance, the addition of explicit state and inheritance mechanisms to the kernel is needed to support object oriented programming.

I have just scanned through this book, and haven’t yet given it its full due, but it is clear to me that in the CycleFree computational model, there is a method of programming that has not been discovered and explained by Van Roy and Haridi.

They explain that the addition of explicit state and concurrency creates a dangerous programming model and their advice is to avoid using this model as much as possible. They point out that there are other concurrent programming models (dataflow with lazy execution) that are much safer. I think CycleFree brings safety to the explict state/concurrent programming model.

The overall theme of the book is that there are different programming models, and different jobs require different ways of thinking about computing. The computer scientist should know all of the models and select the right tool for the job. Their Mozart programming environment supports all of the different computing models that they have identified.

I don’t think about software quite the same way. Since I first started writing software, I have always been very visual in my thinking about code. While programming can resemble mathematics, for most of the industry jobs I have worked on, it has almost always come down to a bunch of state-full objects interacting with one-another. I have worked with many different multitasking models, low level synchronization, monitors, message passing; as well as single threaded event driven programs. Instead of many programming mechanisms, I have always prefered to use as few as possible. I endeavor to make the software structure as simple as possible and still get the job done. Mozart might be a great teaching tool, but I would hate to build a commercial system with it.

When you build a commercial system, it gets BIG and it EVOLVES. If you have many different computational models at your disposal, and many different programmers, you will get a lot of interactions between different models and styles of programming. The result invariably becomes a system that is almost impossible to decipher. This has been my commercial experience.

However, the way of reasoning about Programming Language is excellent. Discussion the Practical Programming Language Syntax, and showing how it is supported by underlying Abstract Kernel Semnatics. This needs to be done for the CycleFree model.

CycleFree RTOS

If I’m going to do a Ph.D., I need a thesis proposal. Which got me thinking about what I want to do. I was digging around on my computer and came across a great letter. It was written two years ago to my new Microsoft buddy, explaining why Microsoft needed the CycleFree Patent.
There was some really good stuff in that letter.

First there was a summary stuff about what is CycleFree Software:

1) It is an evolution beyond the object model, invocation hierarchy is enforced.
2) The enforcement of invocation hierarchy means the following:
a. The complexity of possible program paths is reduced exponentially
b. Mathematical elimination of certain bugs, reentrancy, unbounded inter-object recursion, etc. is a result.
c. An event mechanism (signal) is provided to initiate communication from lower to higher objects.
d. Event Routines can be scheduled for execution by the CycleFree kernel.
e. Concurrency can be provided implicitly as can synchronization.
f. It becomes easier to provide formal program verification
3) The CycleFree Kernel can be implemented multiple ways.
a. As a multi-threaded kernel, it can work on top of existing O/S.
b. As a virtual machine kernel, can replace stack-based invocations with context-chaining. This would speed execution in small memory models by reducing the overall memory requirements,
no need to allocate stacks, and eliminating the run-time checking of stack overflow.

Then I followed with some sales hype:

If you have this visual picture in your mind, then you understand the DRAMATIC potential of this technology. Some degree of FORMAL program correctness can be discussed intelligently, and programs can move from being big things that even we experts are unsure of their correctness, to organized systems that are guaranteed not to have many of the transient program errors that we experience today.

Then I explained three potential attacks on Microsoft Windows Franchise.

1) Head-On with full featured alternatives (the only viable one is open source Linux)
2) From the Top, with application environments that make the underlying operating system a moot point, (e.g. Java programming)
3) From the bottom. With real-time operating systems that grow in importance as computers get more and more ubiquitous.

Then I identified the bottom-up, RTOS, market as the most vulnerable area for Windows:

Microsoft is well equipped to fight the battle on fronts (1) & (2), because you are delivering a lot of functionality, and with the delivery of a bunch of stuff, you have a checkbook and the leadership to get behind any initiative and fight a good battle. Witness the C# common run-time .NET initiative as an alternative to Java.

I believe Microsoft is most vulnerable on (3). Here is the problem Microsoft faces. In order to justify a Windows solution on embedded devices (many without even a UI) the core O/S needs to be stripped down to a minimum. Once the core is stripped to a minimum, there is simply no compelling reason why anyone would select Windows over many other alternatives (e.g. VxWorks). Without the COMPLEXITY, the proprietary Windows CE operating system does not provide the benefits required to justify the cost. How do you get people to commit to Windows CE?

Then I closed by listing the benefits that CycleFree could bring to Microsoft.

With the patent, Microsoft can build a tiny kernel, with little more than the CycleFree scheduling algorithm. This would be a CycleFree embedded O/S perhaps with an option to execute a virtual Machine, or compiled code. The kernel can provide concurrency implicitly and the great benefits of CycleFree applications can be touted. Here is a real TECHNICAL reason to use a proprietary O/S, with a clear technical advantage over competition. (Without stacks, the memory model could be much more efficient). I could see such an operating system being selected by NASA to replace VxWorks (used on the Mars pathfinder). The PR value of having THE mission critical embedded O/S would be great for Microsoft.

The story that Open Source advocates is that it takes “many eyes to make reliable software.” This has been Microsoft’s biggest weakness. The rejoinder that it “takes mathematics to make reliable software” kills this Open Source argument.

Of course, I rambled on a bit in between making these points; but all-in-all, a good letter.

I’m thinking I need to focus on research that would result in a CycleFree RTOS. Something that would get used. There is a lot in this area to think about.

What do I know?

What do I know about software? It doesn’t feel like much, but I’ve been doing it for over twenty years so there is some core competency is some areas. I have experience in these areas:

1) Embedded Microcontrollers, programmed in C and Assembly.

2) The unix process model, programming with standard input and output on top of a files system with Console I/O.

3) Shell programming with C-shell and Korn scripts.

4) Windows application development, old C style programming with SDK and Windows API calls, and MFC/C++ style.

5) Macintosh application development era early 1990s.

6) Visual Basic 6.0 Application development with Forms.

7) SQL database queries, mostly in VB or Microsoft Access environment.

8) Multitasking systems, vxWorks, PSos, VRTX, Windows threads.

Here is what I know a little bit about:

Web Services Languages

I have read a lot about the Java Virtual Machine, Microsoft’s Common Language Runtime, and know some of the architectural differences between Java and C#, but I have not build a commercial app using either technology.

Web Development Tools
I know HTML and XML basics, and I know what is going on when HTTP is does a “GET” on a URL. I have played with Microsoft Front Page, and a little Dream Weaver, but I am not sure what is going on with Dymanic HTML, Active Server Pages, FLASH, or any of the UI oriented Web tools. I've hacked together some JavaScripts, but my 17 year old daughter is probably better than I at directly editing HTML pages. I could learn all this web junk I suppose, but it changes so fast, CGI scripts, PERL, PYTHON, Component Software, I don’t have a big picture sense of where all this technology is going.

Why did I not dig into the WEB stuff the same way I did all the other technology earlier in my career? Maybe it is because I am older and don’t have the gas to play like I used to. But I don’t think this is it. My sense is that the whole application development is moving to competing FRAMEWORKS, where programming is simple putting together the BLOCKS that have already been developed for the Framework. Just as I lwas learning AWT in Java, it became passé, replaced with the more sophisticated SWING framework.

I think the reason I haven’t dug too deeply on the web stuff is because of the sense that the whole traditional application development market is going the way of the dinosaur. These web interfaces will be assembled overseas where developers may be paid under $10,000 a year. I worked for a Romanian company that was doing this. I became a spec writer for offshore development.

I have also neglected the whole Rational Rose development methodology, with “use cases” and the stick figure men. I once started to wade through these manuals, but I knew my days at NIVIS were numbered, and combing through the hype to harvest the few nuggets had limited returns

So where can I go from here? I know embedded microcontroller environments and limited memory/threaded/real time stuff as good as anyone on the planet. I should probably specialize in this domain, and target the CycleFree stuff to small memory applications.

I always thought of the CycleFree stuff as perfect for mainstream languages on which everything would be built, an alternative to C# or Java. But Szyperski is right, the infrastructure development required to compete in that domain precludes getting people to take notice of this technology. You are not going to rebuild an entire Java Bean development enviroment just to get CycleFree;s implicit concurrency benefit.

I think I have to start thinking of an alternative language to C for embedded device development. Think small. That's that ticket.

Return to School at Fifty?

Sounds like a crazy idea. But it is what I am considering. Getting a Ph.D. at 50. I have the support of three strong academic professors, which is more than I had twenty years ago, so maybe it is possible.

What else can be done with CycleFree Software?

I will record my progress on this blog. First task, write a thesis proposal. Let's see how this goes...