-- scratch this sentence. Unfinished though ... --

> In the same way that I avoid IOStreams in C++, one tends to avoid pointers in D.

Matthew wrote:
> 
> Further, I'd suggest that an understanding of what goes on beneath the covers is actually a hazardous skill to be lacking.

I very much agree.  In fact, this is my primary issue with the use of Java as a teaching language.  It's nice when the teacher wants to gloss over details to focus on algorithm design or some such, but ignorance of the software-hardware interaction doesn't seem to make for good programmers.


Sean

On 2006-02-12 19:32:47 -0800, nick <nick.atamas@gmail.com> said:

> What's worse, I can use the function prototype:
> 
> void surprise(inout A a);
> 
> and the results will be exactly the same. That just seriously breaks all
> the high level language features that D puts in place. So I guess my
> question is: "Shouldn't there be a mechanism to deal with this?"

If you're working with people who are idiots, they're going to be idiots regardless of a damn unsafe keyword, or a friggin' throws keyword, or whatever!  Language do not fix people.   Writing software is not subject to malicious attacks by hackers.  People are not intentionally injecting bad code into your software!  You do not need security features built into the language.  If it were up to me I'd abolish the private and protected keywords too!  They're rather stupid, their intent is to "recommend" people not to use them.  Quite often, especially in .NET i want to use a protected method and end up having to subclass the F*CKING class to expose it to the rest of my program.

-S.

Matthew wrote:
>> I am in no way trying to attack you. I am just pointing out that C and C++ breeds bad programming practice, and we need protection from them.
> 
> Are you serious?
No, I think I should rephrase myself. My new statement: people who come from a background that's primarily in C and C++ (especially if all they did was take one C or C++ course in college) are likely to use a C-style pointer instead of the appropriate D-style tools. We need a safeguard.

> Similarly, I am not trying to attack you, but this is terribly jejune. C and C++ and pointers are no more or less hazardous than is a hammer or a syringe or a stick of dynamite. If you're bashing in a nail or injecting a patient or excavating a tunnel these are the best tools to have. They do not "breed" bad practice. That comes from process, experience and attitude.
They cause a problem in D. Here is an example:

void surprise( in A a )
{
	byte *ap = cast(byte *)(a);
	ap[9] = 5;
}

If a function like that is part of a library, and I link against it, I may be in for quite a surprise. (There is code in the previous post that demonstrates the badness)


> Walter correctly sought to incorporate pointers in D as first class parts of the language. In the same way that I avoid IOStreams in C++, one tends to avoid pointers in D.

> Bottom line: if you're a good engineer, you're a good engineer. If you're not, you're not. The language used won't affect this truth. And avoiding peaking inside abstractions won't help you become one.
But if you are a good engineer working with people who are good electrical engineers and bad programmers you are in for a void surprise().

I think you are looking at this through the eyes of someone who is an expert programmer, which you are. The fact is many people who program are not experts and you can't change that. It would be nice to have a safeguard against mistakes that they are likely to make. If you can point out why there shouldn't be a safeguard that (similar to the one in C# or a different one) I would like to hear that reason. That's exactly why I posted this thread.


THE OTHER POINT:
---------------
> Further, I'd suggest that an understanding of what goes on beneath the covers is actually a hazardous skill to be lacking. (You might find http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html illustrative of my point.)
I have no beef with that. I must say I am lucky to have made it into and out of my school before it became a Java prepschool. I took the weedout courses even though I had placement APs to get me out of some. You could say "I run gmake and gcc and I ain't never call malloc without calling free".

> C and C++ and pointers are no more or less hazardous than is a hammer or a syringe or a stick of dynamite.
From the Joel on software article:
"Now, I freely admit that programming with pointers is not needed in 90%
of the code written today, and in fact, it's downright dangerous in
production code."


> I'll repeat something I observed here a long time ago: the very worst coding I've come across, by a country mile, was a group of Java "consultants" (from
<SNIP>
> cleaning tools (which, thankfully, were written in a fast language) to start to clear up the junk.
We are mixing two arguments here. If you want to discuss the negative effects of Java prepschools, let's start a new thread for that. I'll join you in bashing them.

S. Chancellor wrote:
> On 2006-02-12 19:32:47 -0800, nick <nick.atamas@gmail.com> said:
> 
>> What's worse, I can use the function prototype:
>>
>> void surprise(inout A a);
>>
>> and the results will be exactly the same. That just seriously breaks all the high level language features that D puts in place. So I guess my question is: "Shouldn't there be a mechanism to deal with this?"
> 
>  Language do not fix people.   Writing software is not subject
> to malicious attacks by hackers.  People are not intentionally injecting
> bad code into your software!  You do not need security features built
> into the language.  If it were up to me I'd abolish the private and
> protected keywords too!  They're rather stupid, their intent is to
> "recommend" people not to use them.  Quite often, especially in .NET i
> want to use a protected method and end up having to subclass the F*CKING
> class to expose it to the rest of my program.
> 
> -S.
> 

Now you're talking crazy talk. Throws declarations may be a bad idea - I agreed after having read up on it. I have yet to hear a good reason why the unsafe keyword or some other safeguard against dangerous pointer code is a bad idea.

I'm just going to quote Joel here:
"Now, I freely admit that programming with pointers is not needed in 90%
of the code written today, and in fact, it's downright dangerous in
production code."

http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html


> If you're working with people who are idiots, they're going to be idiots regardless of a damn unsafe keyword, or a friggin' throws keyword, or whatever!
When will people finally realize that stupid an unexperienced aren't the same thing. Some individuals who write code are mathematicians, physicists, or electrical engineers by training. Programming languages aren't just for hardcore experts like Matthew or Walter. Most programmers are amateurs; you're not going to change that. Furthermore, humans are prone to error.

If you think that safeguards aren't for you, then maybe you should double-check the list of D features: in/out/inout, nested functions, typesafe variadic arguments, contract programming, guaranteed initialization, and others. Are you telling me that all those should be thrown out because they are just there to prevent mistakes?

On Mon, 13 Feb 2006 00:26:48 -0500, nick <nick.atamas@gmail.com> wrote:

> Now you're talking crazy talk. Throws declarations may be a bad idea - I
> agreed after having read up on it. I have yet to hear a good reason why
> the unsafe keyword or some other safeguard against dangerous pointer
> code is a bad idea.
>

Then would 'delete' be 'unsafe'? Even though it nulls the reference, other places may still be referencing it, hence making it unsafe.

"nick" <nick.atamas@gmail.com> wrote in message news:dsp5ak$s35$1@digitaldaemon.com...
> S. Chancellor wrote:
>> On 2006-02-12 19:32:47 -0800, nick <nick.atamas@gmail.com> said:
>>
>>> What's worse, I can use the function prototype:
>>>
>>> void surprise(inout A a);
>>>
>>> and the results will be exactly the same. That just seriously breaks all the high level language features that D puts in place. So I guess my question is: "Shouldn't there be a mechanism to deal with this?"
>>
>>  Language do not fix people.   Writing software is not subject
>> to malicious attacks by hackers.  People are not intentionally injecting
>> bad code into your software!  You do not need security features built
>> into the language.  If it were up to me I'd abolish the private and
>> protected keywords too!  They're rather stupid, their intent is to
>> "recommend" people not to use them.  Quite often, especially in .NET i
>> want to use a protected method and end up having to subclass the F*CKING
>> class to expose it to the rest of my program.
>>
>> -S.
>>
>
> Now you're talking crazy talk. Throws declarations may be a bad idea - I agreed after having read up on it. I have yet to hear a good reason why the unsafe keyword or some other safeguard against dangerous pointer code is a bad idea.
>
> I'm just going to quote Joel here:
> "Now, I freely admit that programming with pointers is not needed in 90%
> of the code written today, and in fact, it's downright dangerous in
> production code."
>
> http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html
>
>
>> If you're working with people who are idiots, they're going to be idiots regardless of a damn unsafe keyword, or a friggin' throws keyword, or whatever!
> When will people finally realize that stupid an unexperienced aren't the same thing. Some individuals who write code are mathematicians, physicists, or electrical engineers by training. Programming languages aren't just for hardcore experts like Matthew or Walter.

LOL! This appelation never fails to make my brain do a "what, you mean me!?!" double-take. Same feeling as getting caught nicking one of mum's cakes, or in-flagrante with one's girlfriend, perhaps. ;-)

> When will people finally realize that stupid an unexperienced aren't the
> same thing. . . . Most
> programmers are amateurs; you're not going to change that. Furthermore,
> humans are prone to error.

True. But you can't hobble "production" programmers to cater for hobbyists. That's just not a go-er. Isn't it better to do what D has done, and allow for the low down and dirty while fostering and promoting a generally more suitable higher-level of abstraction?

Type-safety, const-correctness, and all such things are very good. Basically, whatever you can get the compiler to do for you is a good thing. Just as long as you can circumvent it when you need to. In both these areas, I think D has some way to go, but it's better than most.

Chris Miller wrote:
> On Mon, 13 Feb 2006 00:26:48 -0500, nick <nick.atamas@gmail.com> wrote:
> 
>> Now you're talking crazy talk. Throws declarations may be a bad idea - I agreed after having read up on it. I have yet to hear a good reason why the unsafe keyword or some other safeguard against dangerous pointer code is a bad idea.
>>
> 
> Then would 'delete' be 'unsafe'? Even though it nulls the reference, other places may still be referencing it, hence making it unsafe.

That seems to be an implementation detail. However, my immediate reaction is that delete probably should be unsafe; however, I am not sure. It all depends on how much it is needed for mainstream software development and how much damage it tends to cause.

Of course, if you are talking about overriding new and then calling delete, that's a different story. By allocating memory manually you are preventing a good garbage collector from optimizing your heap, so you should be avoiding that in most cases.

The upshot of using "unsafe" is that all code that messes with the memory manually would get marked unsafe. So, someone working on OS features may end up having to put an "unsafe:" at the top of every file and compiling with the --unsafe flag (or something to that effect). It seems like a small price to pay for preventing amateurs from screwing up your code.

It seems to me that most people who write code don't need pointers. Both D and C++ are languages that provide high-level and low-level access. You are going to get both experts who need the pointers and amateurs who don't need them.

Both Bjarne and Matthew seem to think that people should just "learn to code well". Despite admitting that most coders are not experts, Bjarne says:

"The most direct way of addressing the problems caused by lack of type safety is to provide a range-checked Standard Library based on statically typed containers and base the teaching of C++ on that". <http://public.research.att.com/~bs/rules.pdf>

I must disagree. There are too many people to teach. In some cases it is a lot easier to modify a language than to teach everyone not to use a feature. This may be one of those cases. I think experts tend to forget that a language is there to help programmers develop software and to reduce chances of human error.

"nick" <nick.atamas@gmail.com> wrote in message news:dsp4lg$pul$1@digitaldaemon.com...
> Matthew wrote:
>>> I am in no way trying to attack you. I am just pointing out that C and C++ breeds bad programming practice, and we need protection from them.
>>
>> Are you serious?
> No, I think I should rephrase myself. My new statement: people who come from a background that's primarily in C and C++ (especially if all they did was take one C or C++ course in college) are likely to use a C-style pointer instead of the appropriate D-style tools. We need a safeguard.

That's fair. But I think they're likely to not want to waste their time here, and so will have an open mind to new idioms. That's likely to be of more use and less bother in the long run, I think.

>
>> Similarly, I am not trying to attack you, but this is terribly jejune. C
>> and
>> C++ and pointers are no more or less hazardous than is a hammer or a
>> syringe
>> or a stick of dynamite. If you're bashing in a nail or injecting a
>> patient
>> or excavating a tunnel these are the best tools to have. They do not
>> "breed"
>> bad practice. That comes from process, experience and attitude.
> They cause a problem in D. Here is an example:
>
> void surprise( in A a )
> {
> byte *ap = cast(byte *)(a);
> ap[9] = 5;
> }
>
> If a function like that is part of a library, and I link against it, I may be in for quite a surprise. (There is code in the previous post that demonstrates the badness)

Sorry, I've fully read your post now. Always helps.

The answer's simple: const. One of the continuing crushing advantages that C++ has over D.

But you'll never see it in D. Walter doesn't use it in C/C++, and therefore has only a compiler writer's perspective on it, which is that it is a time-consuming pest to implement correctly with little, if any, use whatsoever because it can be subverted. Surprisingly, I'm from the other viewpoint. const is immensely expressive and powerful, and I wouldn't leave home without it. It is one of the ways I can tame the C++ compiler to do my will.

>> Walter correctly sought to incorporate pointers in D as first class parts
>> of
>> the language. In the same way that I avoid IOStreams in C++, one tends to
>> avoid pointers in D.
>
>> Bottom line: if you're a good engineer, you're a good engineer. If you're not, you're not. The language used won't affect this truth. And avoiding peaking inside abstractions won't help you become one.
> But if you are a good engineer working with people who are good electrical engineers and bad programmers you are in for a void surprise().
>
> I think you are looking at this through the eyes of someone who is an expert programmer, which you are.

More flattery. You've obviously cotton'd on to my crushing insecurity, and its attendant vanity. ;-)

To be fair, I would not claim expert status in anything other than C++ in general, STL extension in particular, and writing very fast recursive directory search libraries. Ha ha ha ha . . . . . . . wibble.

> The fact is many people who program
> are not experts and you can't change that. It would be nice to have a
> safeguard against mistakes that they are likely to make. If you can
> point out why there shouldn't be a safeguard that (similar to the one in
> C# or a different one) I would like to hear that reason. That's exactly
> why I posted this thread.

And now I fully follow your point, I agree that const would be perfect to your requirements.

>> I'll repeat something I observed here a long time ago: the very worst
>> coding
>> I've come across, by a country mile, was a group of Java "consultants"
>> (from
> <SNIP>
>> cleaning tools (which, thankfully, were written in a fast language) to
>> start
>> to clear up the junk.
> We are mixing two arguments here. If you want to discuss the negative effects of Java prepschools, let's start a new thread for that. I'll join you in bashing them.

Nah, it transpires that I only like talking with people with whom I violently disagree. ;-)

What's going to stop them from making other mistakes, unrelated to pointers?  For example, the following:

void surprise(in char[] array)
{
    ubyte[100] x = cast(ubyte[100]) array;
    array[99] = 1;
}

This will compile fine, and uses zero pointers.  It's exactly the same concept, too.  Here's another one:

void surprise(in int i)
{
    if (i == 0 || i > 30)
        return i;
    else
        return surprise(--i);
}

Oops, what happens if i is below 0?  Oh, wait, here's another common mistake I see:

for (int i = 0; i != len; i++)
{
    ...
}

What happens if len is negative?  I've seen this happen, a lot, in more than a few different people's code.  They weren't stupid, you're right, but it did happen.

So do we mark != in fors as "unsafe"?  Recursion too?  And forget casting, any casting is unsafe now as well?

Seems to me like you're going to end up spending longer dealing with their problems, if they think they can use pointers but really can't, than you would just reviewing their darn code.

Oh wait, it's only open source where you do that "code review" thing. Otherwise it's considered a waste of time, except in huge corporations.  Why bother when "unsafe" can just fix everything for you like magic?

Valentine's day is coming up... good thing there are flowers, they just fix everything too.  I can be a jerk and all I need are flowers, right?  Magic.

-[Unknown]


> Matthew wrote:
>>> I am in no way trying to attack you. I am just pointing out that C and
>>> C++ breeds bad programming practice, and we need protection from them.
>> Are you serious?
> No, I think I should rephrase myself. My new statement: people who come
> from a background that's primarily in C and C++ (especially if all they
> did was take one C or C++ course in college) are likely to use a C-style
> pointer instead of the appropriate D-style tools. We need a safeguard.
> 
>> Similarly, I am not trying to attack you, but this is terribly jejune. C and C++ and pointers are no more or less hazardous than is a hammer or a syringe or a stick of dynamite. If you're bashing in a nail or injecting a patient or excavating a tunnel these are the best tools to have. They do not "breed" bad practice. That comes from process, experience and attitude.
> They cause a problem in D. Here is an example:
> 
> void surprise( in A a )
> {
> 	byte *ap = cast(byte *)(a);
> 	ap[9] = 5;	
> }
> 
> If a function like that is part of a library, and I link against it, I
> may be in for quite a surprise. (There is code in the previous post that
> demonstrates the badness)
> 
> 
>> Walter correctly sought to incorporate pointers in D as first class parts of the language. In the same way that I avoid IOStreams in C++, one tends to avoid pointers in D.
> 
>> Bottom line: if you're a good engineer, you're a good engineer. If you're not, you're not. The language used won't affect this truth. And avoiding peaking inside abstractions won't help you become one.
> But if you are a good engineer working with people who are good
> electrical engineers and bad programmers you are in for a void surprise().
> 
> I think you are looking at this through the eyes of someone who is an
> expert programmer, which you are. The fact is many people who program
> are not experts and you can't change that. It would be nice to have a
> safeguard against mistakes that they are likely to make. If you can
> point out why there shouldn't be a safeguard that (similar to the one in
> C# or a different one) I would like to hear that reason. That's exactly
> why I posted this thread.
> 
> 
> THE OTHER POINT:
> ---------------
>> Further, I'd suggest that an understanding of what goes on beneath the covers is actually a hazardous skill to be lacking. (You might find http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html illustrative of my point.)
> I have no beef with that. I must say I am lucky to have made it into and
> out of my school before it became a Java prepschool. I took the weedout
> courses even though I had placement APs to get me out of some. You could
> say "I run gmake and gcc and I ain't never call malloc without calling
> free".
> 
>> C and C++ and pointers are no more or less hazardous than is a hammer or a syringe or a stick of dynamite.
> From the Joel on software article:
> "Now, I freely admit that programming with pointers is not needed in 90%
> of the code written today, and in fact, it's downright dangerous in
> production code."
> 
> 
>> I'll repeat something I observed here a long time ago: the very worst coding I've come across, by a country mile, was a group of Java "consultants" (from 
> <SNIP>
>> cleaning tools (which, thankfully, were written in a fast language) to start to clear up the junk.
> We are mixing two arguments here. If you want to discuss the negative
> effects of Java prepschools, let's start a new thread for that. I'll
> join you in bashing them.