Nieminen Juha wrote:

> Jon A. Cruz <jon### [at] geocitiescom> wrote:
> :>   Btw, a little problem (just for curiosity, not for flaming): Make a
> :> generic swap-function in Java :)
>
> : Here's the solution:
> : "Why?"
>
>   This is the typical answer when there isn't a solution. Perhaps this specific
> example is seldom really useful, but it was only an example. It demonstrates
> that there are some things that can't be done. It shouldn't be very hard to
> think about a similar problem which is more radical but can't be done for
> the same reason.
>   Why is it so hard to admit that there are things that you just can't do
> with java and that you have to live with that if you are coding java?
>   There are things that are very difficult, if not impossible to do with C++
> and I don't have any problem in admitting it. I know that C++ has some very
> bad things. I know that it would need some features which would make it more
> safe. I admit it and I don't have any problem doing it.
>   What I wonder why is it so hard for java coders to admit that java is not
> perfect? Java seems to be a holy thing and if you criticize it you are
> committing blasphemy.
>   Java coders seem to be like windows users: When they can't do something then
> they convince themselves that actually they don't really need it.
>

First of all the "why" solution was not the usual cop-out, but rather in this case
an actual answer that was supposed to make the reader step back a level and switch
from asking "how can I implement this" to "why should I be doing this" (one thing
that more programmers should be doing). But the main intent was to show that the
particular operation in question was not a good architectural choice for Java.

As far as the point that sometimes one should use Java and sometimes one should
use C++, I am in total agreement. I gave an example where Java was a good choice,
then an example where C++ was a good choice. Here's another one. Don't do a
MPEG-II decoder in pure Java. You'll probably only get 50% the performance of
C/C++.

I used to say "Don't try to write games like Quake in Java", but then someone did
an interface library so that you can use Java to write Quake II games. What is
even more interesting is that later versions exposed the Quake map & all it's
objects using the standard DOM architecture. That's the same why you'd examine and
manipulate an HTML document in IE, or most standard XML documents (even in C++).

But I will say again that I think a Java version of POV-Ray is just not the best
idea. If they are planing on doing a native C library to do the number intensive
part, then they would be better off shelling out to call POV-Ray itself. The
resulting Java program would stay cross-platform, and the performance would be
good.

BTW, this is a bit interesting: http://www.cs.brown.edu/people/jks/thesis.html

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message