Remote control any PC from any platform in the world!
[Previous]
Chris Wright - by Christopher B. Wright
[Next]
OS/2 e-Zine!

Go to a Printer Friendly version of this page



Christopher B. Wright is a technical writer in the Richmond, VA area, and has been using OS/2 Warp since January 95. He is also a member of Team OS/2.

Related Articles
What got you started?
Dream of Open Source
Christmas Wishlist
Open What?


Lash Back! - Join in the ongoing public discussion with our interactive forum. Be frank, be vicious, you can even be anonymous.

- or -

Blast Back! Send a private message directly to Christopher B. Wright with your thoughts:

Contact OS/2 e-Zine!

Sponsored links:
The OS/2 Supersite
WarpCast

Summary: What was that presentation at Warpstock that made all the programmers mad, and why should we embrace the idea instead? Chris Wright talks about this new way of creating software and how it'll make open-source look like a growing pain.

A Vision of Software Future

For those of you wondering, I will be continuing my look at Free Software and Open Source Licenses in about a month. I'm about to move into the Raleigh/Durham/Chapel Hill area of North Carolina, and that's taking up a lot of my time. (Any North Carolinians out there, feel free to drop me a line!)

In this issue we have an interview with Brad Wardell where he talks about the possibility of Stardock becoming the main point of sale for a new OS/2 client. Personally, I think it would be a Good Thing for OS/2. I also think it would be a good idea if OS/2 became Free Software in the same way Linux is today. Though it might seem so, I don't believe the two are mutually exclusive.

But if IBM released only what they owned today, we wouldn't have a complete operating system at all. For much of OS/2 is made up of parts that have been licensed from other companies.

Presentation Manager, for example, is licensed from Microsoft and so is the peer networking. Now in truth, OS/2 is a command-line operating system that doesn't need the PM, but can you really imagine most of us running OS/2 without the Workplace Shell? It's theoretically possible to take parts of an operating system and fill in the cracks with your own code, but this is a monumental task that I don't think can be handled by the current OS/2 development community. And that's why it's nice to know a company like Stardock is still enthusiastic enough about OS/2 to want to try and market it themselves. And despite what some people on Usenet may feel about them, Stardock has displayed a commitment to the OS/2 community that goes above and beyond the call of duty. So I'm keeping my fingers crossed, hoping that they can pull this off.

Yet for the record I also consider this a stopgap fix, for I feel that the technical advantages of an open source operating system are something that smaller OS communities absolutely must have in order to justify the time and expense it takes to keep using it.

How, then, shall we do this? How does one take a proprietary operating system, an operating system that's not just proprietary to one company but has components that are proprietary to MANY companies, and make it freely available to the world at large?

Last year during Warpstock '98 I heard an answer to that question in a session called "A Call To Arms." It's a radical idea. It may not be possible. But is was so breathtakingly bold and innovative that it made many of the people in that session very, very angry.

I was interested in the session because the speaker, Lynn Maxson, was very vigorously pushing it beforehand. Most people who heard about it thought it was going to be a "rant session," and I confess I did too. There were a few rant sessions at Warpstock (one of them was mine, I'm not ashamed to admit it), where people would basically say "OS/2 has problems, and it's all [insert scapegoat's name here] fault."

Mr. Maxson is an older man with long, long steel gray hair pulled back in a rather austere ponytail. He's a very vigorous and strong-spoken, strong willed man. The first time I saw him, I thought to myself "he looks like the kind of guy who would occasionally reminisce about the Chicago riots fondly." In other words, he was intimidating and he seemed a bit crazy. When he was telling people about his session, he told everyone "prepare to be offended." I had no idea what that meant, but that kind of sell always attracts me, so I showed up at his talk (a bit late, alas) expecting him to rail against IBM, rail against Microsoft, and rail against the computer press for screwing up the OS/2 market.

Mr. Maxson's session looked like it would be the mother of all rants. It wasn't. It was the plans for a revolution against the entire software industry; it was, indeed, a "call to arms."

His idea is deceptively simple: instead of "coding" a program using a language like C, C++ or Java, write a detailed software specification. Run that software specification through a logic engine. Let the logic engine write the code.

The idea already exists to a certain extent. At Warpstock '98 there were two products that almost did this: one was a traditional programming application called Visual Prolog, and one was a Java design tool. In both, instead of writing code, you told the program builder what you wanted the program to do, and it generated code for you. These applications had their limitations. With Visual Prolog, for example, you could only create single applications. But they were marvelous examples of how advanced technology has come, and how much more accessible programming is to the world at large today.

Think about it: computers don't "understand" programming languages. Programming languages weren't built for computers, they were created for people. Computers only "understand" the concepts "on" and "off," represented in binary, and there aren't too many people who actually program in binary (in fact, I think all ninteen of them live on a mountain somewhere and they actually rule the entire world in secret).

Programming languages were created to allow people to write commands that were a lot closer to the way we actually communicate. These commands are then translated into the language a computer understands when they are fed through a compiler.

Programming languages, however, are like any other kind of language: you have to learn to speak them correctly or the other party won't understand a damn thing you're trying to tell them.

And yet today we have programs that can approach the translation of sentences from, say Spanish to English and vice versa. A very crude version of this is the Babelfish translation engine at the search engine AltaVista and there are programs much more sophisticated that can do even better.

So why can't we apply this technology to application development? And ultimately, why can't we use that to create OS/2 on our own?

That was Mr. Maxson's hypothesis. We are almost on the verge, he claimed, of an era where we will have the computer power to feed a well-written software specification into a logic engine, where the logic engine will look for every single possible code combination that will meet those specifications, and ultimately spit out a working program in machine language. Perhaps not this year, but a few years from now, when Pentium V's are being marketed like Celerons are today, we'll be able to do this in a period of time that approaches acceptable.

It's the old idea that if you took an infinite number of monkeys and sat them down in front of an infinite number of typewriters for an infinite length of time, eventually one of them would, simply by hitting random keys, produce the entire works of William Shakespeare. Computers, being more single-minded and less susceptible to starvation than our Simian cousins, could do the same thing a lot more efficiently. And they'd have a few advantages that the monkeys would not:

  1. They wouldn't be expected to create something ex nihilo. A well-written software specification would give the logic engine a set of guidelines that it wouldn't have to stray from. In other words, you would be able to exclude a whole lot of useless combinations right at the beginning.
  2. Computer Programs can only do so many things anyway. A program is itself constrained in what it can do, and therefore, a whole lot of other combinations aren't even possible.
  3. Therefore, theoretically, it should be possible for a logic engine to say "given these requirements, I can come up with this product."

Theoretically.

The problem, of course, is that I'm not a programmer so I don't really know how hard this is, or how many combinations a logic engine would have to go through to come up with a working product. I asked some people after the presentation who were programmers what they thought of it, and public opinion seemed split right down the middle between people who thought it might work, and people who were convinced that it would never work.

I also noticed that during the presentation a lot of people really did look angry. Some people actually got up and left. Why? Because Mr. Maxson was essentially talking about the end of a programmer's career (as we conceive it today, anyway.)

In fact, I have a personal reason for wanting Mr. Maxson's idea to succeed. I'm a technical writer. If Mr. Maxson is correct, and programs can be created directly through specifications, someday my skills will be in pressing demand. Someday I'll be able to charge a few hundred dollars an hour for a client who really wants a software specification for a product they'd like to use. The mind boggles, the mouth waters...

All greed aside, there would be a lot of advantages to this method of application development, the most obvious one for OS/2 users being: we could write a specification that describes OS/2 and create an OS/2 clone. We could write specifications for device drivers and have device drivers for previously unsupported technology. That's not a walk in the park, that's not something that can be done easily, but it is something that more people than just programmers can participate in. It opens the pool of potential developers much, much wider than even the Open Source movement does. Anyone who can research information, make sense of technical specifications and pay close attention to detail would be able to participate in the development of an application, even if they didn't really know how to write one themselves.

OS/2 could be replaced - piece by piece - with something developed this way. Specifications are, by their very nature, "open source." If someone can read it, someone can implement it. It's Free Software for the masses, it's something you can develop without being a hacker. And it's something that can be used to replace proprietary systems without having to reverse engineer anything.

If it works.

This, of course, is the big question: will Mr. Maxson's idea work? It seems possible in my opinion, but I'll be the first to admit that I'm not really qualified to say. The only reason I can think of why this wouldn't work is that we don't have the hardware for it. But even I don't see this as a true obstacle, because computers will continue to increase in power year after year. Five years from now, the most powerful computer you can buy today will look like a toy. Five years from now, we'll have the computing power to do this.

I'm a big believer in Lynn Maxson's presentation. I don't know what to do about it, I don't know how to make it happen, but I want to see it come to pass and watch it revolutionize the way software is written.

And five years from now, it just might be possible to take this idea and create an operating system out of it; an operating sytsem that isn't really owned by anyone per se, because hey, it's just a specification. Open Specs, baby. The Cathedral and Bazaar models will be supplanted by the Open Mic Night model of software development.

* * *

Wanted: All those people who got angry and left that presentation way back in Warpstock 98. Get angry all over again and talk about it in our interactive form. We want to know why you think this brilliant idea won't work. Oh, and supporters are welcome too ;-)

[Previous]
 [Index]
 [Feedback]
 [Next]
Copyright © 1999 - Falcon Networking ISSN 1203-5696
February 16, 1999