What WordPerfect Corp Should Have Done in the 1980s (or, the Reasons They Did Not Hire Me)

A question about running Unix WP 5 on a modern Debian system brought back some ancient memories.

I was at BYU in the mid-'80s, when WordPerfect was becoming the standard word processor. I knew the guy who managed the Macintosh version development for the first several years. Took classes from one of the founders of the company. Etc.

Tried to get a job there. I was headed in a different direction than they were, so they turned me down.

One of Satellite Software International's products was a FORTH language system which I used (not very effectively) as an intern at IBM when I was recovering from a broken engagement in 1986 or so.

(Heh. As I write this, the English wikipedia page on WordPerfect has it as Satellite Systems International, which is a completely different company. The Japanese page has it correct. There's one kind of bit rot.)

My memory is that Dr. Ashton once said, in class or lab, something about early versions of WordPerfect being implemented in FORTH, and that the C code base had a lot of FORTH-isms for quite a while. (This would not be surprising. FORTH, like LISP, is structured well for text stream processing, which is a lot of what made WordPerfect such a successful product.)

If I could have gotten Dr. Ashton's ear --

Never saw Bruce Bastion on campus that I remember, but I did have some opportunities to talk with Dr. Ashton, since I took a class from him. I tried to talk FORTH and the 6809 up to him. Didn't find out about their FORTH language system product until some time after that class. This was just another example of the social, political, market, non-technical stuff going on at the time, and my studied cluelessness.

I daydreamed while doing my homework, about getting into that company and building a "WordPerfect PC" using the 6809 or the 68000. About re-writing, as I assumed, the code in FORTH, and thus making it possible for the customers to add custom modules.

About using WordPerfect and a canonical WordPerfect Personal Computer as a wedge to push a new cross-platform freedom-enabling OS based on constructing a Unix-like system on the foundations of FORTH as a run-time and library model.

I was enamored with FORTH. They were moving the code base for WordPerfect along on standard C.

-- Don't get me wrong. I like C, to play with. It's lacking in certain features to support large projects, and C++ and Java only manage to point their fingers sort of in the right directions.

-- And not that FORTH did/does not need extending to handle some of the things that C handles well. But FORTH has the extensibility that C still lacks. (And I know that extensibility is a two-edged sword, the tendencies of source code to slip away from standards. And I now have an idea how most FORTH enthusiasts have cut themselves carelessly wielding that sword)

I was interested in the cooperative and open models of software development. They were interested in capitalizing their intellectual property.

I was anxious to set up viable opposition to the Microsoft Way. They were interested in a cozy third-party relationship with Microsoft.

I do not understand why anyone would want to voluntarily enter into a relationship with either Microsoft or Intel. It was obvious to me back then, that both companies were hell-bent on pushing their (quite patently false) claims of being the standard, pushing until they had a de-facto monopoly. And anyone who knows history knows the tyranny of monopolies.

Bell Telephone was the only counter-example of a non-evil monopoly, and the only reason they kept their nose (mostly) clean was that the government was breathing down their back.

There seem to be sirens lounging and singing on the rocks of technology --

Technology can be built into systems. (Computers are the archetype of this.)

Systems are great tools for tying customer relationships.

If you can discover it first, keep it secret, get a patent, you can tie your customers to your technology and then you have a guaranteed revenue stream.

It's a siren song.

These kinds of royal grants have been the tools of tyrants in practically every age, and the wedge they form in the social structures of tyranny has proven to be the most effective and destructive tool in undoing the same tyranny.

Unfortunately, innocent bystanders usually get hurt in the wars that result, by the thousands and millions.

That's the reason the US Constitution said "limited time". Temporary stewardship over part of the intellectual and creative commons, derived from the facts of individually-implemented ambition. None of this nonsense about making property out of the social artifacts of the intellectual domain.

No one was supposed to be able to keep control of their inventions and writings their whole lives.

Otherwise tyranny results.

Well, I was disappointed that people who should have been steeped in the traditions of freedom at BYU should be taking their company right into the heart of tyrannical traditions.

And they weren't interested in an idealistic, naive fourth-year sophomore like me.

Now, who's naive?

I guess we all are.

You know, here's the whole reason idolatry is so strictly discouraged in the Bible:

Systems.

The tyrannical pseudo-religious systems that idols represent.

Until we, as a race, become mature enough to quit worshipping systems, I think God will never let us build a proper computer operating system.

powerful programming languages -- php5 and suhosin

PHP5 is pretty powerful.

Powerful languages have a problem. They allow things to happen that the language designer hasn't even imagined. Some of those things sometimes allow mean-spirited sorts of people to attack servers, steal credit card numbers, and make general malicious mischief.

So PHP version 5.3 needed a band-aid, to help the naive web programmer avoid blowing him/herself away with good intentions poorly implemented. The band-aid was called "suhosin".

Unfortunately, the three German engineers who developed suhosin seem to have gotten busy doing other things, according to this post at Arch Linux. And the current suhosin doesn't match the current version of php5. [update: If you fail to follow all of the links Pierre provides, at least look at this mailing list post from one of suhosin's developers.]

I had been thinking about brushing up my php skills, so I had installed php. With the upgrade to 5.4 in Debian wheezy, suhosin doesn't load. Instead, it fills my error log files with complaints of incompatibility.

So I checked, and nothing else gets removed when I remove php5. So I removed it.

When I really need it again, I'll install it again. Maybe by that time the guys who run php will have folded all of the functionality of suhosin into the language itself.

But this is not a solution, it's a knee-jerk reaction. More first-aid fixes that don't really do the full job.

This highlights one of the problems in software architecture: The power of a powerful language is in its expressiveness. To the more expressive a language is, the fewer limits there are to the things which can be expressed in it. But security in current practice requires setting limits. We need to give the programmer power, but we need to take power away from the end user.

There is an inherent conflict here. I mean, sure, we could go the direction taken with Java, using execution policies to tune the expressiveness available in the end-user's context, but that has its own set of traps --

• Will some of the programmers remember to set up the policies?
• Do the programmers understand how the policies are used to secure the system?
• Does the policy end up preventing the end user from doing important things?

It is interesting that there are parallel issues in law, regulation, and government policy.

• Do legislators understand the interaction with law and regulation and the potentials for abusing the laws and regulations?
• How does the government protect the people's security without inducing more chances for treacherous abuse?
• And how can a government make the people secure without excessively limiting their freedoms? 

Systems have complicated interactions. The more complicated the systems are, the more loopholes (ergo, vulnerabilities) they have. This is a known problem with systems, and it applies as much to computer systems as it does to bureaucracies.

The answer of the US Constitution was "Use checks and balances and keep it simple." Both of these principles have been long ago set aside as legislators and special interest groups press for responsive government.

Is there something wrong here?

Can we as general members of society learn enough about systems to pare back the legal kruft that is currently overburdening (and overly burdening) society (and is a primary cause of budget problems, not to mention the bureaucratic abuses that show every sign of continuing to increase)?

Can these principles be applied to computer systems? If they can, how?

I think they can, but I'm not sure anyone reading this would understand. (I'm not intending to insult. No one has time to study every necessary subject, and this particular subject has been advertised by certain special interest groups as unnecessary.)

And it seems no surprise to me that the current trends in systems design seem to be going towards increasing complexity in the provided systems, which parallels the political atmosphere, and is exactly not the solution. Precisely what we should not be doing.

We put power in the end users' hands (quite literally with the new crop of portable information devices that match the supercomputers of a few years ago). We spend a lot of money, time, and effort putting power in the end users' hands. Then we spend a lot of money, time, and effort trying to limit that power to some definition of "right" uses. We are

• Not trying to teach the end user how to use the power wisely. 
• Not trying to show the end user how to get around the traps.
• Not trying to give the end user more power to do right things.
• Not really trying to give the user solutions, just things that we can sell as if they were solutions

We (that is, the primary movers of the industry) don't want to teach the end user anything that would allow him or her to practice the intellectual property that the system designers' (investors and accountants) think should be making profits for the providers.

We can't understand everything the end user wants to do, and we can't predict what would be "safe" or "dangerous" beyond making crude and overly broad walls. (We, as an industry, try to make straitjackets, really, but we fortunately tend to fail to get the user into the straitjackets -- Fortunately, indeed, since success would make us unable to even consider band-aids like suhosin.)

And we (the primary movers of the industry) don't want to believe that end users could really want to use our systems, any more than we want to believe that the end user could understand new and appropriate ways to use our systems.

We don't want to believe that the end users might be smarter than the system designers about what the end user wants to do with the systems.

And yet, it is the only the smart end user that can safely use the system.

Uhm, no, I don't have a happy solution to the problems yet, at least no quick, straightforward patches. The only real solution I can see is not going to be quick, not going to contribute immediately to anyone's bottom line of monetary profit, not going to be considered acceptable to any of the current crop of investors, managers, and accountants.

patent blues

Give the software patent industry a big, fat raspberry.

Back around 1987, I told a friend who asked me what kind of computer to buy that I didn't like Microsoft for the way they were muscling and hustling the industry.

He asked me if he should then avoid Microsoft, and I admitted that the offerings from Atari and Commodore and the rest of the alternatives, while I liked many of the companies, had the detriment that they were under-represented in the kind of software he needed.

He asked about Apple, and I said, if I didn't like Microsoft, the only reason I didn't hate Apple was that they weren't in the predominant position that Microsoft was.

I told him, I would not like to live in a world where Apple had a defacto monopoly.

Prescience, or what?

So, what did I advise him to do?

Buy the computer for the software he needed, and if he needed more than one, buy more than one.

(If only people had been willing to do that back then, buy the Apple for the kids, for the computer-aided art, etc., buy the IBM compatible for Lotus and WordPerfect, buy Sun for the servers, and learn enough about how to use their computers that they would know to hold their noses when the smelled the stench of anything Microsoft produced.)

It's still good advice, except that I'm going to add Apple to the hold-your-nose category. Buy Apple or Microsoft if you absolutely have to, but don't breathe too deeply, and go to a bit of extra effort to avoid having to.

So, what do I recommend now?

Learn Linux and BSD and the applications that work on those machines. Replace your Apple and Microsoft products as you find reasonable alternatives. Go to a little extra effort to avoid the data-traps Apple and Microsoft lay for you.

Can we trust Google and RedHat? Yes, sort-of, now. More than Apple and Microsoft.

But, and this is the key idea to understand here, systems are dangerous things when they are advocated. (There are historical, psychological, and mathematical reasons for those dangers, and the history goes back well before the beginnings of what we know call the computer industry. Way, way back before that.)

Purveyors of systems, when they get overly anxious to be the one-and-only system, should all be avoided. Google may seem great for now, but once they establish an effective monopoly, give them no more than ten years and they'll be doing the same things that rot out all the good companies, the same things that undid all the good Microsoft and Apple ever did. (Notwithstanding that they do have a better track record than either Microsoft or Apple at this point. Much better track record.)

Any single company that gets that large is going to have this kind of problem.

It would be nice if the Free/Libre software movement could stabilize and provide the technological underpinnings to an industry where there would be lots of small players and lots of consortia, but if Linux-based OSses take over the world, and if the EFF (great players that they are) become the only advocate, we ultimately head for the same problems.

One system to rule them all. That always leads to an evil result.

(Having a triumvirate of Google, Apple, and Microsoft is not a good long-term plan, either, although it's good for now and the next couple of years or so.)

Why must this be so? Why are human systems always going to go south?

Turn the question around: How do you expect humans, even if we can lengthen our life-span to a thousand years, to build anything close to a perfect system?

That kind of perfection literally takes an eternity to achieve. And it should not surprise us that this is so.

Systems are okay to make. In fact, they are good to make, as long as our hubris doesn't prevent us from letting them go when it's time to move on, and as long as our hubris doesn't prevent our systems from getting along with our neighbors' systems, too.