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...