On Sun, 13 Aug 2000 22:36:42 +1000
Tyson Dowd <[EMAIL PROTECTED]> wrote:
> On 11-Aug-2000, Craig Dickson <[EMAIL PROTECTED]> wrote:
> > Antony Courtney wrote:
> >
>
> <stuff deleted></stuff deleted>
>
> > 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.
Aha, but *which* programmers? The C/C++ programmers who will bother learning how to
write safe code, or those who won't?
Many programmers work on teams. Suppose you have 50 programmers on a team working
under a tough time limit, and most of them have just switched from C/C++ (where they
were accustomed to working with unsafe code most of the time) to C#.
Will they choose to learn how to write the bulk of their procedures using safe code
(possibly missing the deadline in the process), or just continue writing lots of
unsafe code (and possibly meeting the deadline, but also likely introducing bugs such
as memory leaks in the process)?
> <stuff deleted></stuff deleted>
>
> 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?
The problem is that many programmers will not focus on the safe features if the unsafe
ones remain.
It takes time to learn a new skill, and if the programmers already know how to write
unsafe code that they are convinced will work (even if it also potentially introduces
bugs), they are not likely suddenly to change their style and to write everything
using safe code whenever possible, even if it happens to be better in each situation.
They are working under pressure and want to meet the deadline. So, they will use
whatever they already feel most comfortable with, including unsafe code even when it
is not necessary.
For example, if the C/C++ programmers are used to explicit memory management using
malloc() and free(), then they are likely to keep writing all their methods using this
old style, even when the running time is not crucial. This could potentially
introduce more memory-related bugs than necessary.
> <stuff deleted></stuff deleted>
>
> 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.
That's a *big* "if," though.
Again, what if the programmers are undisciplined and undertrained former C/C++
programmers (most likely, a large portion of the programmers will be from this group),
and most of the implementation winds up being unsafe? Then what?
Suppose the manager starts the project by requiring that all the programmers write all
non-time-critical portions of their code in pure C#. Suppose that the programmers are
from the above group.
If the language supports unsafe code, then the programmers are likely to write much of
their code using unsafe code, simply because they are used to that style, even when
unsafe code isn't completely necessary.
If the language doesn't support unsafe code, then they are forced to learn how to
write safe code, whether they want to or not, because that is the only way to write
the code.
There is likely to be a difference to the manager between writing much of the code in
another language, and writing much of it in unsafe 100% pure C# code using the
"unsafe" marker: he/she is likely to permit more of the latter than the former. In
addition, the programmers are far more likely to get carried away with writing
unnecessary unsafe 100% pure C# code than they are with writing code in another
language when unnecessary.
> > 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#.
Ah, a testable hypothesis! If you are right, then you should be able to provide an
example of a language that meets the requirements of writing both low-level kernel
code and most user applications equally well for the bulk of the programmers working
with the language!
Benjamin L. Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
