Archive for April, 2005

So, after slogging long and hard through the wee hours of the night, ReSTedit now supports non-contiguous selection and columnar selection. Simply cmd-drag to extend the selection in a non-contiguous manner and option-drag to make a columnar selection.

It was really really hard to do.

Yup. That is all a pack of lies outside of that ReSTedit now has said features. I didn’t do anything other than notice a new feature in Cocoa’s Text subsystem. All Cocoa apps now support these features which means, of course, that all PyObjC apps support these features, as well.

In particular, I created a Desktop tag that will contain all the various random photos I have taken that I like to use as desktop images.

The photos in this post were both taken at Bean Hollow Beach, a small beach covered in mostly pebbles with lots of rocks and tide pools at the north and south end. It is just south of Pescadero almost due west of Saratoga, CA.

I also finally started to populate my Blogger based weblog. Given the tight integration between Flickr and Blogger, I am going to use Blogger as a sort of photoblog. Actually, I’m not going to do so. My weblog template now handles photos quite nicely so, no need to punt to blogger.

I would never have decided to dive totally into Flickr without Frasier Speir’s wonderful Flickr Export Plugin for iPhoto. It makes uploading photos to Flickr from iPhoto totally painless. It will assign tags at upload and lets you easily assign titles and descriptions via a nice UI integrated straight into the export panel of iPhoto.

Yeah, someone busted me on actually failing to answer that question. So, a highly opinionated set of my observations.

In the interim years between which the Java promise was made and broken (again I’m only talking about the shrink wrap Application market here), there have been a number of other tools and technologies that have come along to make the whole WORA point not terribly interesting.

Beyond the development tools on the major platforms maturing significantly, there is also better support for building cross platform non-GUI code. Scripting languages are more easily integrated now than ever before, creating a high level portable solution for implementation of a good chunk of applications. Similarly, the support for C++ (and, really, Objective-C) in cross-platform environments has matured significantly in that write-once-run-anywhere-with-the-right-compiler-flags is a commonly used paradigm these days.

As well, the approach with which software is developed has matured. Developers recognize the value of separating user interface code from their data containment code. Model-view-controller is an obvious and commonly used design pattern that does exactly that. There are other design patterns that achieve the same goal. It is also interesting to note that the growing popularity of unit testing naturally leads to a better separation of user vs. non-user functionality simply because it is so difficult to unit test user interfaces (that is what functional and acceptance testing is all about).

And the tools available for separating data from user interface have also matured significantly. Beyond design patterns, there are now a number of tools that vastly simplify client/server style communications (even when a network connection isn’t really involved– SQLite, for example). Use of client/server also naturally leads to a stronger separation between the platform specific user interface code and the platform agnostic data management and core functionality.

So, while the Java market was largely focused upon providing solutions– some awesomely powerful– for developing internet related or internal/vertical applications, the rest of the market was not sitting around.

Likewise, the platform specific development models have advanced significantly. On Mac OS X, Windows, and Linux/BSD/X, there are many relatively new tools and APIs that make pumping data into a user interface both a heck of a lot simpler (fewer lines of code) while also enabling the ability to create custom visualization tools that are strongly tied to the native APIs. Certainly, Java is providing support for a similar mechanisms via some of the newer APIs, but the development experience still lacks the tightly bound fluidity of using tools designed specifically for the platform.

There have also been a number of APIs and technologies built that also promise write-once-run-anywhere style solutions for cross platform deployment. While all suffer from similar look and feel problems as Java based solutions, there are some very high quality solutions in this space that often have significant advantages over Java — smaller installation footprint, less overhead, simpler development, or some combination therein.

So, as a result of both the significant advancements in platform specific technologies and in the cross-platform tools market, Java is simply yet another solution to an already solved problem.

All of the above combined means that Java just won’t matter on the desktop unless it can offer a compellingly superior solution to some set of problems. At the moment, Java does not.

While writing cross-platform non-UI specific code is both easy and quite attractive with Java, cross-platform GUI code really doesn’t exist without sacrificing the quality of UI that can only be had with native tools. That, combined with the increasing quality and simplicity of tools such as wx*, TK, or a number of commercial products (Real Basic, Runtime Revolution, etc..) for cross platform development further dilutes Java’s potential.

Given the discussed roadmap of Java these days, it doesn’t look like Sun — or anyone else — is really putting up much of a fight for the desktop.

That last post certainly deserves a followup. It generated quite a bit of commentary, some of which was interesting and most of which indicated that the author didn’t actually read what I wrote (or I did a poor job of conveying what I intended).

In any case, thanks to all that responded. It was a remarkably flame/fud/troll free set of responses for a topic that is generally quite volatile in nature.

Some random points of response:

What Carmack Said I know that Carmack’s comments were directed at development of software for cell phones and other embedded devices. The point of my post was to take this particular observation and apply it to what I perceive as a significant failure in regards to the original promise of Java. Java spent a good chunk of the latter part of the 90s being marketed as the end-all, be-all, write-once-run-anywhere, solution for application development. That promise never materialized.

Java, the Language I like Java, the language. I have written tons of Java. It was mostly pleasant, mostly interesting, and often quite entertaining. About the only bits of Java I really found miserable had to do not with the language, but with dealing with other people’s code that was exceptionally poorly written. Java certainly does not own a monopoly on crappy code. However, as a result of so many really bad ideas getting funding during the dot-bomb years, many bits of code that should never have seen the light of day were shipped as “final” products. Until working for Apple, much of my professional time was spent cleaning up other people’s messes. While lucrative, it also meant that I spent a large amount of time de-tangling really crappy code from a client’s environment, often well after that client had spent a boatload of $$$ on said solution. Often, it was a better bet to put up with the crappy code to make the client feel like they didn’t get completely ripped off than it was to do the right thing and throw the garbage out.

One of the promises was that Java development would be efficient. We have seen tremendously powerful features come forth in the various IDEs, but one area that seems entirely lacking is the UI development tools. This is probably one of the reasons why Java as a desktop application development environment (where, again, “desktop application” is “stuff you’d see in a shrink-wrap box at CompUSA) just never met the promise. The tools for building applications sucked when the promise was made, and continued to suck until long after the promise was broken. I have started to see some promising tools in the last couple of years, but none that seem really aimed at building generic applications — most seem to be either tied to some enterprise related back end framework or to solving a particular niche problem such as reporting.

And, yes, Java is not slow. I know that. I wrote many a hunk o’ Java code that had to be fast as hell and it was always possible to eek out the performance I needed. But Java desktop apps, on the other hand, generally are very slow, or unresponsive, or bloated pigs, unless the developer expends an unbelievably huge amount of effort to make them otherwise.

Real World Java Desktop Apps Java promised write-once-run-anywhere style development where the end result would look-n-feel like a native, or near native, app on the target system. That promise was quickly amended to account for that fact that different desktop environments behave differently and some of those differences would require compensation within the codebase to ensure a native look and feel. This is certainly not a flaw of Java, but merely the reality of building desktop apps. However, even that is not really true. Achieving a native look-n-feel while also creating a responsive application — one that doesn’t “feel” any different than any other app on the platform — just doesn’t seem to have happened very often.

What many people missed was that I was specifically talking about commercial applications targeted to the wide market. Not to niches, not development tools, but addressing the original promise that Java would be a major player in the applications market. Sure, many many people are using Java quite successfully to build in-house, niche, one-off apps. I was in that group for a long time and assuredly will write new Java one-offs for my own or other internal uses in the future. Visual Basic has achieved an even greater success in such a role. But that wasn’t the promise! The promise was that Java would be the solution for creating desktop applications of the kind you would see in shrink wrap boxes at the likes of CompUSA or Amazon.com.

So, of course, a number of people responded to the original comments by pointing out various “example” applications that are written in Java, have achieved some level of widespread distribution, and are targeted to the desktop environment.

Azureus, LimeWire Actually, I used Azureus pretty regularly when grabbing etree content. Painful user interface, not very responsive, and made no attempts to look like a native app. But, yes, very very powerful and did a wonderful job of what it did. Certainly not something I would call a “commercial quality” application. But, then again, my standards– having come from a NeXT and Mac background– may be exceptionally high. LimeWire, last I looked, was a similar kitchen sink’s worth of powerful features shoved into a single app with little thought for usability. Both are bloated, too — consume huge amounts of memory.

Java IDEs Yup — there are a number of IDEs written in Java that are awesomely powerful. Java lends itself really well, much better than Objective-C, to building things like complex and very powerful refactoring tools. As a result, the Java IDEs can do some really amazing stuff with code.

But, boy, talk about bloating pigs! IDEs, in general, are typically 10s, if not 100s, of megabytes for the app along + often 100s of MB more for the supporting materials. And there is no easy way to approach the IDE. You are pretty much left with “run the app and hunt until you figure out how to create a new project… then a new file… then to build… then to debug…etc…”. Worse, many of the IDEs seem to have invented their own UI paradigms that guarantee that the look-n-feel is going to be far away from anything native and often quite a bit aside from the “generic Java” l-n-f.

So, while I consider the Java IDEs to be a testament to the power of Java and to the maturity of certain segments of the Java market, they are certainly not examples of “wora, looks great, native look-n-feel, shrinkwrap package on a shelf” type apps!

Quantrix Someone mentioned Quantrix, which has been ported to Java. If it works half as good as the original Improv, that is one hell of an achievement and they should be applauded. However, given pricing it would seem to be relegated to a vertical market or niche at this time.

John Carmack has recently pursued software development targeted to cell phones. In his typical fashion, he posts about the realities of software development on cell phones.

What caught my eye were his comments on the use of Java for the development of interactive user interfaces. In particular, John says

“The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. …. there is just no excuse for having 10+ millisecond granularity in timing. Given that the java paradigm is sort of thread-happy anyway, having a real scheduler that Does The Right Thing with priorities and hardware interfacing would be an obvious thing. Pressing a key should generate a hardware interrupt, which should immediately activate the key listening thread, which should be able to immediately kill an in-process rendering and restart another one if desired. The attitude seems to be 15 msec here, 20 there, stick it on a queue, finish up a timeslice, who cares, right?
“

There was a period of time when the promise was that Java would take over the desktop. Every company was focused on either “standardizing” on Java as their language of choice for desktop development/deployment or was fighting like hell to try and dilute the “write once, run anywhere” promise of Java to maintain their proprietary stranglehold on a particular piece of the market. All the while, Sun milked the hell out of it, spending massive marketing dollars perpetuating the promise.

But that promise has certainly never been realized. And, now, it looks like it never will. Can you name a single commercial desktop application that is implemented largely in Java? I can’t. Sure, there are a number of various random products that are dominating particular niches. But when I look at the boxes of software in CompUSA or an Apple Store, I don’t think I have seen a single piece of popular or “major” software written in Java.

What John said above is largely why. Java is a great general purpose language. I have written tens of thousands of lines of Java code for various random web and web related applications and enjoyed doing so quite a bit. If you remember, I was one of the handful of developers in the WebObjects community that fully embraced the move to Java.

Java has failed on the desktop because the architecture does not yield a decent and responsive user experience without a tremendous amount of effort fighting against the “natural” patterns of the various toolkits. The promise of Write Once, Run Anywhere mostly– well, pretty often– works for non-UI applications. For UI applications, the differences between platform and UI philosophy mean that WORA also yields a user experience that is alien to the platform.

Likewise, the very architecture of Java naturally incurs latency throughout any Java realized UI. As John said “15msec here, 20 there, stick it in queue … who cares?” For UI development, that is a deal killer.

My second month of World of Warcraft just expired. The plan is to pay month to month and skip a month or so in between.

So, back to the world of the hacker-productive, hopefully. I wonder how many open source projects have seen a significant slow down in their release cycles as a result of WoW?

It really is a very, very well done game. There is a bit of tedium to it after a while in that the core of the game is a kill-collect-sell-upgrade-rinse-repeat endless cycle. Fortunately, playing with a boatload of your friends, a huge variety of quests and just a really beautifully well done environment results in a very entertaining play experience.

Whether actively playing or not, I’m certainly going to follow the evolution of the Warcraft environment. Blizzard has laid a foundation that is pretty much unlimited in its potential. If the world ever becomes “too small”, they merely have to add continents or new planets with means of traveling between. It is interesting to observe that the Warcraft setting is not free of technology, thus providing the potential for unlimited changes or additions through the use of creative inventions/devices.