Older blog entries for wen (starting at number 1)

Since I can't post a reply to the software reliability article yet...

I think that people are comparing apples and oranges when comparing things like microwave and VCR with PCs. These are very simple, single/few-purposed devices that have predetermined components that are likewise as simple. The PC is not that.

The PC, to me, will always be a multipurpose, mass- distributed experiemental device that happens to serve end- user purposes. This is why hackers love working with PCs - PCs can be easily programmed and reconfigured and upgraded to do a myriad of things. The environment will remain dynamic and upgrade-envy and commercial marketing efforts and (a small part) the need to constant and continuing effort to improve upon the past.

What I am saying about software reliability on PC or similar multipurpose, multifunction platforms is that it's damn near impossible to get the kind of reliability that VCRs and appliances can achieve, of course, because PCs and such are always a work in progress. They are not an end product.

I do believe, however, that some more end products will be coming soon. Using the PC to emulate an end product will be ok, but more specifically, people may be be more readily accepting of network computers if the network computers can do much of what they need and if the computing facility is offered to them as a service (yes, I'm aware it's like Microsoft's proposed subscription model for software, part of that .NET thingamajig). I believe at some point, there will be very little you can add software like word processing programs or spreadsheet programs that will be more than a slight incremental improvement. In other words, the product "matures" and once that happens, it is ripe for being implemented as an "end product"

This whole idea hinges on computing power as a service (like a utility like electricity or telephone, etc). Much like the Lou Gerstner's quote in this xmlhack article.

Bottom line: PC software reliability is not purely a programmer problem as it is a complexity issue in a world where the platform being used is a rapidly and constantly moving target. If we want software reliability, we need to nail down snapshots of hardware and software and produce end products as such.

Of couse, simplicity in any kind of software will always go a long way towards reliability. I'm sure the software on airplanes and space shuttles work reliably, and on much older hardware - they are end products.

I wonder how hard it would be to create an XML application that could encase and express any programming language concept. A universal pseudo programming language that can be specified in XML, that is. It may be a lot of effort for no reason, but I think that the open source community, more than anyone else, would benefit from it.

All programming languages have their own syntax(es?). But when you cut through all the difference in vocabulary and stuff, the grammar is roughly similar. The biggest differences you might encounter would be object-oriented vs. procedural programming. I'm sure there are others.

But even object-oriented programming is procedural in its methods. OOP has different conceptual structure, but the basic elements - variables vs. attributes, functions vs. methods - are similar enough that we can treat them as roughly similar.

Enter psuedo code - the language neutral way to express some programming concept/idea/algorithm. We specify some programming concept using pseudo code as a service to those who are not familiar with the programming language we are using. Also, it eases the programming language prejudices in the programming community. The psuedo code should be even easier to understand than the high level programming languages that were designed to make it easier for English speaking people to understand. Implementing the pseudo code in a specific programming language is a simple matter of someone taking the time to put the concept into code.

If there was a way to specify pseudo code in a consistent, standard format, then producing the code for a specific programming language could be pretty trivial (or so I assume - this will haunt me, I'm sure).

Enter XML. Ever since I started learning about XML, I became thoroughly enamored with XSLT. What a great, powerful concept! I thought that the cornerstones (for me anyway) of what makes XML great were:
1. portability/extensibility/interoperability,
2. General purpose parsing,
3. Transformation,
4. Validation/DTD/Schema enforceability.

So I thought, why not express and store pseudo code or any other programming concept in XML? If an XML application were created with the appropriate DTDs or schemas created, the XML-stored pseudo code should be reasonable human readable. I think even basic syntax can be checked using XML parser's facilities. The most important thing for me, however, (this was the point that I've been trying to get to all this time) is tranformation.

By createing appropriate XSLT files to transform the pseudo code to code for a specific language, we gain in several ways (and maybe lose in a few):

Advantages:
- Libraries of algorithms can be stored in a language- neutral way, and reconstituted (just add water!) into any specific language just by using the appropriate XSLT transformations.
- Encourage code sharing across not only platforms, but also across programming languages.
- Code can be (I think) checked for rudimentary syntax problems.

Disadvantages:
- Programmers may become lazy and not want to understand a piece of code. Just transform-cut-paste.
- I don't know how difficult it is to implement such a system that would be able to effectively accommodate any programming language past, present, and future.
- The psuedo code may be more difficult to read by humans (ah, but wait! There could be an XSLT transformation that can be used to produce more human friendly output!).

I don't even know if the whole idea is sane, but it sure seems cool to me. I'd love to work on something like this. I would also love to see what other people may think of this.