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.
Yitzak - 19 Nov 2004 14:29 GMT
No doubt as GUI and debugger VB is excellent.
However so few people know of its pitfalls, even experienced VBers
that I will only use it for front end development. No conincedence
that "implements" - "new" were added to VB 5/6 from Java.
Yes I agree these front ends are clunky and slow to work on. But you
wanna design a back end and implement it in Java and forget about it
esp if it has anything to do with networking. Try this with VB and the
winsock control - where you have to be a Guru.
VB was the glue to hold many 3rd party controls together. They did a
great job in porting it into class orientated. However it never truly
like Java separates the doing part from the defintion part - in VB the
t.l.b is stuck in the dll (can be created separately I know).
There are far too many gotchas in VB now
1. Interface forwading w.r.t binary compatability (easy to get around
by using interfaces)
2. Adding the call syntax as in VB5 I think has opened the door to
some weird probs - you end up passing the address of the array rather
than the array itself
3. Try returning an array from a Property make it suitably large
enough to notice it being copied and VB will copy uncessarily if the
last line of your property assigment is NOT teh array assignment. Try
tracking this one down.
the list goes on and on..
In short used VB for 10 yrs- I particaularily don't trust it now.
There is NO mental model to it. With Java tried a few test cases
understood it and now flying through the code. Wheras in VB I'm
continously thinking there is a gottcha on doing this which I've found
before but cannot remember it.
VB is still a great tool - but not for object models.
Andrew Mayo - 22 Nov 2004 10:37 GMT
> No doubt as GUI and debugger VB is excellent.
>
[quoted text clipped - 7 lines]
> winsock control - where you have to be a Guru.
> [snip]
I completely agree with you that VB has become unnecessarily messy
over the years. But the point of my comments was that VB became
popular not because of technical features in the language but because
the IDE was really intuitive and easy to get started with. This still,
unfortunately, is the case; Visual Studio .NET, VB's successor, is
still much much easier to get to grips with than any of the leading
IDEs for Java.
This seriously impacts the uptake of Java. I personally think Java the
language and the JVM are quite solid and I have no problems with the
clean design of Java compared to VB. I just wish the damn development
tools were more intuitive. As it stands, many development shops will
eschew Java for .NET, not over technical language features, but
because the tools are simply more productive over on the .NET side of
the fence. If the Faustian bargain is to relinquish platform
independence, so be it.
PS: having said this I still think that it is incredibly arrogant of
the Java designers to dismiss properties as 'syntactic sugar' while
having no qualms about implementing inner classes as syntactic sugar
and admitting this.
I also think that the support in the .NET framework for
boxing/unboxing and structs is a good idea; it enables highly
efficient software to be written whereas Java's 'everything is an
object' metaphor, while pure, unfortunately fails to recognise that
the real world is inherently messy and as such, no computer language
that fails to understand this, will ever be a complete solution. After
all, when you need structs, you need 'em badly; if you don't like
them, don't use them!
Still, at this point you start getting into religious wars. I just
deeply regret that the development tools for Java are so inadequate.
Ironically, this isn't a clear limitation of Open Source projects.
After all, Firefox is as slick as they come. Why, oh why, can't Sun
understand this.
Yitzak - 23 Nov 2004 14:07 GMT
The guys who wrote VB esp taking from 3 to 5 deserve a medal, must of
been so hard to keep backward comptablity. But its showing its age.
100% with you on that, it is IMO the best debugger and development
environment. I mean change code as you run!! Catch events etc.
Just wish the back end had Java's syntax/semantics or whatever you
call it which I've understood I still forget the caveats in VB.
But VB doesn't separate the doing part from the defintion part (all in
the same dll) this can confuse newcomers.
C##??? maybe
Personally I like the fact that everything derives from the class -
"class" in Java. Inheritance is its main adavantage over VB (also its
main disadvantage) its very powerful and dangerous concept, if its
done wrong it can be a nightmare to maintain. In a way I prefer VB's
sort of pseudo inheritance where you create an instance of the class
you want to inherit from and just delegate to that - more typing less
functionality than Real inheritance - but much less scope for
disaster.
I think VB became popular because of its scripting nature, e.g. you
needed a Grid you bought an OCX from say sheridan. There are so many
third party controls for VB out there.