On Friday, March 09, 2012 09:39:23 deadalnix wrote:
> Le 07/03/2012 04:46, Nick Sabalausky a écrit :
> > "Adam D. Ruppe"<destructionator@gmail.com>  wrote in message news:bwqkuqhyiygvgqswicvz@forum.dlang.org...
> > 
> >> On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis wrote:
> >>> I don't understand this complaint at all. curr is an incredibly common abbreviation for current.
> >> 
> >> Is it your *first* choice?
> > 
> > In the general case, it frequently is for me. In the specific case of
> > Clock.curr(ent)?Time, I'm equally happy either way. Although I agree with
> > whoever it was (Brad?) that said "Clock.now()" would be even better.
> 
> The usage of current is often a smell that is saying « I had no clue how to name that, so I did name it using current ».
> 
> Meaningful name are what we should look for. And now is meaningful.

It's no more meaniful than currTime. It's just another name for the same thing.

- Jonathan M Davis

On Friday, March 09, 2012 09:33:20 deadalnix wrote:
> Le 07/03/2012 02:00, F i L a écrit :
> > I personally find it much easier to remember and use longer, more sentance-like method names. However, Jonathan and others obviously feel more comfortable writing with a high level of abbreviation, which they justify rather well. Still, if D's goal is to gain popularity, I think it should take notices of other rising languages like C#.
> > 
> > The problem with making any change to Phobos is backwards compatibility.
> 
> We just need a politic for the change. IE: make the old name a warning, then deprecated, then remove it. Spread the process to a year or so.

We're not changing symbol names without a good reason. Yes, there's a deprecation process that allows us to change them if we need to, but it's still disruptive.

- Jonathan M Davis

Le 09/03/2012 05:42, H. S. Teoh a écrit :
> On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
>> On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
>>> IMO, making all abbreviations in Phobos consistent would be a big
>>> step forward.
>>
>> You know, people keep saying that the abbreviations are inconsistent,
>> but I don't buy that. _What_ abbreviations are inconsistent?
> [...]
>
> My comment was referring specifically to the pull request that adds
> "secs" as an alternative for "seconds". From what Walter said, he seems
> to be against any renaming changes, so any existing inconsistencies that
> we might find seems likely to be rejected as well.

Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common.

On 09/03/12 05:54, H. S. Teoh wrote:
> On Thu, Mar 08, 2012 at 07:07:04PM -0500, Nick Sabalausky wrote:
> [...]
>> Heh one of us should hack up DMD to produce a NihonD, using (or at
>> least allowing) kanji instead of the kanas wherever appropriate :)
>> That'd be both fun to make and to use.
> [...]
>
> On another note, I've always dreamt about a language where keywords are
> i18n'd. Every keyword has an equivalent in every language (well, up to
> the languages currently supported, of course), and can be used
> interchangeably.
>
> Support for Arabic and Hebrew would be tricky because of the
> right-to-left thing, but cool if it can be pulled off. Even cooler would
> be to support top-to-bottom, right-to-left for traditional Chinese
> writing. Don't know how it would interoperate with code written in
> English, though. :-P (Though it would mainly be a display issue, since
> at the Unicode level everything is just an unambiguous sequence of
> characters.)
>
>
> T

Ugh. VBA does that. It's just horrid. I used to write the VBA code on my laptop, in English. But I could only test it on a German PC. If I found a small bug, I'd fix it on the test system. Problem is, when you look at the code, the keywords and built-in functions have all changed.

Trying to guess which German word the keyword changes to is a nightmare, especially when there are abbreviations. Eg, AVG() <--> MITTELWERT().

On Friday, March 09, 2012 09:55:50 deadalnix wrote:
> Le 09/03/2012 05:42, H. S. Teoh a écrit :
> > On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
> >> On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
> >>> IMO, making all abbreviations in Phobos consistent would be a big step forward.
> >> 
> >> You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent?
> > 
> > [...]
> > 
> > My comment was referring specifically to the pull request that adds "secs" as an alternative for "seconds". From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well.
> 
> Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common.

Because it creates needless aliases. Now you have to remember _both_ of them, because they're both going to be used in code. And people reading code will wonder what the difference is. It just adds more confusion to the library and reduces its cohesiveness and consistency. It works far better to just have the one symbol. Isn't that one of the major complaints about PHP? That it has a ton of different ways to do the same thing?

Walter and Andrei are very much against having aliases in the library just to create different names for the same stuff. And adding more options for the time units argument to the templates that use them is basically the same thing. So, we're not going to add such aliases. It's not like it's all that hard to learn the library, and none of the names are horribly wrong. They just don't happen to be the names that you prefer. You have to learn the names of the symbols of _any_ library that you use. This is no different.

- Jonathan M Davis

On Friday, March 09, 2012 01:07:57 Jonathan M Davis wrote:
> On Friday, March 09, 2012 09:55:50 deadalnix wrote:
> > Le 09/03/2012 05:42, H. S. Teoh a écrit :
> > > On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
> > >> On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
> > >>> IMO, making all abbreviations in Phobos consistent would be a big step forward.
> > >> 
> > >> You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent?
> > > 
> > > [...]
> > > 
> > > My comment was referring specifically to the pull request that adds "secs" as an alternative for "seconds". From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well.
> > 
> > Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common.
> 
> Because it creates needless aliases. Now you have to remember _both_ of them, because they're both going to be used in code. And people reading code will wonder what the difference is. It just adds more confusion to the library and reduces its cohesiveness and consistency. It works far better to just have the one symbol. Isn't that one of the major complaints about PHP? That it has a ton of different ways to do the same thing?
> 
> Walter and Andrei are very much against having aliases in the library just to create different names for the same stuff. And adding more options for the time units argument to the templates that use them is basically the same thing. So, we're not going to add such aliases. It's not like it's all that hard to learn the library, and none of the names are horribly wrong. They just don't happen to be the names that you prefer. You have to learn the names of the symbols of _any_ library that you use. This is no different.

If you want to read Walter's arguments on the matter as well as more detailed discussion on this particular case, then just read the comments in the now closed pull requested for adding "secs":

https://github.com/D-Programming-Language/druntime/pull/173

- Jonathan M Davis

Le 09/03/2012 10:07, Jonathan M Davis a écrit :
> On Friday, March 09, 2012 09:55:50 deadalnix wrote:
>> Le 09/03/2012 05:42, H. S. Teoh a écrit :
>>> On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
>>>> On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
>>>>> IMO, making all abbreviations in Phobos consistent would be a big
>>>>> step forward.
>>>>
>>>> You know, people keep saying that the abbreviations are inconsistent,
>>>> but I don't buy that. _What_ abbreviations are inconsistent?
>>>
>>> [...]
>>>
>>> My comment was referring specifically to the pull request that adds
>>> "secs" as an alternative for "seconds". From what Walter said, he seems
>>> to be against any renaming changes, so any existing inconsistencies that
>>> we might find seems likely to be rejected as well.
>>
>> Why it isn't possible to support both ? And miliseconds as well a usecs
>> ? This make sense, as long as they are both common.
>
> Because it creates needless aliases. Now you have to remember _both_ of them,
> because they're both going to be used in code. And people reading code will
> wonder what the difference is. It just adds more confusion to the library and
> reduces its cohesiveness and consistency. It works far better to just have the
> one symbol. Isn't that one of the major complaints about PHP? That it has a
> ton of different ways to do the same thing?
>
> Walter and Andrei are very much against having aliases in the library just to
> create different names for the same stuff. And adding more options for the time
> units argument to the templates that use them is basically the same thing. So,
> we're not going to add such aliases. It's not like it's all that hard to learn
> the library, and none of the names are horribly wrong. They just don't happen
> to be the names that you prefer. You have to learn the names of the symbols of
> _any_ library that you use. This is no different.
>
> - Jonathan M Davis

This is not alias. This is about accepting template parameters. The actual isn't very consistent anyway (seconds, but usecs ?).

On 08/03/2012 21:08, Matt Soucy wrote:

> "American" does have the benefit of being more pronounceable, though...I
> just tried to pronounce that "oohz-ee-an", "us-ee-an", etc and they all
> sound odd.
>

I say it as "Yu-Essian", it gets a lot of funny looks even after I have explained ^^

A...

On 09/03/2012 00:07, Nick Sabalausky wrote:

> But yea, it would be interesting to see a langauge that was based on
> something very different. A German-based one would be fun. Or even better,
> something that doesn't use the Latin alphabet, like Japanese or Hebrew or
> Russian. Or Swahili (which is an awesome-sounding language). Designing/using
> an Arabic (right-to-left, IIRC) programming language would be a great
> mind-fuck. Heh one of us should hack up DMD to produce a NihonD, using (or
> at least allowing) kanji instead of the kanas wherever appropriate :) That'd
> be both fun to make and to use.
>

I recall, but have no idea where to start looking for it, reading an article about why English is the only language that works for programming. I think the jist was that its archaic rules allowed any syntax needed to be shoe-horned into place. After all, "grammatical, everything Yoda says, is." Or perhaps it is a relic of lost colonialism that English is good for listing instructions.

Having said that, I'd love to see a programming language that was based on Welsh/Gaelic/Irish/Cornish/Occitan/Catalan, they make for beautiful sounding poetry (no idea what they mean though) and I have a theory that poetic languages would be good for programming in.

Also I think I remember there being a Greek version of C, but it never took off even in Greece.

A...

On Friday, March 09, 2012 10:28:12 deadalnix wrote:
> Le 09/03/2012 10:07, Jonathan M Davis a écrit :
> > On Friday, March 09, 2012 09:55:50 deadalnix wrote:
> >> Le 09/03/2012 05:42, H. S. Teoh a écrit :
> >>> On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
> >>>> On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
> >>>>> IMO, making all abbreviations in Phobos consistent would be a big step forward.
> >>>> 
> >>>> You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent?
> >>> 
> >>> [...]
> >>> 
> >>> My comment was referring specifically to the pull request that adds "secs" as an alternative for "seconds". From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well.
> >> 
> >> Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common.
> > 
> > Because it creates needless aliases. Now you have to remember _both_ of them, because they're both going to be used in code. And people reading code will wonder what the difference is. It just adds more confusion to the library and reduces its cohesiveness and consistency. It works far better to just have the one symbol. Isn't that one of the major complaints about PHP? That it has a ton of different ways to do the same thing?
> > 
> > Walter and Andrei are very much against having aliases in the library just to create different names for the same stuff. And adding more options for the time units argument to the templates that use them is basically the same thing. So, we're not going to add such aliases. It's not like it's all that hard to learn the library, and none of the names are horribly wrong. They just don't happen to be the names that you prefer. You have to learn the names of the symbols of _any_ library that you use. This is no different.
> > 
> > - Jonathan M Davis
> 
> This is not alias. This is about accepting template parameters. The actual isn't very consistent anyway (seconds, but usecs ?).

It amounts to the same thing, and core.time and std.datetime are as consistent as they're going to get. seconds are _always_ seconds, and _no_ units greater than seconds are ever abbreviated. Only the sub-second units are abbreviated. And they're abbreviated only because they would have been way too long otherwise. And making seconds secs would create even _more_ inconsistencies. Just read the discusion in the pull request:

https://github.com/D-Programming-Language/druntime/pull/173

- Jonathan M Davis