::scr usability, languages and apis

[Simon Kinahan]

> Take Java (or don't acually) :
>
> http://java.sun.com/j2se/1.4/docs/api/index.html
>
> Java obviously has guide lines. On an object, to set a variable, you do
>
> $object.setVariable()
>
> and to get it you do
>
> $object.getVariable()

Indeed, although Sun themselves sometimes break these conventions. I've seen
the JDK source code. Parts of it are more evil than you can possibly
imagine.

However, I quite like Java. More than Perl, in fact. Is it possible to have
a useful conversation on whether Java is a good language or not ? The main
reason I like it is that it was the first language to bring things lots of
people think are of academic interest - closures, for instance - to a "blue
collar" audience.

The main thing I dislike is along the lines you mention: The split between
the core language - with primitive types like int and char that behave a bit
like they do in C++, and user developed stuff that behaves more like
Smalltalk, is ugly. Why do I have to write:

int i = i ++;

but:

BigDecimal dec = (new BigDecimal(4.0)).increment();

when they're clearly doing the same thing ? It smells wrong. Even more wrong
is that to put an integer in a Vector you have to do:

Vector.add(new Integer(i));

to wrap the primitive up as an object.

In spite of that, Java seems to be the best common applications language.
Sometimes I find this depressing.

Personally, I'd have made the core behave more like Smalltalk too, but then
would anyone have used it ? I'd guess a lot of people would prefer the whole
language to be more C-like, but then it would be C++, and C++ seems much to
hairy to fill the niche Sun where trying to fill with Java.

> Basically a good API should, where possible be consistent, predictable and
> follow the rule of least surprise.
>
>
> The API i'm using at the moment doesn't do this - it's a very good and
> powerful API but it's not immediatley obvious how things
> interact, sometimes
> because it goes through hoops to remain OO.

Hmm. Looking at the class hierarchy below, it is not one I would recommend
to anyone. Something is clearly wrong with it because you've got
ScrollingTile and ScrollingSprite as unrelated classes. Now, I don't know
whether tiles and sprites scroll the same way or different ways, but at the
very least they need to implement a common interface called, say,
Scrollable.

> java.lang.Object
>   |
>   +--com.bitbull.filmstrip.Sprite
>         |
>         +--com.bitbull.filmstrip.Tile
>         |     |
>         |     +--com.bitbull.filmstrip.scrolling.ScrollingTile
>         |           |
>         |           +--com.bitbull.gameutils.platforms.Solid
>         |
>         +--com.bitbull.filmstrip.scrolling.ScrollingSprite
>
>
>
> The guy who wrote the API told me I should use Solid because my
> Sprite needed
> to have things bounce off it. However I suspect that it won't now scroll
> around the world because it's inherited from Tiles which aren't
> suppsoed to
> push the view of the world around. However ScrollingSprite is missing many
> methods defined in Solid and ScrollingTile which is irritating despite the
> fact that they have similar functionality.

Now, see, I'd have thought that whether something is solid or not, and
whether it scrolls or not, are separate concerns, and therefore should be
encapsulated separately. I spend some of my time teaching training courses
in OO design, and I think the hardest thing to teach people is getting the
correct separation of concerns. Its more like analytic philosophy than
anything one has to do in "just writing code".

In my darker moments, I wonder whether this is because we haven't got OO
quite right yet. Aspect Oriented Programming looks interesting.

Simon