View mode: basic / threaded / horizontal-split · Log in · Help
November 19, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
>>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?
>

I had to write some Perl code today after a while away from it, and I take that
last paragraph back <g> Made for a long Friday!

I do like Perl's

<statement> if(<condition>);

syntax somewhat, but can't say I care for it enough to add it to D.

- Dave
November 19, 2005
Sorry [was: Re: tightening up if statments[was: Re: D - Looks great!]
In article <dlm6a3$2hd0$1@digitaldaemon.com>, J C Calvarese says...
>
>In article <dllt4i$2akj$1@digitaldaemon.com>, Munchgreeble says...
>>I think some people get defensive because they are insecure about their own
>>ability as a coder, and feel they can't admit that something like
>>consistently-using-braces will help them. Of course some people are genuinely
>>brilliant coders, never make any mistakes even when tired and under pressure.
>>Hopefully such people might have keen enough perception to see that we're not
>>all like that and perhaps be gracious enough to allow the rest of us mortals the
>>benefit of the help that they don't need?
>
>How long have you been reading this newsgroup? Have you been lurking at all or
>have you actually just arrived?
>
>I'm just suggesting that it's good to listen as well as speak. You've been doing
>quite a bit of speaking. You might want to spend some time getting to know the
>group dynamic -- before you manage to offend everyone. ;)
>
>I'm not a professional programmer, but I write some code. And I can't remember
>ever getting an error by leaving off braces on what I meant to be a block if
>statement. I'm not saying it never happened. I've probably been stung by this,
>too. I just remember other problems I've had a lot more clearly (such as
>forgetting to put breaks in my switch cases). But I really doubt Walter would
>change something like this at this point -- especially if it's going to require
>him to add brackets all over Phobos sources. And Walter's the one who has to be
>sold on it.
>
>jcc7


OK thanks - good advice =) No I haven't been lurking - I'm just so excited by
this language I've kind of gone in with both feet a bit. I must admit that it
has annoyed me in the past when other people have done this on lists I've been
reading for ages, so I guess I owe you guys an apology: Sorry Everbody!

It's useful to know that this sort of stuff is unlikely to get changed at this
stage, so thanks for that =)

The above was really just me trying to reason through "out loud" why it is
people get so defensive when presented with guidlines or rules like this. It's
always a difficulty at work and seeing the same reaction here made me start to
consider the possibilities, because it often stops people thinking logically
without them realising it - I really didn't mean to offend anybody. I wasn't
intending to be sarcastic or anything, just trying to help. Again - apologies =)

OK so, what sort of stuff is decided already and what is changeable?

Cheers

Munch
November 19, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
In article <dlluaa$2bev$1@digitaldaemon.com>, Kris says...
>
>
>"Munchgreeble" <Munchgreeble_member@pathlink.com> wrote in message
>
>> Oh my goodness it's 1 o'clock again.
>>
>> How does this group suck the time away like that?
>
>Because it's so much warmer near the computer!
>
>Guessing you're somewhere near Scotland/Ireland/Wales/England ~ it's /cold/ 
>there at this time of year. 

Yes UK =) And you're right it is cooold here this morning. I can't see the
garden out of the window because the window is covered in ice.
November 19, 2005
Re: Sorry [was: Re: tightening up if statments[was: Re: D - Looks great!]
In article <dlmpq4$2uri$1@digitaldaemon.com>, Munchgreeble says...

.. (snip) ...

>OK so, what sort of stuff is decided already and what is changeable?
>
>Cheers
>
>Munch

Since Walter is the dictator (he's a friendly and smart dictator, though), he's
the only one who can answer that. I think he's written things like he doesn't
expect any major changes at this point, but ultimately he's the one who decides
what's a major change and what's a minor change. And it's conceivable that if
someone makes a convincing argument that there's a show-stopper, he might be
persuaded to revisit a fundamental decision. 

I think he's busy fixing bugs right now, and that's the only changes that I
expect at this point. But he seems to welcome discussions about any idea that
might improve D. Even is he's not replying that doesn't mean he's not reading
them. Also, he has a habit of replying 2 months later to a discussion that had
long since died out. Often, it's just a "You're right" to someone that had
already guessed the answer to the question.

jcc7
November 19, 2005
Re: tightening up if statments[was: Re: D - Looks great! Open to
Codebases I've worked on have ranged in size, but generally been fairly 
large, and have involved more programmers than just myself and one or 
two other people.

I'm sorry if you've had negative experiences with this, but quite 
frankly, if I ever met anyone who consistently (or even more than once) 
had a problem with something so simple, whether they were a doctor, 
programmer, or even a waiter... I wouldn't expect them to hold their job 
long.

In my view, whatever excuses you want to make (drunk, whatever) if you 
are working on the job, and you cannot put something in the right place 
for the compiler (which is the whole point of 80% of programming 
constructs) you don't know what you are doing.

It is very similar in my mind to a waiter or waitress dropping a tray. 
If someone needs to push around a cart (except in cirumstances like 
airplanes and trains) to avoid breaking plates and glasses... that does 
not mean all restaraunts should have carts installed.  That means that 
person needs to find another line of work.

You may think, everything would just be better if carts were used in 
restaraunts.  Everything would be better if cars had a builtin limit 
such that they could not go faster than 75 miles per hour.  This makes 
mistakes impossible, and these are such simple changes!

Well, I of course disagree.  There are always going to be possible 
mistakes you can make.  When I was much younger and first started 
programming, I made tons of mistakes.  I programmed a lot of Assembly 
and BASIC back then, and you can imagine how many times my computer 
crashed.  I'm not perfect, nor am I expecting anyone to be.

But I learned.  I still make mistakes, but I don't make the same 
elementary ones now.  That's what you're supposed to do.  Learn.  I 
know, I know, programmers seem to want to run from that word more and 
more these days.  Go to college, and you pop out an expert, just like 
that.  Unlike every other freaking profession in the world, including 
even driving a car.  Yeah, right.

There are common mistakes, and there are common mistakes.  I would 
really have to argue that this mistake you are talking about is just so 
elementary, that it will only hit those programmers who NEED to be hit. 
 It was stupid mistakes like this one that hit me when I was younger 
and taught me to understand program flow.  I didn't make mistakes like 
these because I was tired, I made them because I was stupid.  I am no 
longer as stupid.

You may choose to put those programmers you manage in small plastic 
boxes with soft plastic gloves, but in the end that will just have the 
effect of making them remain in that exact state.  They'll never learn, 
they'll never grow.  No, people need to make mistakes... it's just how 
it works.

And, yes, there will always be that person who makes the mistake 
consistently, but is good at what they do otherwise.  There are waiters 
and waitresses who break plates, but are amazing otherwise.  Doctors who 
need to be reminded to wash their hands, but can save more lives than 
Superman.  For these people, yes, an option might be nice.  But really, 
if such a person can't find a way to overcome their problem (by evasion 
or similar, I mean), they aren't so great after all.

I really wouldn't be nearly as interested in using D if it made such 
changes, and I'm totally serious when I say that.  I think D is a great 
and wonderful language, with lots of benefits over others, but if it 
goes the route of thick, soft, plastic gloves... well, I'll have to wait 
for another that actually takes the right route, or make my own.

-[Unknown]


> 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
> 
>
November 19, 2005
Re: D - Looks great! Open to changes still?
On 11/17/2005 04:58 PM, clayasaurus wrote:
> If you have a suggestion to make the language better, don't be afraid to 
> say it. As of yet D is still a work in progress.
> 

I'd like to suggest that, by default, class types are created on stack, 
just like struct types, instead of in heap, since heap creation is much 
slower, IIUC.  However, I suspect I'm unaware of some reason why it
was done this way.  Any references justifying this decision?


The above conclusion about class creation in heap is based on:

   Class objects are instantiated by reference only.

from:

   http://www.digitalmars.com/d/class.html

and also on:

   To have a class allocated on the stack that has a destructor, this
   is the same as a declaration with the auto attribute.

from:

   http://www.digitalmars.com/d/memory.html#stackclass

although the last quote is hard to understand.  Should it be:

   To have a class with a destructor allocated on the stack, add the
   auto attribute to the class declaration.  IOW, a class, Foo, is
   declared an auto class as follows:

     auto class Foo{...}

   as explained in

      http://www.digitalmars.com/d/class.html#auto

   ?
November 19, 2005
OT Re: tightening up if statments[was: Re: D - Looks great! Open to
Hi There =)

OK, thanks for your point of view. It's always good to have the benefit of other
people's experience. I guess this is kind of academic now, (i.e. I'm not
expecting the brace thing to get changed), but I wanted to address a couple of
points:

1. I take your illustration on board, but D will presumably not just be used by
professional programmers. There will be plenty of school kids, hobbyists etc.
who pick the language up, maybe to try and help out on an open source project or
something. I agree about the need to put time into learning, but I would hope
that the language could be as helpful as possible in preventing new coders (or
old ones for that matter) falling into pitfalls.
2. I may have communicated my point poorly. I've never come across anybody who
consistently makes this coding mistake. Like a lot of trivial coding errors, you
make it once - go "d'oh" - then never conciously make the mistake again. If it
happens in future it happens by accident, but it still happens. Most people make
a wide variety of accidental errors with varying levels of frequency. E.g.
adding a semi-colon at the end of an if statement (which D now outlaws -hoorah)
is fairly rare, but most people have done it on occasion. Similarly with missing
out braces when you need them. It's just a statistical thing - it's about
reducing the probability of bugs occuring, and increasing the probability of
finding bugs when they do occur.

I really like your speed limiting example because it's exactly the same
argument. Here in the UK, all haulage is speed limited by law, there has been
massive pressure to get trains speed limited and that's now going ahead, there
have also been discussions of speed limiting all road vehicles. Similarly
wearing of seatbelts is requred by law. Thinking outside of road transport,
things like firearms are illegal. This is just because applying these rules
reduces the number of deaths. The rules are midly inconvenient and even
infuriate some. They may even *cause* deaths in some cases. But with them in
place the _total_ number of deaths is lower.

I have never understood the desire to have your own way, at the expense of
others, but I guess it's just a cultural thing. However, I accept that
regardless of me not understanding why, some people really do want that freedom,
so I take your point =) I shall try to stay more aware of it in future.

Thanks

Munch

In article <dlnnct$nd3$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>Codebases I've worked on have ranged in size, but generally been fairly 
>large, and have involved more programmers than just myself and one or 
>two other people.
>
>I'm sorry if you've had negative experiences with this, but quite 
>frankly, if I ever met anyone who consistently (or even more than once) 
>had a problem with something so simple, whether they were a doctor, 
>programmer, or even a waiter... I wouldn't expect them to hold their job 
>long.
>
>In my view, whatever excuses you want to make (drunk, whatever) if you 
>are working on the job, and you cannot put something in the right place 
>for the compiler (which is the whole point of 80% of programming 
>constructs) you don't know what you are doing.
>
>It is very similar in my mind to a waiter or waitress dropping a tray. 
>If someone needs to push around a cart (except in cirumstances like 
>airplanes and trains) to avoid breaking plates and glasses... that does 
>not mean all restaraunts should have carts installed.  That means that 
>person needs to find another line of work.
>
>You may think, everything would just be better if carts were used in 
>restaraunts.  Everything would be better if cars had a builtin limit 
>such that they could not go faster than 75 miles per hour.  This makes 
>mistakes impossible, and these are such simple changes!
>
>Well, I of course disagree.  There are always going to be possible 
>mistakes you can make.  When I was much younger and first started 
>programming, I made tons of mistakes.  I programmed a lot of Assembly 
>and BASIC back then, and you can imagine how many times my computer 
>crashed.  I'm not perfect, nor am I expecting anyone to be.
>
>But I learned.  I still make mistakes, but I don't make the same 
>elementary ones now.  That's what you're supposed to do.  Learn.  I 
>know, I know, programmers seem to want to run from that word more and 
>more these days.  Go to college, and you pop out an expert, just like 
>that.  Unlike every other freaking profession in the world, including 
>even driving a car.  Yeah, right.
>
>There are common mistakes, and there are common mistakes.  I would 
>really have to argue that this mistake you are talking about is just so 
>elementary, that it will only hit those programmers who NEED to be hit. 
>  It was stupid mistakes like this one that hit me when I was younger 
>and taught me to understand program flow.  I didn't make mistakes like 
>these because I was tired, I made them because I was stupid.  I am no 
>longer as stupid.
>
>You may choose to put those programmers you manage in small plastic 
>boxes with soft plastic gloves, but in the end that will just have the 
>effect of making them remain in that exact state.  They'll never learn, 
>they'll never grow.  No, people need to make mistakes... it's just how 
>it works.
>
>And, yes, there will always be that person who makes the mistake 
>consistently, but is good at what they do otherwise.  There are waiters 
>and waitresses who break plates, but are amazing otherwise.  Doctors who 
>need to be reminded to wash their hands, but can save more lives than 
>Superman.  For these people, yes, an option might be nice.  But really, 
>if such a person can't find a way to overcome their problem (by evasion 
>or similar, I mean), they aren't so great after all.
>
>I really wouldn't be nearly as interested in using D if it made such 
>changes, and I'm totally serious when I say that.  I think D is a great 
>and wonderful language, with lots of benefits over others, but if it 
>goes the route of thick, soft, plastic gloves... well, I'll have to wait 
>for another that actually takes the right route, or make my own.
>
>-[Unknown]
>
>
>> 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
>> 
>>
Next ›   Last »
1 2 3 4 5
Top | Discussion index | About this forum | D home