Why the Podunk County School will never be using Java and will probably never leave VB

From: Andrew Mayo (ajmayo_at_my-deja.com)
Date: 11/18/04 

Date: 18 Nov 2004 06:19:37 -0800

Recently it was time for my annual review of the Java vs .NET state of
play. Every year I optimistically think 'This is it. Java's finally
ready for prime time'.

(cf: "too much cream in the coffee", which, unfortunately, is still
largely true several years after I posted it)

And with big shiny new IDEs like Eclipse and Netbeans, and a new,
improved JVM, surely my unreasonable prejudices would simply melt
away.

Now, what's this got to do with the Podunk County School?. Well,
someone recently rather sniffily pointed out that dear old Visual
Basic - not the .NET mutant version - is used by zillions of people
like the poor ole County School. The clear implication is that VB is
for those poor people who can't master templates, multiple inheritance
and *real* programming. The real programmers are all fighting over
whether properties and boxing are good or bad things, and the various
merits of their favourite IDE/XML parser etc.

And of course, Java, and .NET, provide all kinds of wizzo high-level
features; proper inheritance, delegates, you name it. How could anyone
write serious systems without all that cool stuff!

But the reason that VB became so popular isn't that its users are too
brain-damaged to program in a 'proper language'. It is because the IDE
permits such a fluid and intuitive workflow that you can concentrate
on solving the actual business problem and not just fighting the
compiler.

Microsoft understand this very well, and it's deeply saddening to see
that the Java IDE-writing crowd don't.

Let's try a simple task in Visual Studio .NET, Eclipse and Netbeans.
I'm just starting out with Java (or C#) and I'd like to create a
single form with a single button on it. Then I'll put a breakpoint on
the button click event and use the whole thing as a springboard to
explore the language and the UI environment.

In VS .NET this is nice and simple. Start a new project and choose a
windows form application. Select the toolbox and drag and drop a
button, position it where you want. Now double-click and you're in the
button click event; place a breakpoint on that, hit RUN and presto,
there's your form, there's your button, off you go. No surprises
there, a naive user will be up and running in no time even though
they've never used VS .NET before.

Ok, let's try the same thing in Netbeans. I'll start with 3.6 and I
realise that at least one issue I'm about to raise is resolved for 4.0
but that is still in beta.

I select new project and, yup, JFrame form looks plausible to me, so I
pick that, and now it asks me where I want to put the project. But
wait, what's going on?. The folder I type gets added onto the END of
the already existing directory name. No, that's not right.....

So, first hurdle, learn about mount points. I can see the use of them
but it's a weird way of looking at the world compared to any other
application. And, yes, Netbeans 4 gets rid of that but, excuse me, how
come it took 4 releases!.

But my problems are not over.

I get past this hurdle and I pick a Swing button off the toolbox and
plunk it on the form... hey, that's weird. I can't move or resize it.

Second hurdle. The layout controls what happens. Instead of sensibly
defaulting to the null layout as a start point, Netbeans defaults to a
layout which will simply prevent me from doing the obvious intuitive
thing of dragging and resizing that button, as I would expect to do.
So now I scratch head for a few minutes, discover the layout tab and
fix that..

Great, I can resize the button. Well, er, something's strange. I think
I'm resizing the form too. Hmm, let's double-click and put a
breakpoint on the click event, anyway.

... ok, would it have killed them to use the de-facto F9 standard?. Oh
well, er, ctrl-shift-f8?. Three keystrokes for maybe the most
commonly-used function in debugging?. And what's this gratuitous
dialogue box for?. At last, a breakpoint!.

JToggle1ActionPerformed. Ah, I guess that'll be the click event. I
guess lots of events get funnelled through there... bit weird, but
hey, lets go with it.

Run program.... Nothing.... Why isn't my form displayed?.

oh yeah, it IS. That tiny little thing in the top corner... just
expand it out and.. hey, there's the button... click it and, hmm,
didn't take the breakpoint.

oh.. you gotta say 'run in debugger!'. Not just 'run'. Wow!

Well, Netbeans 'blows goats' as one poster said. Let's try Eclipse,
shall we.

I mean, 40 million bucks!. Should be good.

Well, install looked easy.... hmm, that's odd. Just unpacked all the
files. Didn't create a desktop shortcut like any other standard app on
the planet. Geez, can't even find it off the start menu. Hmm, where'd
it go.

ah well, go to the command prompt and start it from there.

Eclipse 3.0... cool splash screen..... ok, hmm, sure get a lot of time
to admire it, too!.

Ah, we're up. Now then, file/new/project... pick java project, choose
path.

Create project in workspace.. um, dunno, oh, why not. Doesn't say
where the workspace is, but this is just a test, so hey, let's go with
the flow...

You gotta love the way it tells you if a project name already exists,
too, as you type, but it never occurred to anyone to show you the
project names already stored in the 'workspace', but hey, let's carry
on.

Source folders on build path.... er, Included (all) Excluded (none).
Geez, dunno, I guess....
those other tabs... er, um,.....

oh, hey, ignore it, just press finish.

hmm, doesn't look like we got anything to run yet. JRE system library,
hmm, no, er....

ah well, let's add a class, then... yup, ok....

geez, where's my UI widgets?. er, let's try help....

wow. Cheat sheets, huh!. Let's expand all those steps first and see.

In order to compile the code which uses SWT, you must add the SWT
jar(s) to the Java Build Path.....

Press the 'click to perform' button.

Cool, great, er hang on. What button. I've got a 'click to redo'
button on the first step. There are no buttons on the other
steps.....(A Voice From Heaven booms out 'dear developer, they don't
appear until you do all the previous steps') .... oh, yeah, um....

Well, another year, another disappointment.

I don't know what planet these people are on when it comes to UI
design but if the tools suck so badly its unsurprising that .NET is
eating Java for lunch. I mean, seriously!. I'm sure I can work round
all the initial head-scratching but why the hell should I?. It's just
plain easier to go down the path of least resistance and concentrate
on what I'm actually paid to do, which is DEVELOP SOFTWARE and NOT get
a PhD on 'how to master Eclipse/Netbeans etc'.

I didn't even begin to mention how S...L...O....W these tools are,
too. Doing anything is like wading through molasses, a problem
conspicuously lacking in Visual Studion .NET, which runs very crisply
indeed.

Using these tools feels like being a pianist who must assemble their
own Steinway from a kit before playing a note; a painter who must make
their own brushes and paint; a sculptor forced to make a set of
chisels. And worse, the kit is missing a full set of instructions, the
brushes shed their bristles, and the chisels are too blunt.

PS: I do know about JBuilder. It is certainly better, albeit not free,
which rather negates the purpose of going with Java in the first
place.

Quantcast