Jim: I appreciate your points though I think you are reading a bit too much into my motivations. I’m not really sulking about the loss (I had time enough back then to do so) so much as trying to show some of the factors which led to Sun’s failure on the desktop and that much of that was in their control. I’m not sure where you are going with your marketing point. This was internal politics and it didn’t matter how it was marketed. The mere fact that it was not their (JavaSoft’s) idea cemented the decision. The main thing I am lamenting now is that my Sun stock is still stuck in single digits.

And things are much better now. These better ideas still exist and have been expanded upon in the Cocoa frameworks which I have been happily using since Apple revived them by buying NeXT. I think the quality of the apps built on the respective frameworks tells a lot of the story.

Also, I don’t hate Java (not that you implied that at all; just trying to head off any such notions). I have been coding servers in Java for quite a number of years and Objective-C could learn a few things from Java on the language level. I just feel that the frameworks leave much to be desired when it comes to GUIs.

Ulrich: There are significant differences in how they operate. They are not items that appear on a check list. Hopefully, we can go beyond the notion that having the same list of features somehow makes them equivalent. Execution is everything. Also, read Jens Alfke’s article (it is linked up top).

A quick example of how they fundamentally differ: Sun avoids dynamism. Though it can be achieved via reflection in Java, they avoid it at all costs. One of the areas where this becomes apparent is the huge class bloat when using Java. You end up coding tons of “glue” classes just to connect objects since you are stuck with a very specific method signature/interface. Inner/anonymous classes make it a tad more palatable but it’s still tedious. A whole class just to have one method call another method on another object. To me, that sounds like a workaround for a bad decision. Compare that to the use of selectors (method pointers for those that don’t know Objective-C) and you can see how cumbersome the Swing way is.

Frameworks and APIs should not just be ways to access functionality. “Adequate” is not enough. The framework should inspire, encourage the good things and discourage the bad. It should allow you to express what you want to program and not get in the way. If all that matters to you is whether it has the widgets you want and has the requisite tools, then there’s probably little I can say that will sway you.

Every programmer I know has a story of a superior idea losing out to an inferior idea. You see it all over the place. CP/M losing to DOS, OS/2 losing to Windows, Objective C losing to C++, Smalltalk losing to Java, you name it.

However, the thrust of all of these stories always boils down to “life is so unfair” or “things were better back then”. I think this is a bitter oversimplification. The truth is that ideas don’t thrive on their brilliance alone. And it’s a cop out to say that an idea is “before it’s time” or that people “just don’t get it”.

Even good ideas need to be sold. It’s ironic that programmers think that marketing is worthless. Most of these sob-stories are testaments to the value of marketing.

The two GUI toolkits I happen to know are Swing and Cocoa, and I wouldn’t say they’re fundamentally different. Both are MVC, both have GUI builders (Apple IB, NetBeans Matisse), both support object instantiation (IB, JavaBeans). Maybe the only real difference is that in Swing, a menubar is always part of a window (conceptually; I know about the Apple hack that puts in its real place).

Well, no key-value coding or bindings for Swing (so far), but that’s not really a killer for me.

In the 90’s when Smalltalk was trying to break into the mainstream, some colleagues and I went to PARC to look at their windowing toolkit. I had high expectations, because these were the people who had invented object-oriented programming *and* GUIs. But I was flabbergasted at how crude their visual tools were. I don’t remember specific flaws. I just remember thinking it was clear these guys had never seen NextStep. All the power and elegance and *history* of Smalltalk, and that was the best they could do?

One of my colleagues wanted to mock up a simple IB-like thing, and asked if there was any way to draw a connecting line between two windows, like IB does when you connect an outlet. They said no, it couldn’t be done. Well, my colleague sat down and showed them it *could* be done, the way NextStep did it, by making “lines” out of windows one pixel wide.

It’s a testament to Smalltalk’s other great qualities that on balance I still loved it. NextStep and Smalltalk *both* spoiled me.

Unfortunately, getting the Lighthouse apps back is not really an option. Reasons:

- It’s very possible the code has disappeared beyond the ken of man. Sun didn’t seem to care about it and the Lighthouse people left so it’s unclear if anyone kept it somewhere safe.
- As noted by Terrence, a lot of the code was pre-Openstep. It would require some work. In addition, the Cocoa APIs have diverged a bit since then. Not as much an issue if the work was done when all this was fresh in people’s minds but it’s been almost 10 years.
- I’ve heard rumors that various parties (including Apple) have tried to negotiate for the code to no avail.

Fortunately, others have come in to fill the void.

Diagram: OmniGraffle (Omni Group)
Concurrence: Keynote (Apple) / OmniOutliner (Omni Group)
TaskMaster: OmniPlan (Omni Group)
Quantrix: no Cocoa equivalent but Pete Murray, one of the original authors, has re-written it from the ground up in Java (and it runs on OS X). Check it out at http://www.quantrix.com.

Of course, I think it’s more than a coincidence that ex-Lighthouse people are involved with the above apps. In addition, the Omni guys had a close relationship with Lighthouse (OmniWeb on NEXTSTEP was sold by Lighthouse) and were considered kindred spirits. I even recall some Quake matches with Wil Shipley.

If you find that somehow the OS X versions above don’t quite satisfy your itch, I recommend contacting the authors and letting them know what it is you want. The torch has been passed and a new foundation has been established. I think the best thing now is to build upon that.

Leo: Haven’t read that before. Thanks for the link. Most of it seems to be after my time at Sun but from my perspective their angle on Swing is a bit off. It could just be the perspective of someone seeing it afterwards and from the outside who was fed different info from different people at Sun.

http://web.archive.org/web/19970615200826/http://developer.netscape.com/library/ifc/

and a screenshot:

http://web.archive.org/web/19970615123220/developer.netscape.com/library/ifc/constructor/screens.html

If you download the code and copy the 3 folders under ifc11/netscape/ from the IFC distribution into constructor10b3/Constructor.applet/netscape in the Constructor distribution, then open index.html with Safari, Constructor will actually run. It also works with the Mac OS X Applet Launcher.

For a while there it seemed like Objective-C was headed for complete obscurity, odd that in some ways Sun ended up saving it by screwing up Java’s total potential.

It is unfortunate they don’t even open source the Lighthouse apps and the apps that Lighthouse acquired, a lot of stuff there…