March 11, 2012
On 3/11/2012 8:34 AM, deadalnix wrote:
> I do think better name isn't the problem. The problem is about consistency, and
> will persist as long as we don't agree on a guideline on that in phobos.
>
> Changing a name just for changing it doesn't worth the cost, unless the original
> name is horribly misleading - rare case. But getting the naming convention
> consistent is of much greater importance, and justify breaking code.

Frankly, I think naming conventions are overrated. The problem is that, as the sec vs seconds debate shows, there is not a correct answer. It becomes a bikeshed issue. There are a lot of considerations for a name, usually conflicting with each other. To set rules in concrete and follow them no matter what is a formula for silly results.

I'm not suggesting no naming convention. Naming conventions are good. But they don't trump everything else in importance, not even close.

And sometimes, a name change can be a huge win - the invariant=>immutable one is an example. But I think that's an exceptional case, not a rule.
March 11, 2012
"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jjj0je$2bse$2@digitalmars.com...
> On 3/11/2012 4:20 AM, Matej Nanut wrote:
>> I've been using an EeePC for everything for the past 2.5 years and until now, I could cope.
>
> You're right that there's a downside to providing your developers the hottest machines available - their code tends to be a dog on the machines your customer has.
>
> I have an EeePC, but I find I could not cope with the tiny screen and tiny keyboard :-)

I've often found the keys on a normal sized keyboard to be a bit small. (I have somewhat large hands - I think the original XBox1 "Duke" controller is the only good-sized game controller.) I spent some time trying to find a keyboard with slightly larger than normal keys, but couldn't come up with anything. OTOH, I may have just been being sloppy with my keypresses: I'm not hitting multiple keys anymore like I had been for awhile.


March 11, 2012
On Sunday, March 11, 2012 13:16:44 Walter Bright wrote:
> On 3/11/2012 8:34 AM, deadalnix wrote:
> > I do think better name isn't the problem. The problem is about consistency, and will persist as long as we don't agree on a guideline on that in phobos.
> > 
> > Changing a name just for changing it doesn't worth the cost, unless the original name is horribly misleading - rare case. But getting the naming convention consistent is of much greater importance, and justify breaking code.
> Frankly, I think naming conventions are overrated. The problem is that, as the sec vs seconds debate shows, there is not a correct answer. It becomes a bikeshed issue. There are a lot of considerations for a name, usually conflicting with each other. To set rules in concrete and follow them no matter what is a formula for silly results.
> 
> I'm not suggesting no naming convention. Naming conventions are good. But they don't trump everything else in importance, not even close.
> 
> And sometimes, a name change can be a huge win - the invariant=>immutable one is an example. But I think that's an exceptional case, not a rule.

Another issue is the question of what you consider consitency to be. On the whole, I really don't see much inconsistent about Phobos' naming at this point. The main problem that it's had is that it hasn't always used camelcasing historically, and a number of functions weren't camelcased like the rest and like we'd decide we wanted our function names and enum values to generally be. That's mostly been fixed. And yet there are still some people complaining about consistency. And to boot, other than the issue of secs vs seconds, I don't know what they even think is inconsistent.

Some very basic conventions (such as the normal casing rules for various types of symbols) are certainly helpful, but you _are_ going to have corner cases, and if we tried to have strict and complicated rules on naming, it would just be frustrating all around. Not to mention, there's always _someone_ who comes up with a reason why they think that a particular name is bad or doesn't fit with the rest.

So, I think that Phobos is mostly consistent with its naming at this point, and aside from some people not liking the name of a function or two, I really don't see what there is to complain about.

- Jonathan M Davis
March 11, 2012
Walter:

> And sometimes, a name change can be a huge win - the invariant=>immutable one is an example. But I think that's an exceptional case, not a rule.

I was among the ones that have asked for that name change. But "immutable" is a quite long word. Now I think the "val" used by Scala is better, it uses less space for something I use often enough. "imm" is another option, but it looks less nice :-)

Bye,
bearophile
March 11, 2012
On Friday, 9 March 2012 at 22:41:22 UTC, Timon Gehr wrote:
> Most bug fixes are breaking changes. I don't think we are there yet.

In my opinion, this is a very interesting and important observation – due to the powerful meta-programming and reflection capabilities, most of the time the question is not whether a change is backward compatibile or not, but rather how _likely_ it is to break code. There isn't really a good way to avoid that, even more so if your language allow testing whether a given piece of code compiles or not.

A related problem is that we still don't quite have an appropriate language spec, so you can never be sure if you code is really »correct« or if you are relying on DMD implementation details – I'm sure everybody who had their meta-programming heavy code break due to a seemingly unrelated DMD bugfix knows what I'm trying to say…

David
March 11, 2012
On 3/11/2012 2:51 PM, bearophile wrote:
>> And sometimes, a name change can be a huge win - the invariant=>immutable
>> one is an example. But I think that's an exceptional case, not a rule.
>
> I was among the ones that have asked for that name change. But "immutable" is
> a quite long word. Now I think the "val" used by Scala is better, it uses
> less space for something I use often enough. "imm" is another option, but it
> looks less nice :-)

The reason we went with "immutable" is for any other name, I'd be constantly explaining:

    "xyzzy" means immutable

And I did just that for "invariant". Over and over and over. People immediately get what "immutable" means, like for no other name. So consider "immutable" a labor saving device for me.
March 11, 2012
Le 11/03/2012 21:16, Walter Bright a écrit :
> On 3/11/2012 8:34 AM, deadalnix wrote:
>> I do think better name isn't the problem. The problem is about
>> consistency, and
>> will persist as long as we don't agree on a guideline on that in phobos.
>>
>> Changing a name just for changing it doesn't worth the cost, unless
>> the original
>> name is horribly misleading - rare case. But getting the naming
>> convention
>> consistent is of much greater importance, and justify breaking code.
>
> Frankly, I think naming conventions are overrated. The problem is that,
> as the sec vs seconds debate shows, there is not a correct answer. It
> becomes a bikeshed issue. There are a lot of considerations for a name,
> usually conflicting with each other. To set rules in concrete and follow
> them no matter what is a formula for silly results.
>

I think this example is very good. The seconds/secs show us the importance of getting consistent. Here the problem come from the fact that some stuff has been abbreviated (msecs, usecs, . . .) and some other hasn't (minutes, hours). Now we ends up with the tricky case of seconds, because it is in between theses 2 worlds and 2 naming conventions. And as we have seen, it confuses people, and have no good solution now (either duplication of the value, which is never good, either arbitrary choice of one naming convention).

This typically show us what problems bad naming convention occurs, and how difficult it is solve afterward, because it breaks compatibility.

> I'm not suggesting no naming convention. Naming conventions are good.
> But they don't trump everything else in importance, not even close.
>

I have to disagree. They are really important on a large codebase (let say > 100,000 lines of code). Otherwise people tend not to find modules they can reuse expect by nowing the whole codebase. This have indirect effect to cause needless duplication - with all known drawbacks - and make the project more dependent on documentation - more documentation have to be produced, which means an overhead in workload and more trouble when documentation lacks, is outdated, or is bugguy.

> And sometimes, a name change can be a huge win - the
> invariant=>immutable one is an example. But I think that's an
> exceptional case, not a rule.

IMO, the name in itself isn't that important. The important thing is that thing get named in a predictable and simple way.
March 11, 2012
Le 11/03/2012 23:12, Walter Bright a écrit :
> On 3/11/2012 2:51 PM, bearophile wrote:
>>> And sometimes, a name change can be a huge win - the
>>> invariant=>immutable
>>> one is an example. But I think that's an exceptional case, not a rule.
>>
>> I was among the ones that have asked for that name change. But
>> "immutable" is
>> a quite long word. Now I think the "val" used by Scala is better, it uses
>> less space for something I use often enough. "imm" is another option,
>> but it
>> looks less nice :-)
>
> The reason we went with "immutable" is for any other name, I'd be
> constantly explaining:
>
> "xyzzy" means immutable
>
> And I did just that for "invariant". Over and over and over. People
> immediately get what "immutable" means, like for no other name. So
> consider "immutable" a labor saving device for me.

We have the same phenomena with dur and return type type qualifier (ie: why does const int* fun() isn't compiling ? Because const is qualifying the function, not the return type).

Both are recurring questions and so should be as important as immutable. But both are major breaking change.
March 11, 2012
Le 11/03/2012 21:07, Walter Bright a écrit :
> On 3/11/2012 12:32 PM, Nick Sabalausky wrote:
>> I'm convinced that colleges in general produce very bad programmers. The
>> good programmers who have degrees, for the most part (I'm sure there are
>> rare exceptions), are the ones who learned on their own, not in a
>> classroom.
>
> Often the best programmers seem to have physics degrees!
>

I saw you coming ^^.
March 11, 2012
Le 11/03/2012 21:06, Walter Bright a écrit :
> On 3/11/2012 4:20 AM, Matej Nanut wrote:
>> I've been using an EeePC for everything for the past 2.5 years and
>> until now, I could cope.
>
> You're right that there's a downside to providing your developers the
> hottest machines available - their code tends to be a dog on the
> machines your customer has.
>

I think a better solution is including expected performances in the user stories and add them in the testing suite. Dev can enjoy a powerful machine without risking to get a resource monster as a final executable.