On 11-Aug-2000, Craig Dickson <[EMAIL PROTECTED]> wrote:
> 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.
I agree that you should make it clear to anyone reading (or modifying)
your code that it is breaking the rules. And in fact if you are
using code that breaks the rules (and that rule-breaking is not hidden
behind some suitable abstraction) you should know about it. And possibly
even if you are using rule-breaking code behind an abstraction, you
should be able to know about it.
But I disagree completely that this implies the solution is to switch
language!
> > 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
It is 100% C#.
It's not 100% safe. Any "grep" through the source code will reveal that
since you have to use the unsafe keyword to write unsafe code.
And if you don't have source code, you can verify the output code using
a verifier -- unsafe code will not verify.
> 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.
I don't believe you can teach programmers anything by trying to take
tools away from them.
I believe you can only teach programmers by showing them a better tool.
> > 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.
So long as the unsafe code is clearly labelled as such, and cannot be
confused with safe code why does it have to be in a different language?
Why do you have to sacrifice all the features of the language you are
currently using just because you need to write some unsafe code?
> > 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.
Well that's a language design consideration.
The designers of C# have obviously decided they would like people to
write device drivers in C#.
But that's beside the point. You can write the bit-twiddling parts in C
or assembler in both languages.
The point is that the memory manipulations have to be hidden from the
base system at some level, because the "safe" portion of the languages
(safe C#, or all of Java) is not allowed to see it. This means you have
to introduce a layer to hide the unsafe stuff.
In Java you have to do all this layer in some foreign language.
In C# you can do a large part of this layer in C# (using "unsafe").
What does this mean?
Well in Java all it means is that the implementations don't have to
worry about implementing the unsafe stuff, since it isn't part of the
language. But the consequence is the programmer has to do the low-level
stuff purely in some foreign language, which means all the other good
features in Java have to be sacrificed for this section of the code.
But in C# it means that the programmer is able to use the other features
of C# while writing this layer. Objects, methods, bounds-checked
arrays, whatever takes their fancy. So that might make it easier for
them to write code. Of course the downside is the
implementations have to do more work, because they have to implement
unsafe stuff. And that might mean the implementation isn't as good.
So it looks to me like a classic programming language design tradeoff.
If you can implement the unsafe stuff in a way that doesn't harm
the rest of the implementation, and you can partition the unsafe portion
of the language from the safe portion in a way that is acceptable in
software engineering terms, then the programmers can have an easier time
writing or interfacing to bit-twiddling, pointer manipulation code.
> 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.
Ah, a testable hypothesis!
If you are right, then you should be able to criticize some other
features of the language that have suffered as a result of unsafe
code in C#.
(PS: I argue this case because I believe that features such as mondadic
IO in Haskell, unique modes and impurity declarations in Mercury,
are important language features to allow you to interface with unsafe
code without necessarily giving up all the advantages of high-level
programming).
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
[EMAIL PROTECTED] #
http://www.cs.mu.oz.au/~trd #
