View mode: basic / threaded / horizontal-split · Log in · Help
March 11, 2012
Re: Breaking backwards compatiblity
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
Re: Breaking backwards compatiblity
"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
Re: Breaking backwards compatiblity
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
Re: Breaking backwards compatiblity
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
Re: Breaking backwards compatiblity
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
Re: Breaking backwards compatiblity
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
Re: Breaking backwards compatiblity
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
Re: Breaking backwards compatiblity
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
Re: Breaking backwards compatiblity
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
Re: Breaking backwards compatiblity
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.
13 14 15 16 17 18 19 20
Top | Discussion index | About this forum | D home