Banned Erlang

[Luke Gorrie]

"Joakim G." <jocke@REDACTED> writes:

> >>It looks like some department made a deal with Rational.
> >>No wonder they don't like UML on this list. :)
> >
> >My totally unbiased opinion about UML is that it is
> >inherently unsuitable for telecom systems programming.
> >
> My totally unbiased opinion about UML is that it is inherently
> unsuitable.

My totally unbiased opinion is that UML is in fact useful for Java
programs.

In my experience, the thing about a typical "properly" OO-designed
java program is that each file tends to be very small and to contain
very little information. From a filename alone, you probably can't
tell whether a file is implementing major functionality, or just a
trivial interface declaration. And when you do open up a real file,
you can't really tell what other files it's calling, because most
things are going through a level of indirection via an interface,
which can be very cumbersome and difficult to "resolve" using just
emacs and grep. To make things harder, a typical Java program probably
has at least ten times as many source files as the equivalent Erlang
program.

It can be very time consuming to figure out "which way is up", where
the real work is done, and how it all fits together. This is where UML
actually does help, by showing you what is just interface glue, what
is actually implementing things, and hiding irrelevant details. Even
automatically generated UML can save you a lot of time in 'grep' and
'wc' trying to figure out where the real work is done :-)

So, I do think it's "a high tech solution to the wrong problem", but
not actually useless if you're hacking java. YMMV.

Actually, coming up with high tech solutions to artificial problems
seems like a major theme in Java-like languages. For example,
Aspect-Oriented Programming is generating a lot of excitement in OO
circles, and one of the central ideas is "Gee, we have this 'ravioli
code' where nobody knows (or is supposed to know) how the other parts
work, so how do we handle the stuff that doesn't fit inside individual
objects, like concurrency? We'll bolt it on the side and call it 'an
aspect'.."

The Design Patterns people are doing similar things with distributed
programming, to come up with fancy ways to keep things looking
object-oriented but actually be able to understand what is going over
the wire and when.

Ditto the people trying to make relational databases look object-oriented.

Questions like "Hey, wouldn't it be easier if we just wrote this
database program in relational style?" don't seem to come up :-)

Cheers,
Luke