Perceived Flaw with Java

There are several things that annoy me about Java.  Same goes for C# and similar languages.  Albeit - I do respect the "code-behind" feature of C#.

The flaw is not security, it's not performance, it's not syntax, it's the encouraged methodology.  And I'm not complaining about the inner classes used to implement interfaces to receive events (although that could be a rant on it's own).  It's a philosophy that developers must break out of.

Getters and setters - I'm looking at you!

Nothing wrong with getters and setters?  Hmm - let's delve deeper into the perceived problem.  A getter allows code to extract values from a class, and a setter allows us to set values into a class while performing a bit of error correction.  Sounds good so far.

But there's an ominous problem here - and it appears to affect most OOP languages.  The getters and setters - when used improperly (happens more often than not) - bypasses the elegant concept that a class' public methods are simply a gateway to get something to happen and that the underlying implementation can change at will.

Classes should perform a (limited) set of actions and the getters/setters should reflect not the underlying implementation but what the user of the class is expecting.  So often I've seen getters/setters for questionable things that clearly indicate how the underlying implementation must function.  Functions made public for the sake of having them accessible by any other class (since it was convenient).

And XML serialization is making this worse, using reflection to get at the class internals by assuming variables will each have a "getValue" and a "setValue".  The holy-grail of OOP - modular components that can be changed independent as long as they retain the same behavior diminishes as the getters/setters imply an implementation.

I could argue for C-style header files.  However, that wouldn't make a difference - it's a method that I feel Java makes worse.

For example - for most problems - if posed correctly - can be very simple and elegant.  Composition of this simpler problems using classes that expose simple interfaces can keep the program as a whole simple.  However, in reality at times, it's a free-for-all with overly complex function calls... (a big picture view is required to get anything done)

Maybe I'm ranting for nothing?  Maybe things need to expose their complexity?

Flash Coding

For my last pattern recognition assignment (dealing mostly with formants and fundamental frequency of voice), I decided to use Flash/actionscript; and to compare that to my experience of using C# for my previous assignments (which tended to deal with bitmap data). Also -- I've done other (bigger) projects in both; to the scale of over 10 classes (I like to keep my code organized).

C# was fun to program in. There is a panoply of existing objects to quickly get started to do practically anything. Debugging was easy and painless, and the squiqling up of the code like any word document was a nice addition (in comparison to XCode). The language has practically the same semantics as Java (both are managed/in a vm with reference counting galore -- well, a sophisticated version of reference counting). The documentation was easy to read; and I needed no help what-so-ever from Google's web search to complete the assignment (except for the odd bit of code that quickly loaded up the bitmaps).

Flash was fun to program. Admittedly, it is based around a different philosophy of programming. The built-in finite-state machine (aka timeline) made it possible to have very differing screens when buttons on the menu are pressed -- the easiest way to do that in C# would be through big if/else statements, or dynamically loading/unloading components. Debugging is really primitive in Flash -- I have not managed to set up a breakpoint that actually breaks... I'll investigate this later; for now trace is my trusty friend. Since the program is interpreted, some errors it only reports at run time -- and by specifying types, Flash will attempt to say if there will have any errors at run time. This prediction of errors can be wrong -- in the sense that it doesn't find errors, or that it finds non-existant errors. All-in-all, it's quite usable. The documentation, opposed to the one from Sun/XCode feels as though it's as good as the MSDN -- however I did have a bit of trouble the first time I used the BitmapData object -- and still do when it comes to loading images with transparency. Also, errors in the documentation sort of made it difficult... UI is what Flash does much better than C# -- where I'd import a bitmap for a coordinate system, I just draw them in Flash. Lastly, flash is resolution independant (if you don't use bitmaps), and is cross platform -- some nice incentives especially when you're doing all your homework on a Mac, and it will be graded on a PC or Linux box.

All in all, this just shows that Flash is as viable a language as C#/C++ for programming assignments. Actionscript hasn't let me down as a watered down language for designers, but as a nice semi-complete (public, private which acts like protected, no protected) OO implementation.