Antony Courtney wrote:
> But Java also has a way to do "rampant pointer-level
> optimization": You declare a method as "native" and
> then implement it in C.
That's hardly the same thing, though. Of course an FFI allows you do to all
sorts of things, but at least it's very clear, from the fact that you're
using another language, that you are switching paradigms and potentially
doing something dangerous. In fact, I would generalize this a bit further
and say that if you want to do something that violates the paradigm of the
language you're working in, you _should_ do it in another language,
precisely to make the point (to anyone reading your code) that certain
components aren't following the rules.
In C++, this isn't much of an issue because C++ is the all-time paradigm
whore of languages; there basically aren't any rules, and you can do
whatever you like, which is part of why C++ sucks. With STL and some of the
weirder properties of recursive templates, you even almost have a sort of
half-assed functional language. I'm almost surprised that Stroustrop hasn't
tried to build in a real module system, closures, and backtracking; then
he'd have just about everything.
> Any sensible programmer
Most programmers, in my experience, are not sensible.
> will recognize the loss of portability, safety and
> abstraction when writing a native method in Java, and
> will only do so when absolutely necessary. The same
> should go for "unsafe" methods in C# [...]
The difference is that C# allows you to fundamentally design an application
in an unsafe way and still claim (to your manager) that your code is 100%
C#. I'm not kidding; this will happen. Remember that many C# programmers
will be coming from C and C++ where it is perfectly normal to do all sorts
of things that the compiler cannot guarantee to be safe. This leads to all
sorts of bugs such as buffer overflows, stack corruption, page faults
accessing unmapped memory, etc. By making it so convenient to write unsafe
code in C#, Microsoft has essentially given these C/C++ coders an excuse not
to bother learning how to write safe code, and many programmers will take
that excuse.
> Remember, too, that not every program is written as an
> application on a PC. The requirement in Java that native
> methods be implemented in another language caused serious
> problems for the JavaOS and embedded / JVM-on-a-chip
> efforts.
Erlang has the same requirement that code doing unsafe things has to be
written in another language. It is used in a number of embedded systems; in
fact, that's what it was originally intended for. So the argument that you
have to have unsafe features built into the language just doesn't wash.
> How do you write a device driver for a memory-mapped
> device in 100% pure Java? You can't.
And you aren't supposed to. I wouldn't want to write hardware drivers in a
garbage-collected language that allocates all objects on the heap.
Java is not a systems-level language; adding low-level bit-twiddling
features to it would give it some of the same problems that C++ has, with
the low-level features undermining the high-level features and the
requirements of the high-level features interfering with the low-level
features.
Your not-quite-spoken assumption that it should be possible to write
everything in one language is just something I fundamentally disagree with.
The requirements of low-level kernel code are quite different from those of
most user-level applications, and any single language that tries to address
both sets of requirements will do so poorly.
Craig
