January 23, 2007
Sundown
My friend, and former Lighthouse/Sun colleague, Paul Kim writes about some ancient history that more or less stopped Java from ever becoming a real application development platform. Please read his entry before you read mine. (It’s new information that actually isn’t in Wikipedia.) I agree with Paul that it did not have to turn out that way.
Paul invited me to tell the tale of the demise of OpenStep within Sun. I actually think I’m not going to attempt that. There are others in the world who invested far more of their lives in getting OpenStep up and running on Solaris. The fourth paragraph of the Wikipedia entry seems reasonably accurate as to what all was involved. It was no mean feat: the fact that OpenStep ran at all on Solaris, in X Windows no less, let alone as well as it did, still amazes me to this day. That work was done before I even got to Sun and my hat is still off to that team. Those guys knew X and CORBA and the bowels of Solaris like I hope I never have to know X or CORBA or the bowels of Solaris.
Nevertheless, no matter how good OpenStep could have gotten at Sun, it was not going to stop the Java juggernaut. It did stop CDE, though, at least for a little while, and for that we should all be grateful.
But in ‘96 Java was everything to Sun. Limitless potential—since hardly anything had been developed—and everyone wanted in on it.
One thing I was supposed to do was to figure out where to take things for OpenStep Solaris 2.0. Not just me, of course, there were certainly others, but I had at least one idea that I pitched, I think, at the VP level and it relates to what Paul’s talking about. (Of course, the idea went nowhere fast.)
After OpenStep 1.0 was out the door, Sun and NeXT diverged significantly. Well, they probably diverged long before that, but Sun’s problem was that the OpenStep that NeXT had licensed them lacked the much more sophisticated Project Builder and other development tools that NeXT’s version of OPENSTEP would include. I don’t have much inside knowledge on that but I’m pretty sure NeXT wasn’t going to share that code with Sun, if at all, without a whopping big check from Scott McNealy.
You pretty much only had to have a pulse to realize that that was just never going to happen. OpenStep was going to be forked, not just under the hood, but all over the hood, and no one wanted that. Even if Java had never existed, sending OpenStep in divergent directions would have eventually led to its demise, at least at Sun.
(Also keep in mind that although the OpenStep Specification had been out for a couple of years, many of the client apps—I’m guessing both at NeXT and at Sun/Lighthouse—were pre-Foundation Kit apps and still needed to be ported. (Think NX* classes instead of NS*: no easy to use arrays and dictionaries, no autorelease pools, etc., only a lot worse.))
But, it wasn’t going to matter anyway. Remember that Java juggernaut? Everything was going to move to Java. No. Matter. What. And, frankly, at the time that wasn’t necessarily a bad thing. Limitless potential, remember?
So here we had an OpenStep-aware group at Lighthouse who needed to write applications in Java. And an OpenStep-aware group at SunSoft that needed to figure out what it was going to do with itself, and with Java. And, oh yeah, SunSoft, as a product line, had just really crappy Java development tools. (Sorry, Jeff!) Hmm... I think you can see where I’m going.
(The IDE available from Sun, and I think actually mandated for internal use at Sun, was Java Workshop 1.0. I wish I could find a screenshot. Everyone I knew at the time just used Emacs.)
So, ok, one of the things I suggested was that the OpenStep group start building real Java development tools, first in Objective-C, then ultimately in Java. Right now. Anything would have helped. Lighthouse would have loved it. The world would have loved it. And OpenStep Solaris would have had a little more life.
Ah, but we needed an Interface Builder for Java and we didn’t have a lot of time. Or so I thought.
Enter NetCode.
NetCode was the developer of the Internet Foundation Classes (IFC). It was started by two guys from NeXT. Those two guys now ship two (different?) Cocoa applications today. They got it. I wanted it. Actually, I wanted what came with it: Constructor.
Constructor, to this day, is still the most IB-like 100% Java-based interface builder I’ve ever seen. For 1996, it was f’ing amazing. (I wish I had a screenshot; I don't. UPDATE: 24 hours later, I do. See below.) It was IB, in Java. WYSIWYG drag-and-drop layout. Palettes. Dragging connections between objects. Actual. Freeze. Dried. Objects. (None of this “here, let me generate for you a few thousand lines of incomprehensible, but precisely formated—don't mess with it, not so much as a comma!—AWT layout manager code so you can draw a few buttons” nonsense.)
Imagine this: IFC looked a helluvalot like AppKit, in Java. No AWT. And it came with a friggin’ Interface Builder!
IFC, I thought, had had a stunning debut at a tradeshow in 1995. Netscape promptly bought them in 1996.
I had a meeting with Jayson at Netscape in late 96 about Constructor. It didn’t go anywhere. And neither did Constructor. Ah, what could have been! I never understood why Constructor, or at least the idea of Constructor, didn’t come over to Sun when IFC got folded into JFC. Certainly neither Netscape nor Sun ever did anything with it.
And now we join Paul’s story. The one thing Sun did understand was that AWT wasn’t going to cut it. Not by a long shot. They were looking straight down the double barrel of the AFC shotgun that Microsoft was pointing at them. I say double barrel because AFC not only could have replaced AWT but also tied future Java GUI development to Windows, as only Microsoft can do. Embrace and extend. Yikes.
So now JavaSoft has AWT, Netscape has IFC, and Microsoft has AFC. And AFC is really f’ing scary for JavaSoft. Losing control to Netscape would be bad enough. Losing it to Microsoft likely would have been fatal. But what could Sun really do?
Ah, but wait, Lighthouse—by then a bloody Sun company!—had been somewhat secretly developing the Lighthouse Foundation Classes (LFC). Very similar to the IFC, the LFC dropped AWT on the floor and was pretty much on its way to being a decent knockoff of AppKit, all written in Java.
So what happened? Some people convinced some other people to stop development of IFC (!) and LFC (!!) and fold parts of those teams into a new team based at JavaSoft—headed by the AWT guys (!!!)—where they/we would write the new Java Foundation Classes (JFC) that would save the day and ward off the dreaded AFC. Which, when you come right down to it, it actually did accomplish.
But, as Paul points out, a heavy price was paid. LFC and IFC (apparently including Constructor) were abandoned in order to stop Microsoft. That’s all there is to it. And that’s a decision I can understand.
But Paul is also right that Sun’s own internal battles and basically just NIH by JavaSoft itself hobbled the development of Java as a first-class application development environment. JFC should have simply taken LFC or IFC and continued to develop it. SunSoft should have abandoned Java Workshop far earlier than it did.1 Lighthouse should have been allowed to port its office suite (and then some) to (a smartly done) JFC.2 There were people at Sun that knew what to do. They were ready to do it. They wanted to do it. It just didn’t happen.
Yes, Paul, what might have been. What might have been.
Oh well, back to Cocoa... I think that part, at least, turned out pretty well.
UPDATE: It turns out that Constructor lives! Sort of... Following the instructions posted by Tim in the comments to Paul's post, I actually brought up Constructor in Safari! Pretty rippin' cool that you can still download the code (though sadly not the source). If do you try it out, my advice is to edit the provided index.html to make the applet size a lot bigger than the default 640x480. Here what I've been playing with at 1024x768:
1 A few years later, after I and others had left Sun, Sun abandoned Java Workshop and paid a lot of money for NetBeans.
2 A few years later, after I and others had left Sun, Sun woke up and realized they needed an office suite after all and paid a lot of money for StarOffice. All in glorious C++. Yikes * 2.
Posted by ttalbot at 9:51 PM
September 25, 2006
Thanks Mickey
I originally wrote this at the very end of last year, but apparently never published it. So, old topic. But I liked the post anyway, so here it is...
No, this isn't about Disney. It's about Michael Sprague, my high school computer science teacher. I no longer see him on the school's website. He'd only be about 50 now. A little young to retire. But maybe not. I hope he found something better to do than teach teenagers about computers, but he was pretty great at that. So actually I hope he's still doing it.
What brought "Mr. Sprague" to mind was Joel's latest [ed. not so latest anymore] essay, The Perils of JavaSchools, and Dori's followup, You think you're old? recounting her computer science education back in the day, as the kids say.
Dori nicely summarizes Joel's argument: "[In] the old days, programmers went to college, learned C, and got a good understanding of what was going on deep down internally. Nowadays, these newfangled programmers are only learning Java, and consequently, they don't know anything about recursion or pointers. Schools should teach Scheme and C, and the students will be the better for it."
And that got me thinking. Pointers and recursion. Yeah, he's right. Sprague had us doing those in PDP-11/70 assembler and Pascal (for the AP test the following year) and some pseudo-language of his own invention when I was a junior in high school.
I mean, like, for months it was dereference this, parse-this-expression-into-a-tree that. And after a while our heads did explode. But we felt better for it. And, you know what?, the following year the small group of us that could put our heads back together again won the ACSL state championship really without even worrying about it. (Ok, so we placed, I think, 9th nationally but that had more to do with our hastily arranged trip to Amish country than anything else.)
This was a good thing, too. When I went to college, a really, really long time ago, at least in Internet time, my alma mater didn't even offer a formal computer science undergraduate education. (It was considered "too practical". Apparently that's now changed.) So I went to law school...
Now I don't bring this up to say "see, I was doing this in high school, look at me", I bring this up to say a sincere thank you to whomever at LHS decided they could start a computer science curriculum around an 8 year old 16-bit minicomputer and to give a tremendously big shout out to Mickey. You guys saved my butt.
Posted by ttalbot at 10:17 PM
March 9, 2006
CocoaHeads LA Meeting Tonight
Just a reminder that the third meeting of CocoaHeads LA (Santa Monica) will be tonight (Thursday) night at 7:00 PM.
We'll again be hosted by Steve Gehrman at the fabulous CocoaTech offices at 1238 7th Street, Santa Monica, between Wilshire and Arizona. We may move the venue later in the evening to one of the local spots for food, drinks, or dessert.
We're still in our nascent stages, so now's the perfect time to join the group. (It's free).
We'll be having our general Cocoa roundtable, show-and-tell, and discussion about Cocoa debugging techniques, including a demo of OmniObjectMeter.
CocoaHeads LA. See you there!
Posted by ttalbot at 10:52 AM
March 8, 2006
On Mac minis and putty knives
With the recent release of the Intel-based Mac minis, there's once again a slew of postings/articles about how to properly open a Mac mini to add RAM, replace a hard drive, or (now) swap out the processor.
Most articles tell you to use a putty knife with the blade's edge sanded down to be a little thinner. This allows you to pry the case open a little bit so you can insert the knife and start popping some of the latches that hold the mini's lid on. However, there appears to be a significant number of people who end up marring the mini's case when the putty knife isn't thin enough to slip in easily. (This apparently led to the invention of the "wire method" which I am nowhere near coordinated enough to figure out.)
One of Karelia's main servers is a (PPC) mini -- the other is a G4 Cube -- and it works like a champ. When I needed to open the case to upgrade the RAM, I did not order the specially modded putty knife or fumble around with wires. You know what I used? A kitchen spatula. I had three of them in the drawer. All of them were thinner than the putty knife I was going to have to sand down. I tried them all. Two of them were still too thick. One worked perfectly.
In fact it worked so well, that I'm amazed that people still talk about putty knives. Not only was the spatula thin enough to work without marring the case, it was also a lot wider than a typical putty knife which meant that I could unhook twice as many of the tabs at a time. In fact, the spatula made it damn easy to get the case apart. I'm just saying.
So there you have it. Kitchen spatula.
Posted by ttalbot at 3:45 PM
November 9, 2005
CocoaHeads LA Meeting Tomorrow Night
Just a reminder that the second monthly meeting of CocoaHeads LA (Santa Monica) will be tommorow (Thursday) night at 7:00 PM.
We'll again be hosted by Steve Gehrman at the fabulous CocoaTech offices. We may move the venue later in the evening to one of the local spots for food, drinks, or dessert. Mmmm.... Cocoa and dessert! Sounds like a good, new LA trend.
We're still in our nascent stages, so now's the perfect time to join the group. (It's free).
We'll be having our general Cocoa roundtable, show-and-tell, and discussion/hacking on our first community effort: CocoaSpot. (What's CocoaSpot? Come to the meeting and find out!)
CocoaHeads LA. See you there!
Update: Steve says that the care package is in from Mark Dalrymple at CocoaHeads HQ. Included is a brand spanking new copy of his and Aaron Hillegass's new book Advanced Mac OS X Programming. We'll have it available for your perusal and possibly as a door-prize. I can't wait to see it!
Posted by ttalbot at 3:34 PM
July 8, 2005
aARDvark
Ok, a break in the code, I've got a backlog of posts...Since we've started using FogBugz to track issues at Karelia, I keep Joel on Software tucked over in a corner of NetNewsWire just to see if there's anything going on at Fog Creek I want to keep an eye on. (What? Too many links in one sentence? What's the rule?)
So, sometime during the spring Joel announced that they were hiring a few select interns for the summer to work on a new, super secret product, code-named Project Aardvark. The premise sounded pretty interesting: take a few smart interns and throw them at a new project that's supposed to ship at the end of the summer.
It sounds new and fun and cool and sexy and not that dissimilar to how Dan and I are spending the summer, to ship something new and fun and cool and sexy for Karelia, except of course that they're in New York and we're in California and they're working on a Windows product and we're working on a Mac product and they're interns and, well, we're, um, clearly not.
Anyway, last week they announced that Project Aardvark is to become Fog Creek Copilot, a Windows app that puts up a VNC window of your friend's computer so you can take over the screen and the mouse and the keyboard and fix whatever horrible thing has gone awry with their Windows box.
A couple of interesting observations here: the core of Copilot is based on an open source version of VNC (as is pretty much everybody's, though how often do you see open source leveraged in a Windows product?), it apparently has a strange e-commerce use model that I don't yet really understand, and it should be incredibly useful for people who need to keep up with their friends and family PC support obligations.
I was really surprised that this is what Aardvark turned out to be. I guess I thought these things existed already. I've been doing this for Lisa's parents and mine using Apple Remote Desktop for a couple of years. It really is the only way to fly. And then it hit me. Aardvark. aARDvark. The clue was there the whole time...
Posted by ttalbot at 2:45 PM | Comments (2)