Java Jabs, VisiCorpse, and the Blood of Red Smith

Hal Hardenbergh, an FOD (Friend of Dobb's) and a Dr. Dobb's Sourcebook contributing editor, invariably refers to this part of the magazine as my "Pairofdimes" column. It may be his assessment of the value of the writing. Taking it as such, it follows with geometric logic, as Bogart's Captain Queeg might have put it, that whenever I let readers get their collective two bits in, as I do this month, the column ends up with a net positive balance of five cents. I'm saving up these nickel overages in the hope that I can trade them in later for valuable prizes. A lot you care. Get on with the column, you say. So be it.

Let it Be

The Pairofdimes mailbox bulges this month with reader mail. Here are two representative samples:

From Don Slepian, along with some encouraging words about my recent incomprehensible ramblings about recent equally incomprehensible events at Apple (I think I was talking about the "widely admired but unpurchased" [in the words of FOD Hal] Be operating system, which of course Apple isn't talking about anymore), come two unsolicited and entirely enjoyable Beatles parodies. Here, barely within the limits of legal fair use and defensible allocation of space in a programming magazine, are a couple of excerpts:

When I find my code in tons of trouble
Friends and colleagues come to me
Speaking words of wisdom
Write in C.
Write in C, Write in C,
Write in C, yeah, Write in C.
BASIC's not the answer.
Write in C.

and

Somewhere in the memory I know,
A pointer's got to be corrupted.
Stepping in the debugger will show me...
I don't want to leave it now
I'm too close to leave it now
You're asking me can this code go?
I don't know, I don't know...

Walter Pinkus writes in a different vein: "In your 'Programming Paradigms' for November 1996, you quote a Gene Fowler that "'Writing is easy...'." Says Walter Pinkus, getting the target clearly in his sights before firing this blast: "I first encountered that in 1960 or '61 as 'Writing a column is easy. You just sit in front of a typewriter until small beads of blood appear on your forehead,' [attributed to] Red Smith. It was scrawled on the wall of our college student newspaper office, along with other Historic Great Truths."

Well, I knew it was a writer. This is why history repeats itself -- because it didn't get it right the first time.

History Repeats Itself Again

Joachim Feise had written to me before challenging my account of the naming of Konrad Zuse's historic computers in a past column in which I discussed Zuse. I argued with him, because my sources were good, but he came back with a source that would have to be regarded as pretty authoritative: "It took me some time, but now I can point you to Zuse's autobiography to support my claims: Konrad Zuse, The Computer - My Life, Springer Verlag (1993, both in German and in English. The ISBN for the English edition is 0-387-56453-5). In it, he only mentions that the Z4 was called V4 during construction. The Z1 through Z3 apparently were always called Z1-Z3. The word 'Versuchsmodell' is translated as 'Experimental Model', although I would rather translate it as 'Prototype'."

Feise also corrects my spelling of Zuse's programming language, Plankalkül.

Konrad Zuse has as good a claim as many better-known computer pioneers to the title of inventor of the digital computer. Working in Germany during World War II, he was isolated from computer pioneers like Mauchley and Eckert and John von Neumann in the United States (and they from him, which partly, but only partly, explains his near anonymity in the States). He designed and built a series of machines, culminating in the Z4, which he moved out into the Bavarian Alps late in the war, just a little ahead of Allied bombing.

In Bavaria he wasn't able to work on the Z4 (he kept it hidden in a basement), so he spent his time fiddling with his programming language, Plankalkül. I haven't been able to determine whether there was an oak tree outside the window.

Java Jabs

There was an oak tree outside James Gosling's office window while he was writing Java, and for a while the language was going to be called "Oak." I have a lot of oak trees outside the window of my office where I am teaching myself Java. So far they haven't inspired me to write a programming language, but maybe they are making the task of learning it easier. Well, it's possible. Something about being in the state of mind of the developer when he developed it? Although if that's my goal I'd probably do a lot better just consuming mass quantities of coffee. In any case, writing in Java is easier than writing Java, and -- even though I fully concur with Mr. Fowler/ Smith about the blood -- writing about Java is easier than either.

Recently in this column, I proffered a contrarian view of Java. It was highly critical, and also highly contrived. Although I took all of its criticisms from a published essay by a professional programmer, I reworked them for publication here so much that the programmer probably didn't recognize himself in the straw man I constructed, and may not have agreed with all of the straw man's criticisms. I didn't agree with a lot of them, myself. But they were, modulo some editorial license, the views of an actual programmer out there in the trenches, and they were provocative. I hoped that they would provoke something publishable.

Java programmer Ward Mullins took the bait. He wrote in to knock down Straw Man's criticisms of Java, and to replace them with some criticisms of his own. Here, in somewhat condensed form, is what Ward had to say. In what follows, quotation marks indicate the Straw Man is speaking, no quotes mean that Ward has the floor, and brackets mark my interruptions.

"We don't need another C++."

Agreed! But Java is far closer to Smalltalk or Objective-C than [to] C++. [But it's often been described as C++ with a haircut. Okay, it's been described that way once. Now.]

"Multithreading is obscure."

All of the modern [operating] systems have multithreading capabilities, and yet none of our so-called modern languages have support for this (except Ada and Java). To say this is obscure is an Ostrich response. [But multithreading is certainly widely misunderstood. One book that takes a lot of the mystery out of it is The Java Programming Language, by Ken Arnold and James Gosling, Addison-Wesley, 1996.]

"Java is slow."

Sometimes, but it's almost three times faster than Visual Basic (that's without a Just-In-Time compiler). [Performance] heavily depends on the run-time implementation, as the new Java Runtime on the Macintosh demonstrates (it's an absolute speed demon!). Systems like SGI have shown several applets and applications [that] run with 50 percent of the performance level [of] similar C++ programs. Also, many applications [that] take advantage of threading run significantly faster than their C/C++ counterparts. See the CERN Http server (JigSaw) as an example. It actually runs far faster than their [own] C-language version. [On one benchmark test I've seen reported, Java performed at about the same level as Visual Basic 4.]

"It'll never be fast."

Companies like Asymetrix, which offers a native compiler for Java, might disagree. Just-In-Time compilers increase performance significantly for many operations (although not all of them yet). [...to something like 1/5 or 1/10 the overall speed of C++, according to programmers at Borland, who pioneered the JIT compilation concept. Java and C++ guru Bruce Eckel doesn't think Java can reach C++ speeds: He has compiled a list of security features of Java that he thinks can't be optimized out of the language, and that all adversely affect performance. If C++ was designed for speed and Java was designed for security, and if neither design was fumbled, doesn't it stand to reason that C++ will always be faster than Java?]

"Security comes from it being interpreted."

[Wrong, socket breath.] Several components make up security, with the interpreted aspect being one of them. Part of Java's security comes from a verifiable bytecode system, although this bytecode system is certainly not limited to the Java Language Syntax (as the porting of Ada and Rexx to it have shown), it is certainly part of the Java language standard, and one of the reasons for its success.

"Weak development environments."

Well, I have to agree...the current environments leave a lot to be desired. [And developed.]

Java Jabber

[Now here are Ward's top ten complaints about Java.]

1.Current implementations of the AWT generally suck! This is more of an implementation issue than an architectural issue, but it's certainly real.

2.Splintering of the GUI toolkits. We have AWT, IFC, Marimba's Bongo classes, and now Microsoft's AFC (I think that's what they're calling it). This is going to turn into a programming nightmare unless someone gets control of it.

3.Inconsistencies between run times. This comes from a lack of validation suites, and is supposed to be addressed in 1.1.

4.Lack of a component architecture. This is going to be fixed in 1.1.

5.The threat of nonstandards creep from Microsoft. This is a real issue that could eventually derail the Java train, although so far Sun has done an amazing job of preventing this. I've even heard rumors that Microsoft is porting Office 97 to pure Java!

6.Lack of serious solutions, as opposed to prototypes and toys.

7.Disinformation, especially about security! The security model of Java is pretty good. You're far more likely to be burglarized than to have your system intentionally harmed via Java.

8.Lack of real Object skills. Most programmers come from a C/C++/Perl/ Basic background. If they have any Object skills, they're often bad, or simply inappropriate. This means that a lot of companies and individuals are writing some pretty crappy code.

9.The me-toos, which are really the me-nots. A prime example of this is Active-X, which everyone compares to Java. They are no more related than a NEC monitor and a US Robotics modem.

10.Lack of valid press understanding. I'm sure to press people all of this stuff must sound the same, but more often than not the articles read like press releases from Microsoft or Sun, instead of having any meat or substance around the real issues. The bottom line of what technology X costs, and what it delivers. Very few talk about the cost issues with Java. Now I can write an application on one platform and deploy on more than a dozen, with a single binary file and no recompiles. As a business owner I can tell you that this is a very real issue, and a very real cost saver.

[That's] my 2 cents worth.

[More than two, surely. About a dime's worth, I'd say.]

The bracket-and-quotation-mark convention is now off. </convention>. Swaine has the floor again, with no brackets. The subject, accordingly, shifts. It shifts to shifts, in fact, of the paradigmatic kind.

VisiCorpse

Changing the world is no big deal. We all change the world, for better or worse, every day. We change the world through our failures as well as through our successes. Think of the Xerox Alto. And we change the world through our inaction as well as through our actions. The world is a better place for all those billions of people who didn't blow up a commercial airliner yesterday. If you're one of them, I'd just like to say thank you. Some instances of changing the world are more memorable than others. Dan Bricklin and Bob Frankston changed the world in a number of memorable ways. As everyone knows, Bricklin is the designer and Frankston the executor of a world change called "VisiCalc." VisiCalc introduced the concept of the electronic spreadsheet. When it was first released (through Dan Fylstra's pioneering personal computer software company Personal Software), it ran on an Apple II and required 16K of RAM.

One way that it changed the world: It sold Apples. The idea that anyone would buy a personal computer for a particular piece of software was in itself an innovation. The boost that VisiCalc gave to Apple, which was only by sheer happenstance the machine for which VisiCalc was first written, is one of the major events in the history of Apple Computer. Another way it changed the world: Virtuality came into the picture. "What-if" became a more common way of thinking in business. Testing out the consequences of different business strategies is not what is usually meant by virtuality, but I think it fits: Much more today than in the past, people in business spend time in alternate universes articulated in the rows and columns of electronic spreadsheets. In my opinion, this is Bricklin and Frankston's greatest active world change. As for passive world changes, so far as I know neither of them has ever blown up a commercial airliner.

After creating VisiCalc, Bricklin and Frankston went on changing the world. By 1984, their company, Software Arts, was engaged in an insane corporate struggle with Fylstra's Personal Software for control of VisiCalc. Personal Software had done so well with VisiCalc that the company's fortunes were all tied up in the continued success of the product. In fact, it wasn't Personal Software any more: The company's name was now VisiCorp. But VisiCorp didn't own VisiCalc. The contract between VisiCorp and Software Arts gave VisiCorp the rights to market the product, but made it clear that Software Arts was responsible for development. But Bricklin and Frankston hadn't been doing their job, VisiCorp maintained, permitting the product to lose ground against competitors like Lotus 1-2-3. Bricklin and Frankston saw it differently: They were fighting to get marketing rights away from VisiCorp, which they saw as not doing its job in promoting the product properly. Meanwhile it was clear that nobody was doing what they should be doing for the product, so ensnared were they all in the game of suit and countersuit. In the end, VisiCalc, VisiCorp, and Software Arts all slid into oblivion.

None of the principals in the VisiCorp-Software Arts suicide pact was stupid. So how did they get themselves into such a mess? That question has provided material for many a business school class. It may also give the independent software developer something to think about when negotiating contracts.

So Bricklin and Frankston (and Fylstra) changed the world in this way, too -- by providing a bad example.

Premature Burial

There's another product that came out of Software Arts that I've always had a possibly irrational fondness for -- TK Solver.

TK Solver was invented by Milos Konopasek back before the personal computer era, the first version running on a PDP-10. Defining TK Solver was a challenge then and remains one today. Konopasek characterizes it either as a mathematical modeling and knowledge-management system, or as a declarative object-oriented programming language, depending on the perspective of his audience. Whatever it was, Bricklin and Frankston liked it, and wanted a PC version. By 1983 Software Arts was selling TK for the PC. Initially it employed the same teletype model of user interaction that most math programs still seem to love, but it quickly pioneered a more graphical, full-screen user interface.

Unlike the other casualties of the Visiclash, TK Solver is alive and well. I have Release 3 for Windows; it's marketed these days by Universal Technical Systems (Rockford, Illinois). I got e-mail from Konopasek last fall. It seems that Wolfram Research, the maker of Mathematica (and at least in some ways a competitor to TK Solver) presented the following characterization of TK on the Mathematica web site: "Programmer couldn't keep up with developments in recent years, so TK Solver is now practically a dead product."

Konopasek begs to differ. It is, in fact, precisely "developments in recent years" such as more powerful operating systems, cheaper memory, and faster CPUs that make the computationally ambitious TK Solver more useful today than it was back in the '80s.

He's not sure how to respond to the Wolfram characterization of TK Solver. Reminding old friends of the product (like me) to take another look at it is one response, and I hope to delve into TK (and Mathematica) more in a future column. He's considering other responses, like issuing an equation-solving challenge, but he hasn't decided firmly on anything yet. I'm glad to say, though, that he's not considering blowing up any commercial airliners.

DDJ