View mode: basic / threaded / horizontal-split · Log in · Help
February 13, 2006
Re: unsafe
-- scratch this sentence. Unfinished though ... --

> In the same way that I avoid IOStreams in C++, one tends to avoid pointers 
> in D.
February 13, 2006
Re: unsafe
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
February 13, 2006
Re: unsafe
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.
February 13, 2006
Re: unsafe
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.
February 13, 2006
Re: unsafe
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?
February 13, 2006
Re: unsafe
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.
February 13, 2006
Re: 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.
February 13, 2006
Re: unsafe
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.
February 13, 2006
Re: unsafe
"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. ;-)
February 13, 2006
Re: unsafe
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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home