🚀 go-pugleaf

lee@Unify.com (Lee Crocker) wrote:

>Sun's current attitude about AWT offers little hope.  They seem to
>think that they can achieve portability by making AWT a subset of the
>functionality of existing GUIs; but that attitude is backwards.  To be
>truly portable, it must be a superset of existing GUIs, emulating those
>functions specific to each on the others in a portable way, and letting
>developers query the system for its capabilities in a portable way.

This is a tricky one.  Traditionally multi-platform systems have either
gone the way of "largest common subset" or "emulated superset", both
methods have their pro's and con's.  I expect that in the case of Java, the
largest common subset was the quickest and easiest way to get Java into the
hands of developers on as many platforms as possible.  If they'd gone the
other way we'd all still be playing with console-mode apps at present.

Having said that I'd have to agree that the present AWT is sadly lacking -
but it is adequate for the point on the learning curve that many new Java
recruits are at.

Let's face it, Java has a way to go yet before its ready for the big-time
and here's hoping that we see an alternative (Sun-approved or sourced)
user-interface class library soon.

>There is never any excuse to sacrifice functionality for portability.
>Ever.  Users demand--and rightly so--that they be able to take full
>advantage of every dollar they've spent on their hardware and software,
>and if they hear "well, we could do that but it wouldn't be portable"
>from a vendor, they'll go to a vendor that will do it non-portably.

In a production environment that is true - but as I mentioined above,
nobody really believes that Java is ready for production-quality
development yet - or if they do then they may get a few surprises :-)

>As a developer, if I can earn 10 cents more by writing a non-portable
>program, I will, without the slightest twinge of guilt.

I think that the goal of total platform independence is a laudable one and
given the choice I'd opt for a Java solution every time.  Why should I be
tied to one platform when by using the right tool I can have a much wider
choice.  If the client has performance concerns then they can throw more
silicon at the problem.  Silicon is still a *lot* cheaper than programmer
hours and the price disparity will only widen in the future.

>The only way to ensure portability, therefore, is the ensure that a
>portable program is capable of doing everything the software needs 
>to do, and AWT doesn't even come close.  The glaring omissions for
>me are things like right-button popup menus, native video support
>(for example, being able to query the system for its color capabilities
>and things like monitor gamma, and then optimizing my diplay for it),
>portable virtual keys for things like arrow and cut/paste, better
>font metrics, and about 1000 more system properties.

It's the eternal tradeoff of complexity versus functionality.  I think
you'll find that most developers will settle for less than 100%
functionality if it means that their job is easier and the results are
acceptable.  Look at the proliferation of tools such as high-level database
languages which are imensely powerful but at the same time force the user
into very narrow design choices in many areas.  Most programmers are more
than happy to accept the limitations in return for the greatly enhanced
productivity or they'd be writing in C/C++.

Give the customer the choice between a $100 application that's a 90% fit
and a $10,000 application that's a 100% fit and 99 times out of 100 you'll
sell the $100 app.  Of course there's always room for that $10,000 app and
there will always be a job for those who create them, but I think it's
important to realise where the mainstream markets lie.

>Just one man's rant.  Thanks for the soapbox :-)

My turn over... next please!  :-)

--------------------------------------------------------------
Aardvark - an weekly net-magazine taking a look at the 
internet in NZ and around the world.
http://www.voyager.co.nz/~bsimpson/aardvark.htm