steel-wool panty liners = Java?

[John Chambers]

David Kramer wrote:
> 			...  I graduated from a SUNY
> school with a BS in CS, and our curriculm was heavy focused on
> programming theory, rather than languages. ...  The
> point, or so we were told, is so that we can graduate and be adaptable
> to any language we're asked to program in.

Yeah; some schools do a pretty good job of that.  Not that this makes
much  of an impression on employers, who mostly just want to know how
many years experience you have with languages X, Y and Z.

OTOH, a major complaint I've had about java from the start  is  that,
even  when it is available, I often can't discover how to use it.  If
there are "javac" and "java" commands available, sometimes I can  use
them,  though  sometimes  they're such wild variants of anything I've
used before that I can't make much sense of them. It seems that there
are  quite  a lot of different ways that java can be implemented, and
some of them aren't very well documented.

An example that I like to give: If you open up a "C Bible" from  back
in the 70's, and type in literally the "Hello, world" example, you'll
find that it  works  unchanged.   (That  is  unless  you're  on  some
Microsoft  systems,  as  usual  ;-).  Even that silly "a.out" name is
still the default, a senseless relic of a long-gone linker  that  K&R
used on an early machine. C has evolved a lot, and we've had many new
C compilers, but they all preserve this useful bootstrap example.

Chances are that the machine you're  using  now  actually  has  java,
since most browsers now include it along with javascript. But lots of
luck trying to figure out how to type in a simple  java  program  and
run it.  And, unless you can get the dumb little "hello.java" program
to run, all the sophisticated software design knowledge in the  world
won't do you much good.

A really frustrating part of this is that an important  part  of  the
original  design  of java was that it could run on tiny machines that
were on a network.  You only needed to install the top-level  classes
for  the  apps;  others  would be downloaded dynamically as they were
needed.  This way, you didn't need to install  everything  you  might
ever need, and memory was minimized.

But try using this on most of today's java implementations. One of my
test  toys,  for example, is a BlackBerry 7280.  Cool gadget, and the
software is entirely in java.  But to install anything, you  have  to
copy  it  to  a  Windows  system, connect the BB to the machine's USB
port, and run RIM's specialized tools to install things  in  the  BB.
Yes,  the  device  has a full-time Internet connection, anywhere that
there's GPRS or GSM service.  But you can't install software over the
Net,  like  java  was  designed  to do.  So far, I've found that most
installs take several tries, as the Windows code either crashes, goes
zombie, or gives insane failure messages, different every time.