I think most C++ programmers realize C++ for what it is, a poorly designed
portable object oriented assembler language. Most C++ programmers use C++
because they program for windows and COM, and the only other real choices of
development environments are VB and Delphi (which I do not know anything
about). VB does not fully support COM development nor object-oriented
programming (nor any other kind of programming really), so developers have
little choice but to play with the C++ gun and hope they do not shoot
themselves in the foot. We use VB when we can and C++ when we must in our
shop.
I think almost every Windows developer is eager to move to the safer world
of C#. However, almost no one is even thinking about FP. I think NGWS will
be the kiss of death for FP in the large -- OO just seems 90 degrees out of
phase with FP.
-----Original Message-----
From: Benjamin Leon Russell [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 14, 2000 8:10 AM
To: Tyson Dowd; [EMAIL PROTECTED]
Cc: Craig Dickson
Subject: Re: Haskell and the NGWS Runtime
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
