November 19, 2005
>>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
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
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
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
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
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
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
>> 
>> 


1 2 3 4 5
Next ›   Last »