28 - Sept - 2006
Recently, there was some discussion at Javalobby about the absence of any strong inroads of Java into the Windows Desktop Applications arena, even though we have a hardware-accelerated Swing, SWT, Netbeans and Eclipse RCPs,. and all that. Cameron Purdy suggested that "Java on the desktop" had never been Sun's responsability, and I couldn't disagree more, especially concerning the constant flow of crAPIs (=crappy APIs) coming from the JCP that are a pain to use.
If part of your (Note: I'm using "your" to refer to a generic designer, not to someone specifically) language requires tools, you'd better release a damn good tool with the language if you want to be successful. This simple concept seems to have escaped significant portions of the JCP community for years.
Microsoft has been especially good at this, but not only Microsoft. Would Delphi-the-language had been the success it was if it wasn't for Delphi-the-IDE? What if Borland - at the time of Turbo Pascal - had assembled an "expert group" and after years of head-scratching had delivered ... not Delphi, but a specification of the .DFM (=Delphi Form) format which of course (sarcasm intended) you can write by hand but you don't need to (sarcasm squared) because "of course you'd use tools", nevermind that they are crappy or nonexistant at the time the spec is released. The same is happening lately with "stuff" coming from the JCP.
Am I supposed to write desktop (aka GUI) applications by hand-writing component positioning and event handling?
Am I supposed to write and read EJB deployment descriptors by hand?
And don't even get me started on JSF (Two more of these and we won't have java on the server, either).
Its easy to design an overbloated bunch of XML poo-poo or classes with strange source-level-compiler-undetectable dependancies to make IBM's or Bea's or Oracle's implementation easier or to make your design look so cute on paper with all sorts of clouds and boxes and circles that it makes it to the front page of cuteoverload.com and then cry "not-my-responsability-use-a-tool" when a gang of mad developers come back at you beacuse it requires a sisyphean effort to do anything nontrivial.
Consumers are fortunate that usability studies are done for them when designing a product. Where are the usability studies for us - developers - for the loads of crAPIs we get?
Just two examples. EJB 2.x was designed so that I could theoretically query even a server storing data as graffitti on walls. Nevermind 99% of the world stores data in relational databases. So since there could be the slight possibility that maybe your data storage wasn't relational, they invented an abomination called EJB-QL which is more or less like SQL but with amputated legs and one eye poked out.. So when it came to deciding what features of SQL that thing would have, these white-bearded experts discovered that - regarding ORDER BY clauses - they couldn't guarantee ordering semantics to be completely portable. You see - different databases may order the same set of strings differently, and differently from Java, too. So instead of just accepting the ordering semantics of the underlying data store, these architecture astronauts decided that the most reasonable thing was ... to drop ORDER BY altogether, all for the sake of portability, AWT-style all over again. After all, everybody knows that no end-user wants any listing sorted, ever, and even if he wanted it, you can always fetch your multimillion row database and sort it server-side. God forbid we make the graffiti or XMLDBMS / OORDBMS writers unhappy.
It doesn't stop here.Take JSF for example. JSF is designed so that I can -also theoretically- render my application on a wooden table using a numerical milling machine, or on a lousy WML device. So If I want to develop a new component I have to swallow a whole ton of crap of abstraction layers for rendering, nevermind that world+dog is sticking with plain HTML so far. Again, God forbid we make tex-wannabe renderers or woord engravers unhappy.
If the domain needs a very specific semantic, why the hell has it to be expressed in XML? Read a compiler book and do a DSL1 that makes it nice for the users of the technology, not for you the implementor or tool vendor. If I wanted a programming language with the verbosity of XML I'd rather go back to COBOL first, thank you.
So now we have things like
<foo:call methid="bar">
<foo:param name="foo">value</foo:param>
</foo:call>
Don't make me laugh!. I couldn't agree more with a recent article by Allen Holub that I believe was widely misunderstood. XML is just not a programming language. It is a data representation format .
I'd like to know, exactly at which point did the KISS principle go down the drain?
I think JCP expert groups should be forbidden from writing even a single comma of a specification until they have developed several production-strength applications using that specification and with the publicly available tools at that time and that runs reasonably well on a low end user computer. And discussions should be held in the open so we know the guy to shoot when the next crAPI arrives. Of course, you might say that since the spec is new, there aren't any tools yet. Well, that's precisely the point. : either deliver an API usable by hand, OR deliver a robust usable tool first, then your crAPI.
And then, there's another factor. Usually non-zealots (like me) have a real life to live and real decisions to make and to live with. If I'm evaluating something and it sucks, it is doubtful that I'd be re-evaluating every single minor release that comes afterwards. I'll just pick something else that works and afterwards I'll have to stick with that decision. Of course, Microsoft can force me be an Office or Windows beta-tester, but most other companies can't.
If at some point of time I have to create a project and I find that Swing is slow as hell (I'm talking about pre-accelerated Swing), or that in JBuilder 1 or Forte I can literally see how menus *gradually* appear on screen or that in WSAD each specialized editor, wizard or plugin is a mini black hole sucking resources like a vampire, then this not only means that I'll dump them and write the thing in MS.VB or Delphi or whatever (and then stick with that decision), but it also means that I'm not going to touch Swing and JBuilder and Forte for quite some time. If you make a graphics library (Swing) that is intended to be revolutionary and the only way to make it run fast is by throwing the computer out of the window, don't be suprised afterwards there's "no desktop java"
On my computer, VS.NET 2005 Professional with all options installed starts in 3 seconds and grabs 80Mb of memory. Netbeans 5.5b2 with mobile and enterprise packs installed starts in 1 minute and grabs 120 Mb of memory, and exits in several seconds, even displaying a "splash exit screen". Eclipse 3.2 with no plugins starts in 15 seconds, and takes 5 seconds to exit.
"Get a better computer", you might say. Beep! wrong answer. You write a better tool. As John carmack said, "there is something deeply wrong when text editing on a 3.6 ghz processor is anything but instantaneous".
Gone are the days when the success of the Microsoft software could be blamed on the unfair knowledge of hidden APIs and stuff like that. It's time to face the fact that maybe Microsoft development tools are popular because of the sacrilegious idea that they are ... good?
The "dump into the market the first version regardless of quality and improve afterwards" might work for Microsoft when you have control of the desktop or when you are offering something for which there's no other similar choice, but it doesn't work in the rest of the cases. First impressions do count and *do last*.