Benjamin Leon Russell wrote:
> Tyson Dowd <[EMAIL PROTECTED]> wrote:
> > On 11-Aug-2000, Craig Dickson <[EMAIL PROTECTED]> 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?
[...]
> The problem is that many programmers will not focus on the
> safe features if the unsafe ones remain.
Exactly. For example, many C programmers use "goto" habitually, even though
there are better solutions even in C.
I, personally, have no problem with learning new paradigms; in fact, I like
it. I regard learning a new programming language as essentially getting an
inside view of someone else's ideas of how programming should be done, and
so I go out of my way to learn the "correct" style for that language.
<rant>
But I work with a number of people who I don't think have bothered learning
any really different ideas about programming since graduating back in the
mid-80s. They write C++ as if it were C, after ten years of working
exclusively in C++. Sure, they call their structs "classes" now, and the
classes have methods, but all their data members are public, and if they
need a list of objects, they just give each object a "next" pointer instead
of using a separate list class. The company's C++ style guide, when I was
hired, contained pearls of wisdom such as "Declare all methods virtual" and
"Never use static members". The company's chief engineer (now chief
architect) habitually violates Microsoft's Windows coding guidelines left
and right because she thinks it makes the code "easier to read" -- never
mind that it doesn't work. I'm sorry, but I just don't think these people
will, of their own volition, learn how to write "safe" C#. They'll just
write unsafe C# because it's more convenient. "After all," they'll say, "my
code is valid C# too, so it's just as good as yours. It's just a matter of
style."
</rant>
Now, on the other hand, if they need to work in C#, and if C# didn't have
"unsafe" features, instead merely having a decent FFI, these folks might get
the idea that safe code is the way to go.
> 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.
<rant>
One thing I've noticed with C/C++ programmers, particularly (which is,
again, the pool from which most C# programmers will be drawn), is that many
of them are convinced that they can handle dangerous techniques which
experience shows they can't handle. They say things such as, "I like doing
my own memory management, because it gives me more control," but their code
continually suffers from memory leaks and other pointer-related problems
that show quite clearly that they are not to be trusted with these things
that give them "more control". This, in my view, is just one more reason why
"unsafe" features should not be built into mass-market languages like C#.
</rant>
> 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!
I think this is a better hypothesis to test than Tyson's. For one thing, to
really be able to say what problems exist in C# as a language, and how the
desire to be both a high-level applications language and a low-level kernel
language plays a role in those problems, will take time and experience with
C#. A lot of the things I now dislike about C++ took me a long time to
really understand.
I realize, of course, that it probably seems very convenient for me that I
prefer the hypothesis that puts the burden of proof on the other party. Of
course it is. But I think history, so far, shows that attempts to make a
language that is "universal" or "good for everything" have resulted in
languages that are too complicated. It may be _possible_ to use them for
everything, but they aren't really all that well-suited for anything.
Because of this, I tend to be suspicious when a language tries to reach too
far. From what I've seen of C#, it would have been a decent Java-like
language without the "unsafe" features; and I don't see why C# is any better
for having them, considering that part of the point the NGWS framework is
that it makes it easy for different languages to work together.
Craig
