Heinz, do you remember the text book we had at UCT called "C for yourself"?
I think it was (co) written by Riel Smit...

In the introduction there was a description of programming in languages like
Pascal as being like flying a large commercial airline jet with safety
controls and auto pilot and everything to make the flight as comfortable and
safe as possible. On the other hand programming in C was like flying a
microlight: you have full manual control at your finger tips, which gives
you the  power to do acrobatics in the air. But with that power comes risk -
a small mistake up there and you're off to join the choir invisible.

I commented on ctJUG years ago on how I prefer manual controls over
automatic control. Maybe I'm a control freak, or just paranoid, but I like
to at least get familiar with manual controls, and master it fairly well,
before I allow some automatic system to control a device for me. I mentioned
how I prefer manual shift gears in a car over automatic transmission, and I
was dabbling in some experimental photography at the time using an old
Pentax K1000 where everything was done manually, and only a tiny battery was
required to power the light sensor.

I have since revised my opinion somewhat. While I still want to be able to
master manual controls, there are times when automatic controls are just too
convenient to ignore. But I am not ready to give up manual control
completely. I am most comfortable with technology that provides me with
automatic control when I want it, yet allows me full manual override when I
want to take control of
some aspect.

For example: I enjoy(ed - until it was stolen) my Fujifilm S100FS I bought
last year. It had good autofocus and low light sensitivity. Putting it in
auto mode enabled me to take good quality "run-o'-the-mill" pictures -
especially when I didn't have the time (or couldn't be bothered) to make
manual adjustments. One evening there was a beautiful full moon, so I tried
to take a picture of it under auto settings, using a tripod for shake
reduction. The result was, well, rubbish. So, I did some reading up on
aperture sizes and shutter speeds, found out what should work and did some
experimentation under full manual control. The result was that I ended up
with a few fairly decent shots showing loads more detail of the moon's
surface than anything I could achieve under automatic settings.

Similarly, my first experience of driving an automatic car was awful. I
hated it and never considered buying myself anything other than a manual
shift gear car. Yet, when I visited the US many years later, I was only able
to rent an automatic car, and it didn't feel that bad that time. Perhaps the
technology improved over the years, making automatic transmission more
responsive, or maybe I was just getting lazy with such creature comforts.
Still, if I were a rally driver I wouldn't dream of driving a automatic.

In the light of the tragic recent air disaster, I noticed a discussion on
Slashdot today on modern autopilot features versus full manual override:


http://tech.slashdot.org/story/09/06/09/0035253/Computers-Key-To-Air-France-Crash

Technology improves our lives in many ways, but we face grave danger when we
place too much trust in technology. Years ago I read a book called "Why
Things Bite Back" by Edward Tenner:

  http://www.amazon.com/Why-Things-Bite-Back-Consequences/dp/0679747567

My take on it all is that automatic control is good and helps us achieve
"common" tasks easier and faster. However, when faced with extreme
conditions, a skilled human at the controls has immense value. It is those
fringe cases that push the limits that one needs to be wary of, and where
one cannot rely on technology alone to do the job for us. The pilot who
landed the Airbus on the Hudson river is a good example of an exceptional
circumstance that probably wouldn't have been catered for in the auto-pilot
software.

Good technology does the job quietly, but gets out of the way when you don't
want it:

  http://tech.slashdot.org/comments.pl?sid=1261521&cid=28261799

Zen and the Art of Motorcycle Maintenance comes to mind: technology is your
ally if you take the time and put in the effort to understand it and know
it. If you don't know technology, and it fails you, you are likely to
respond emotionally, cursing that damn machine that didn't do what you
assumed it should have done. And that is the fundamental reason why I prefer
working on Open technology, which Java is: it allows you to look "under the
hood" to get to know the technology better.

At high school I took apart my motorbike engine and put it back together
again. When the reed valve (between the carburetor and the piston chamber)
broke one day far from home, I bought a can of Coke, drank it, then cut out
a replacement part from the empty coke can which managed to do the job until
I got home (and beyond). If I never had the chance to tinker in my Dad's
garage as a ten year old go-kart enthusiast, and if I had never taken my
motorbike engine apart, I would never have built up the knowledge and skill
to improvise in such a way.

After school I drove an old Renault 4, which had no fancy modern engine
technology like electronic ignition and electric windows and stuff. It broke
down occasionally, but I was always able to fix it myself, learning a lot
about car engines in the process. Nowadays I drive an Opel, that I have
never dared (bothered) to look under the hood of - partly because I don't
have the  time to tinker, but also because it's just way too complex for a
novice like me. When it was idling too low, I asked the mechanic around the
corner if he could adjust the air/fuel mixture on the carburetor to attain
the correct idling speed. He shook his head and told me that I'd need to
take it to an official Opel garage to do that sort of thing - you need to
hook it up to a computer to do that! I have since lost all interest in the
internal combustion engine - it's just not fun when I can't tinker under the
hood, and frankly I can't be bothered anymore - I want things to just work.
And it is far more reliable than the old Renault - it's just that if
something goes wrong now, I wouldn't have a clue how to fix it.

Now, from planes, cameras and automobiles (not quite the title of a
blockbuster movie) back to Java...

Since Java has achieved such widespread adoption, and has been under the
scrutiny of specialists like Heinz and others, it has been pushed into areas
that the designers may not have anticipated - just as the designers of the
software on the Airbus couldn't cover the case of needing to navigate to a
river and land the plane in it safely.

There is a need for balance: I don't want to go back to the days of having
to manually manage memory with malloc/free and the headaches that it causes.
Java's memory management was a godsend, as I mentioned before, and there is
huge value in having automated garbage collection. As with car engines, I
just cannot be bothered with having to manage memory any more when there is
a (sufficiently) good garbage collector that can take care of such matters
for me.

However, it has made some (many?) programmers sloppy. It encourages
excessive object creation - especially when combined with other handy
features like the '+' string concatenation operator.

I believe that a good airline pilot needs many hours of manual flight
experience, and needs to keep up those skills in the same way that musicians
needs to keep working at their art. Similarly, programmers need to keep up
their skills, and explore a bit "under the hood", perhaps do some manual
memory management from time to time - if only to remind them how valuable a
good garbage collector is, while realizing that it won't be ideal under all
circumstances.

Just as aeroplanes can encounter extreme conditions, and just as I might
want to shoot a photo that requires that I understand and apply the
principles of photography better in order to take an extraordinary
photograph, we occasionally run into fringe use cases that requires of us
not to rely overly much on the garbage collector, and to understand what is
happening "under the hood".

And this is where experienced Java programmers like Heinz and a good few
others on ctJUG can help a young programmer like Johan Mynhardt on his way
to learning Java and become aware of the pitfalls and gotchas in the
language so that he can evolve into a competent Java programmer. And not
only beginners - I have loads to learn myself - it is a never-ending path of
discovery and mind exercising, which is one of the reasons I like being in
this industry.

So, onto some practical technical stuff...

public void f() {
  {
    byte[] data = new byte[40 * 1024 * 1024];
  }
  byte[] data2 = new byte[40 * 1024 * 1042];
}

I'll leave a detailed discussion of this issue to Heinz as he has taken the
initiative already with his latest Java Specialist newsletter, so I expect
he will provide further insight in a follow-up newsletter.

For now I'll just say that, if one is aware that some garbage collection
features are unspecified and dependent on JVM implementors, then one will
have an idea what to do to reduce the risk of such code causing a crash. So,
there are some common good practices that will make your code "safer" when
used in fringe cases.

That said, I for one would prefer to see the JVM specification tightened up
in such cases so that the behaviour is more predictable and without
surprizes. Such inconsistencies due to JVM-specific implementations are
cases of technology "biting back": Just as you were getting comfortable and
used to the luxury of having a garbage collector, it does something
unexpected, and now you're stuck with a bug that boggles your mind.

This is precisely where I might want a bit more manual control to override
the behaviour of the automatic garbage collector: where I want to be able to
explicitly tell the JVM: "I am done with this particular chunk of memory,
and now I want you to free it up. Now! Not when you get around to it. I want
you to free it up because I no longer need it and I am going to ask you for
an even larger chunk of memory soon, so release this memory now."

But wait a minute: who am I to order the garbage collector around like that?
How can it manage memory effectively if I'm constantly interfering? Perhaps
assigning null is sufficient... and what if I learnt that assigning null at
the end of a method is redundant, yet I need to assign null in some
circumstances at the end of a closure? It seems inconsistent and yet another
thing that I need to remember to avoid crashes.

Sigh. What to do? Either the language/JVM specification needs to be
tightened up to behave in a more consistent and predictable manner, or else
the programmer needs some form of manual control to override the automatic
behaviour when he wants to do something less ordinary. But allowing certain
aspects to differ among JVM implementations seems problematic...  and it
seems to blur the lines between the language and the platform: having a
local variable go out of scope affects its visibility, but it doesn't
necessarily make it available for garbage collection.

I find Heinz's second example quite intriguing, mostly because I haven't
been able to reproduce it:

public class Foo {
  private int x,y;
  public void f() {
    int a = x;
    y = 3;
  }
  public void g() {
    int b = y;
    x = 4;
  }
}

Heinz, can you show us under what circumstances you could end up with a
result of a=3 AND b=4?

I've tried and I haven't succeeded in getting such a result - unless I
invoke either method more than once. You've piqued my curiosity - I'm just
frustrated now that I cannot achieve the result you mentioned.

Overall, Java's automatic garbage collection is probably the one feature
that makes it so much more productive and easy to use compared to C/C++.

Curious, investigative programmers will always discover "corner cases" that
make us scratch our heads in amazement and disbelief.  This is not
unexpected: *any* language that becomes as widely adopted as Java will face
similar levels of scrutiny, revealing warts/pitfalls/gotchas that people
thought would not be possible. And that is a good thing - iff those guiding
the language take heed and do something about it.

But on balance, outside of such "corner cases", things work pretty well and
it's suitable for most enterprise applications. Would I feel safe knowing
that the aircraft I'm flying in is controlled by Java code..? Hmmm...
probably not.  I wouldn't use Java for such mission-critical applications.
Java has found it's niche in server-side enterprise development, which is
why you need other languages in your toolbox if you want to push the
envelope or venture outside of the enterprise space.

I concede that in the sense of the sheer scale of Java's use in the
enterprise, it is becoming as entrenched in legacy usage as COBOL was. There
are probably already billion of lines of Java code in enterprises - some of
it slowly gathering dust. But unlike COBOL, it is also being used by more
dynamic organizations and individuals. And, overall, Java "culture" is very
different from COBOL culture.

Also, in terms of the direction, size and complexity of the language, it is
becoming as complex and difficult as C++.

Maybe those in charge will clean up some of the legacy warts and
inconsistencies. And if they don't then perhaps younger/smaller languages
will witness what has happened in Java in order to avoid making similar
mistakes as they evolve.

But there is another possibility: that programming in Java will become the
domain of experienced specialists, and that other programmers will start
building Java applications by way of dynamic languages that run on the JVM:
Jython/JRuby/Groovy/etc.

That way they won't need to concern themselves with the pitfalls and gotchas
of "Java the Language", while taking advantage of
"Java the Platform" underneath.

I think there is a good chance of this happening: that Java will provide a
virtual abstraction layer that other languages can co-habitate. This is
something that the guardians of Java resisted initially, but I think that it
is changing as people realize that the value is more in the platform than
the language alone, and that attracting potential programmers who would like
to develop for the Java Platform using a "simpler" or "younger" language has
long term benefits.

So, ultimately Johan's question on whether or not to use Java might turn
into: "I've chosen Java as a Platform, but now I need to choose whether I'm
going to become a Java Language specialist or a Java Programmer in the
language of my choice?"

Johan.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "CTJUG Forum" group.
To post to this group, send email to CTJUG-Forum@goog...
To unsubscribe from this group, send email to CTJUG-Forum-unsubscribe@goog...
For more options, visit this group at http://groups.google.com/group/CTJUG-Forum
For the ctjug home page see http://www.ctjug.org.za
For jobs see http://gamatamjobs.appspot.com/
-~----------~----~----~----~------~----~------~--~---