November 18, 2005
Sean Kelly wrote:

> Munch wrote:
>> One really useful thing in specifying post conditions is to be able to get at
>> the value of the parameters as they were when they were passed in. Is there
>> syntax for that?
> 
> 
> Not at the moment, though it would be nice.  Currently, the easiest thing here would be to use thread local storage to temporarily maintain copies of parameter data for comparison later.  I'm planning on adding TLS support to Ares and when I do I suppose I should submit a patch for Phobos as well.
> 

Thanks. That's a possible workaround, but I'd be very nervous delivering code where the contracts had side effects like that. Looking at the level of responses on this vs the braces suggestion, I'm guessing nobody has really thought about this one before? It really would be very useful to be able to differentiate between the "in" and "out" values of parameters in an out block. I'm assuming it's Walter who we'd need to talk to about this?

Would it be useful to kick this off again in a separate thread so that people can see it through the braces argument?

Munch
November 18, 2005
In article <dlkk2p$15cr$1@digitaldaemon.com>, Munchgreeble says...
>
>Unknown W. Brackets wrote:
>> Don't get me wrong; I understand that if you were used to braces always being there, you might make the mistake.  We're all only human.  But... and again, with all due respect... it seems to me such a weird mistake to make.
>
>Actually in my experience this mistake is more often made by newer programmers who haven't got used to using brackets yet. Since I work with a wide range of programmers, from "just graduated" to 35 years on the job, if we're going to move our teams over to using D in the future (and I'd like us to) I'm looking for a language that is suitable for all
>  programmers. As an aside though, like you say, we are all human. When
>it's late and you're tired and haven't eaten and the deadlines looming and you also know your family is wanting you home etc. etc. it's very easy to add a line of debug and forget to add the braces. It's not so much about the kind of mistake - sure it's fairly rare - but given the ease of fixing it -why not?
>
>I can appreciate the "vertical real estate" argument, but in that case how about:
>
>    if (cond) {
>       blah; }
>
>Or even:
>
>    if (cond) { blah; }
>
>I hear Bruno's point about auto indent, and the lint ideas, compiler warning flags etc. but surely the whole spirit of D is to include this stuff _in_the_language_ otherwise people end up not using it.
>
>Cheers
>
>Munch


but heres the thing.... a lot of people simply DONT NEED IT. In fact I cant believe anyone actually wants this.

and im sorry but this is ugly:
>    if (cond) {
>       blah; }


I mean come on, this is like those people who want to put breathalizer interlocks on all cars because some people drive drunk. is the world going mad?


November 18, 2005
In article <dlkl1b$16c6$1@digitaldaemon.com>, JT says...
>
>In article <dlkk2p$15cr$1@digitaldaemon.com>, Munchgreeble says...
>>
>>Unknown W. Brackets wrote:
>>> Don't get me wrong; I understand that if you were used to braces always being there, you might make the mistake.  We're all only human.  But... and again, with all due respect... it seems to me such a weird mistake to make.
>>
>>Actually in my experience this mistake is more often made by newer programmers who haven't got used to using brackets yet. Since I work with a wide range of programmers, from "just graduated" to 35 years on the job, if we're going to move our teams over to using D in the future (and I'd like us to) I'm looking for a language that is suitable for all
>>  programmers. As an aside though, like you say, we are all human. When
>>it's late and you're tired and haven't eaten and the deadlines looming and you also know your family is wanting you home etc. etc. it's very easy to add a line of debug and forget to add the braces. It's not so much about the kind of mistake - sure it's fairly rare - but given the ease of fixing it -why not?
>>
>>I can appreciate the "vertical real estate" argument, but in that case how about:
>>
>>    if (cond) {
>>       blah; }
>>
>>Or even:
>>
>>    if (cond) { blah; }
>>
>>I hear Bruno's point about auto indent, and the lint ideas, compiler warning flags etc. but surely the whole spirit of D is to include this stuff _in_the_language_ otherwise people end up not using it.
>>
>>Cheers
>>
>>Munch
>
>
>but heres the thing.... a lot of people simply DONT NEED IT. In fact I cant believe anyone actually wants this.
>
>and im sorry but this is ugly:
>>    if (cond) {
>>       blah; }
>
>
>I mean come on, this is like those people who want to put breathalizer interlocks on all cars because some people drive drunk. is the world going mad?
>
>

Sorry I didnt mean to be rude or anything, and I can understand why some people would find this usefull. I simply cannot understand wanting to impose this on everyone, because, to me, its actually a style issue more than anything....



November 18, 2005
From the 'What is D' page: "It doesn't come with a VM, a religion, or an overriding philosophy. It's a practical language for practical programmers who need to get the job done quickly, reliably, and leave behind maintainable, easy to understand code."

It appears forcing to use {} is dangerously close to having a 'religion' or 'overriding philosophy,' and yet if it produces more maintainable code it might be worth it. I'm more on the ledge leaning away from it however, simply because I couldn't do my favorite 'debug writef' lines anymore.

Munch wrote:
> OK so here is my other suggestion. It's very simple to implement from a compiler
> perspective - it adds robustness - it just needs a slight rearangement of the
> sytnax. I found a thread on it in the archives here:
> http://www.digitalmars.com/d/archives/1418.html
> 
> Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
> 
> while (i < 9)
> i++; j++;
> 
> or this
> 
> if (cond)
> <debug statement added to find bug>;
> <line of code intended to be conditional>;
> 
> or more generally
> 
> if (cond)
> <added code here>;
> <ORIGINAL conditional line of code>; <and/or more added code>;
> <and/or more added code>;
> 
> This is one of those things that when you start out coding you kid yourself that
> you save time by skipping out the braces. As the years roll by you gradually
> come across bugs that are harder and harder to find, that had part of their
> cause in missing curlys. Sooner or later you learn to use braces everywhere. I
> occasionally do code reviews and whenever I've come across code which doesn't
> have curlys everywhere, I know I'm likely to find a bug somewhere in the code.
> This is easy to fix in the language syntax, thus:
> 
> IfStatement:
> if ( Expression ) BlockStatement
> if ( Expression ) BlockStatement else BlockStatement
> if ( Expression ) BlockStatement else IfStatement
> 
> Not enough motivation yet? Finally, this also kills one of the most insidious
> bugs in C/C++/Java:
> 
> if (cond);
> <code intended to be conditional>
> 
> I've only done this a few times in my programming life, mainly in the first few
> years, but boy did some of those bugs take a long time to find. Note that this
> one can't be fixed by voluntarily entering braces yourself:
> 
> if (cond);
> {
> <code intended to be conditional>
> }
> 
> The above syntax however, makes this a compile time error =)
> 
> (Obviously the above also applies to "for", "while" etc. )
> 
> Regards
> 
> Munch
> 
> 
November 18, 2005
Again, it sounds like coding standards enforcement is what you really want, and it's something I'm greatly interested in myself.

Since I always use versioning systems whenever possible, it would probably also be workable to simply have a pre-checkin script/program which checks coding standards (and luckily, D is much much easier to parse.)  Still, it seems like the compiler - which already parses it, and has the most semantic logic - would be a great place to do it.

Thing is, I'm a real prude with my coding standards.  Having a { anywhere but on a line by itself properly indented would only be considered a bug by me.  In fact, I even treat mispellings and space at the end of lines similarly.  I've even had compliments on how clean, understandable, and commented my code and the code of those I've directed has been.

Still, it's very hard to enforce standards in larger projects... something automated would be great.

-[Unknown]


> Actually in my experience this mistake is more often made by newer programmers who haven't got used to using brackets yet. Since I work with a wide range of programmers, from "just graduated" to 35 years on the job, if we're going to move our teams over to using D in the future (and I'd like us to) I'm looking for a language that is suitable for all 
>  programmers. As an aside though, like you say, we are all human. When it's late and you're tired and haven't eaten and the deadlines looming and you also know your family is wanting you home etc. etc. it's very easy to add a line of debug and forget to add the braces. It's not so much about the kind of mistake - sure it's fairly rare - but given the ease of fixing it -why not?
> 
> I can appreciate the "vertical real estate" argument, but in that case
> how about:
> 
>    if (cond) {
>       blah; }
> 
> Or even:
> 
>    if (cond) { blah; }
> 
> I hear Bruno's point about auto indent, and the lint ideas, compiler warning flags etc. but surely the whole spirit of D is to include this stuff _in_the_language_ otherwise people end up not using it.
> 
> Cheers
> 
> Munch
November 18, 2005
In article <dlkpot$1bc3$1@digitaldaemon.com>, clayasaurus says...
>
> From the 'What is D' page: "It doesn't come with a VM, a religion, or
>an overriding philosophy. It's a practical language for practical programmers who need to get the job done quickly, reliably, and leave behind maintainable, easy to understand code."
>
>It appears forcing to use {} is dangerously close to having a 'religion' or 'overriding philosophy,' and yet if it produces more maintainable code it might be worth it. I'm more on the ledge leaning away from it however, simply because I couldn't do my favorite 'debug writef' lines anymore.
>

This idea sounds tempting, but I myself actually find neatly organized and well indented code easier to maintain if the one-liner statement bodies are not {}'d for the simple reason that the code seems less 'busy' and more fits on a screen.

OTOH, there's a consistency argument for the required {} idea too - if {} are required to define one member classes, structs, unions, etc. and also one statement functions, why should anything else with a different scope (like conditional statement bodies) be different?

>Munch wrote:
>> OK so here is my other suggestion. It's very simple to implement from a compiler perspective - it adds robustness - it just needs a slight rearangement of the sytnax. I found a thread on it in the archives here: http://www.digitalmars.com/d/archives/1418.html
>> 
>> Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
>> 
>> while (i < 9)
>> i++; j++;
>> 
>> or this
>> 
>> if (cond)
>> <debug statement added to find bug>;
>> <line of code intended to be conditional>;
>> 
>> or more generally
>> 
>> if (cond)
>> <added code here>;
>> <ORIGINAL conditional line of code>; <and/or more added code>;
>> <and/or more added code>;
>> 
>> This is one of those things that when you start out coding you kid yourself that you save time by skipping out the braces. As the years roll by you gradually come across bugs that are harder and harder to find, that had part of their cause in missing curlys. Sooner or later you learn to use braces everywhere. I occasionally do code reviews and whenever I've come across code which doesn't have curlys everywhere, I know I'm likely to find a bug somewhere in the code. This is easy to fix in the language syntax, thus:
>> 
>> IfStatement:
>> if ( Expression ) BlockStatement
>> if ( Expression ) BlockStatement else BlockStatement
>> if ( Expression ) BlockStatement else IfStatement
>> 
>> Not enough motivation yet? Finally, this also kills one of the most insidious bugs in C/C++/Java:
>> 
>> if (cond);
>> <code intended to be conditional>
>> 
>> I've only done this a few times in my programming life, mainly in the first few years, but boy did some of those bugs take a long time to find. Note that this one can't be fixed by voluntarily entering braces yourself:
>> 
>> if (cond);
>> {
>> <code intended to be conditional>
>> }
>> 
>> The above syntax however, makes this a compile time error =)
>> 
>> (Obviously the above also applies to "for", "while" etc. )
>> 
>> Regards
>> 
>> Munch
>> 
>> 


November 18, 2005
> Its a fundamental issue that has nothing actually to do with coding. Some people
> wish to force a style upon another group of people 'for their own good'

sorry i don't want to force - just push a little bit :-)

> All I can say is I am delighted that Walter is the one making these kinds of
> decisions :D

your right - walter will make the best possible decision (i hope)


ciao dennis
November 18, 2005
Munch wrote:
> OK so here is my other suggestion. It's very simple to implement from a compiler
> perspective - it adds robustness - it just needs a slight rearangement of the
> sytnax. I found a thread on it in the archives here:
> http://www.digitalmars.com/d/archives/1418.html
> 
> Why not get rid of the looks-like-it's-nested-when-it-isn't bugs.

It would break code portability.  And is this really a problem for most people?  I don't think I've ever encountered this bug myself.


Sean
November 18, 2005
On Fri, 18 Nov 2005 09:53:12 -0500, clayasaurus wrote:

>  From the 'What is D' page: "It doesn't come with a VM, a religion, or
> an overriding philosophy. It's a practical language for practical
> programmers who need to get the job done quickly, reliably, and leave
> behind maintainable, easy to understand code."
> 
> It appears forcing to use {} is dangerously close to having a 'religion' or 'overriding philosophy,' and yet if it produces more maintainable code it might be worth it. I'm more on the ledge leaning away from it however, simply because I couldn't do my favorite 'debug writef' lines anymore.

That is why I'm saying allow the coder to omit braces but if they do so, they also have to tell the compiler that they choosing to do so. This also acts as a warning sign to future maintainers.

-- 
Derek Parnell
Melbourne, Australia
19/11/2005 8:38:39 AM
November 18, 2005
In article <dlkmou$1882$1@digitaldaemon.com>, JT says...

>Sorry I didnt mean to be rude or anything, and I can understand why some people would find this usefull. I simply cannot understand wanting to impose this on everyone, because, to me, its actually a style issue more than anything....

Don't worry, no offense taken =) I can understand that you can't understand it, but that doesn't mean it's not a good idea of course, it probably just means we have different experience of coding.

I guess a lot of this comes down to the kind of software you write. I'm used to working in teams - each new project I work on I'll be working with at least some people who I've never worked with before. Some projects, I'm so removed from the coding team that I hardly actually get to see the source code, othertimes I'm in there coding with everybody else. It makes a big difference if a language has something built in - which is one of the reasons I'm so keen on D. Loads of the good stuff I try to encourage - fully fledged use of contracts (never managed it), basic asserts, unit tests automatically run as part of the build process (just managed it for the first time on my current project) etc. is part of the language in D. The bracketing issue is another such thing.

I can understand that if for example somebody spends most of their time working on code that they've written themselves, this kind of thing won't bother them too much. Working on large code bases and/or in teams you come across a huge variety of bugs - the worst ones always have multiple causes. Any cause that we can rule out as part of the language has got to be a good thing.

To take a meta view on this problem, what you have here are two groups of people: one whose experience identifies a problem that can easily be fixed, another whose experience hasn't found this to be a problem.

The population of D users is made up of these two groups. The population can also be split into people who think that the overhead of having to use braces is a bad thing and those who don't.

What we need to weigh up is how much the population as a whole would be affected 1. by lack of brace enforcement and 2. by brace enforcement.

In my experience (which I'll admit is not the same as everybody elses), people who wish to have the option of no braces are never that bothered about giving up that option once they start doing it, but extra bugs bother everybody.

To summarise my argument:
- One of D's main strands is robustness (great - gets my vote)
- One of D's main principals is including features in the core language (great -
gets my vote)
- Another of D's main principals is to keep the compiler in mind (great - gets
my vote)
- This suggestion fits in with all three of these goals, and doesn't conflict
with any of D's aims.
- Some people can see the benefit of this, others not, but just because you
personally have no experience of this being a problem, doesn't mean it isn't.
- We need the language to be the best fit for the population as a whole, not any
particular subgroup. Assuming the target population is identified by the
language aims/goals as expressed above then it is logical to include this
change.

I will try not to add any more to this - these arguments do tend to ramble on! It would be nice if somebody neutral could summarise the two sides of the argument as I have probably been biased by my own experience. Perhaps the anti-brace-enforcement guys could summarise their position and we coudl cut and paste the two summaries? I was thinking it's worth putting this in the Wiki: (http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion) to avoid the same ground being covered over and over.

Cheers

Munch


1 2 3 4 5
Top | Discussion index | About this forum | D home