The Joy of Java

[Jim McCoy]

Perry writes:
> Scott Brickner writes:
> > True.  It's still lacking a couple of (non-language) features.  The
> > most important (and most cpunks relevant) is a mechanism to pay people
> > to run programs for you.  This sort of thing is dangerous without a
> > safe environment.

This is not as far away as you might think.  Trust me... :)

> You can do that safely without making it dangerous for your machine. I
> know how I would build a restricted execution environment for such
> markets. However, Java is 1) too slow, since if you are selling
> rendering cycles or such you don't want to be running an interpreter,
> 2) insufficently safe, and 3) paradoxically, insufficiently powerful
> for the sort of code you would want to run in such an environment.

Wow, three incorrect assumption in a single sentence, another hat-trick for
Perry.  Speed of execution is not a major problem given JIT compiler and
interpreter improvements; this has been broadcast far and wide on the net
so your presumed ignorance of this is a bit hard to believe.  Additionally,
if you are buying cycles off the net you can set things up to run in
parallel and accomplish more than you ever could without the ability. To
farm out code.  This is absolutely trivial when it comes to tasks which
are inherently easy to break into chunks which can be run in this fashion
(like rendering and ray-tracing, etc.)  As far as safety goes there are a
lot of people working on this problem and for tasks of this type it is not
as difficult as you assume.  As far as it being insufficiently powerful for
running distributed computation and cycle serving I know know for a fact
that this is not the case.

Rather than trying (and often failing) to prove that unsolvable problems
exist in Java why don't you present the net with an alternative that does
not suffer from these limitations.

jim