On 2012-03-07 23:55, Stewart Gordon wrote:
> On 06/03/2012 16:38, Adam D. Ruppe wrote:
>> One of the stumbling blocks on using std.datetime is how
>> many bizarre abbreviations it has.
>>
>> auto time = Clock.currentTime(); // bzzt, wrong
>>
>> if(time - something > duration!"hours"(4)) // bzzt, wrong
>>
>> writeln(time.toISOExtendedString()); // bzzt, wrong, but this used to
>> work!
> <snip>
>
> The mention of this one reminds me of another issue: capitalisation
> consistency. It would be nice to standardise whether
> acronyms/initialisms occurring within names have just the first letter
> or all letters capitalised. I'm thinking best is to treat them as words
> and therefore capitalise just the first letter. Though I've been known
> to do otherwise in the past.
>
> But it's confusing enough that there are still many functions in Phobos
> whose names are all lowercase when they should be camelCase.
>
> The Java API is in a mess in this respect:
> http://www.mindprod.com/jgloss/inconsistencies.html
>
> We'd have no trouble avoiding this if only Phobos was designed to be
> free of such inconsistencies from its beginning.
>
> Stewart.

I would go with strict camlecase. So if a identifier has an acronym in the middle of the name, I would only capitalize the first letter. If the identifier starts with an acronym, I would not capitalize any of the letters in the acronym.

auto isoExtendedString = time.toIsoExtendedString()

-- 
/Jacob Carlborg

On 2012-03-08 02:22, Stewart Gordon wrote:
> On 07/03/2012 08:10, Jacob Carlborg wrote:
> <snip>
>> Yeah, Clock.now() would be good and Data.today() as well.
>
> My utility library has, for consistency, DateValue.now, TimeValue.now
> and DateTime.now.
>
> Stewart.

Cool. Why the "Value" suffix?

-- 
/Jacob Carlborg

On 2012-03-08 03:14, Ary Manzana wrote:
> On 3/6/12 9:25 PM, Jonathan M Davis wrote:
>> On Tuesday, March 06, 2012 20:58:52 Ary Manzana wrote:
>>> On 3/6/12 8:43 PM, Jonathan M Davis wrote:
>>>> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
>>>>> writeln(time.toISOExtendedString()); // bzzt, wrong, but this
>>>>> used to work!
>>>>
>>>> Yes, and it was quickly changed to toISOExtString, because
>>>> toISOExtendedString is painfully long. toISOExtString is bad enough,
>>>> but
>>>> you can't really make it any shorter without making the name
>>>> uninformative.
>>>>
>>>>> Nope, apparently, I meant "dur". Ridiculous.
>>>>
>>>> A Duration needs to be constructed with a template, and
>>>> duration!"hours"(13), duration!"seconds"(44), etc. is painfully long
>>>> when
>>>> used in expressions. So, it was shortened to dur. I don't know of any
>>>> other abbreviation which would make sense.
>>>
>>> Painfully long?
>>>
>>> How much time does it take you to type 5 more chars? How much time does
>>> it take you to understand "dur" when you read it instead of "duration"?
>>>
>>>> I agree with H.S. Teoh in that abbreviations should be meaniful and
>>>> consistent but that they _should_ be used where applicable. Code
>>>> becomes
>>>> painfully long otherwise - especially when chaining function calls and
>>>> the like.
>>>
>>> Code becomes painfully long when you write lots of lines, not when you
>>> write long lines. Specially when you write lots of boilerplate lines.
>>
>> You don't write much code in functional style, do you?
>
> Here's something I wrote today:
>
> parent_ids = results.map{|x|
> x['_source']['parent_ids']}.flatten.uniq.compact
> Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
>
> Or I could have written:
>
> Hash[
> Site.find(
> results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
> ).map{|x| [x.id, x]}
> ]
>
> No abbreviation at all, many function calls, functional style in the
> middle (the couple of "map").
>
> In Ruby it's not such a big problem to have descriptive names.
>
> I guess in D it would be longer because of all the template invocation,
> the argument types, etc. I just guess it, I'm not sure.

With the new labmda syntax and the new UFCS it would be:

Site.find(
results.map!(x => x['_source']['parent_ids']).flatten.uniq.compact
).map!(x => [x.id, x]);

Don't know the corresponding D functions for "flatten" and "compact", you might not need them.

> If you chain functions
>> much, then long names very quickly result in long lines, which makes
>> the code
>> harder to read, and can quickly lead to expressions having to be multiple
>> lines, simply because the symbol names involved were overly verbose.
>>
>> While, I grant you that duration!"minutes"(5) might be more
>> immediately clear
>> than dur!"minutes"(5) is, I don't buy that it makes all that much of a
>> differences. You're not going to mistake dur for anything else even if it
>> doesn't immediately occur to you that it's an abbreviation for
>> duration, and
>> the units make it very clear that it's related to time. And since dur is
>> something that's likely to be commonly used, it will very quick and
>> easy to
>> remember what it is.
>
> The problem is not mistaking it with something else. The problem is when
> you want to write it. In Ruby my mind works like this:
>
> Mind: "How would I get a span for 5 seconds?"
> Mind: "Let's try 5.seconds"
> Mind: "Wow, it works!"
>
> I'm trying to remember cases when I just wrote what my mind thought it
> was correct and I was *so* surprised it worked out of the box in Ruby.
> Like writing array.last, and get it to work, instead of
> array[array.length - 1]. But in D, from the docs
> (http://dlang.org/arrays.html )
>
> bar[$-1] // retrieves last element of the array
>
> I read: bar dollar minus one wait what??
>
> Now, in D I try:
>
> 5.seconds
>
> and it doesn't work. I have to write this very unintuitive:
>
> dur!"minutes"(5)
>
> Was it really necessary to implement it that way?
>
> Again, the problem is not understanding the meaning, the problem is
> guessing what you have to write and get it right the first time.

I completely agree.

-- 
/Jacob Carlborg

On Thursday, 8 March 2012 at 13:36:56 UTC, Jacob Carlborg wrote:
> auto isoExtendedString = time.toIsoExtendedString()

That's my preference as well.

On 03/08/2012 12:55 PM, Steven Schveighoffer wrote:
> On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana <ary@esperanto.org.ar>
> wrote:
>
>> The problem is not mistaking it with something else. The problem is
>> when you want to write it. In Ruby my mind works like this:
>>
>> Mind: "How would I get a span for 5 seconds?"
>> Mind: "Let's try 5.seconds"
>> Mind: "Wow, it works!"
>>
>> I'm trying to remember cases when I just wrote what my mind thought it
>> was correct and I was *so* surprised it worked out of the box in Ruby.
>> Like writing array.last, and get it to work, instead of
>> array[array.length - 1]. But in D, from the docs
>> (http://dlang.org/arrays.html )
>>
>> bar[$-1] // retrieves last element of the array
>>
>> I read: bar dollar minus one wait what??
>
> array.back;
>
> http://dlang.org/phobos/std_array.html#back
>
> This is the issue with "intuition". It's easy to say, "hey I guessed
> right in Ruby! Ruby must be more intuitive!". But if you were someone
> who knew the range interfaces, wouldn't you try array.back in Ruby and
> say "well, obviously D is more intuitive, it knew what I wanted without
> even looking up the docs!"
>
> You are never going to come up with something that's *perfectly*
> intuitive for everyone in every situation.
>
>> Now, in D I try:
>>
>> 5.seconds
>>
>> and it doesn't work. I have to write this very unintuitive:
>>
>> dur!"minutes"(5)
>>
>> Was it really necessary to implement it that way?
>
> No, nothing is ever necessary to implement a certain way. But there are
> practical concerns. For example, assuming UFCS worked in D, you *could*
> possibly do 5.seconds. However, this means you need a module-level
> function:
>
> Duration seconds(long n) {...}
>
> But the way D's overload resolution works, this precludes having
> 5.seconds work, and also having a member named 'seconds' in your
> class/struct.
>

Actually, UFCS functions are currently always looked up at the module level.

"James Miller" <james@aatch.net> wrote in message news:mailman.235.1331210469.4860.digitalmars-d@puremagic.com...
>On 9 March 2012 01:23, Stewart Gordon <smjg_1998@yahoo.com> wrote:
>>
>> I'm finding it hard to figure how someone would pronounce the "o" and "u"
>> in
>> "colour" separately.
>>

I would imagine it'd be like "kuh-lore".

>Being British means that I do notice the differences in pronunciation, I've pretty much done the opposite to Reagan, gone from England to NZ. I tend to get frustrated when I can't even correct pronunciation because nobody can hear the difference!

I have a little extra insight into this as my mom is a speech/language pathologist:

As you've noticed, trying to get a person to hear the difference often doesn't work (And even if they can hear it, that doesn't necessarily give them enough info to actually pronounce it). I think the right thing to do, at least in cases where it actually matters, is to instruct them on the actual mouth movements involved. Then they can "feel" the difference, and start to hear themselves making the different sound. "Hearing" it can naturally follow from that.

When I started (trying to) learn Japanese, I had trouble hearing the Japanese "R" sound. But the instructor explained how to pronounce it: Pay attention to how your tongue is positioned when saying the English "R" and "L". For the Japanese "R", do the same thing, but put your tongue about half-way in-between: just in front of what's called the "boney ridge" instead of just behind it (English "R") or on the back of the teeth (English "L"). After learning that, I was able to not only pronounce it (more or less) but also hear the difference much better since I actually knew what to expect (interestingly, the Japanese "R" frequently sounds more like a "D" than an English "L" or "R").

A similar thing is the "tsu" sound in Japanese. The "TS" combination is very intimidating for most English speakers, and I doubt many English speakers can easily hear it. But as my class's instructor pointed out: It's exactly like the "ts" at the end of "boots". So just say that and folow up with a "u". Now I can say and hear it just fine (At least, I *think* I can - a native Japanese speaker would have to be the real judge).

On Thursday, March 08, 2012 12:09:29 Stewart Gordon wrote:
> On 08/03/2012 02:56, Jonathan M Davis wrote:
> > On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
> >> On 07/03/2012 08:10, Jacob Carlborg wrote:
> >> <snip>
> >> 
> >>> Yeah, Clock.now() would be good and Data.today() as well.
> >> 
> >> My utility library has, for consistency, DateValue.now, TimeValue.now and DateTime.now.
> > 
> > I specically avoided giving a way to get the time with any type other than
> > SysTime (and TickDuration for using a monotonic clock), because I believe
> > that it leads to incorrect behavior. Any time that you're dealing with
> > the system clock, you should be dealing with SysTime. Date, TimeOfDay,
> > and DateTime are for when you need the date and/or time but don't care
> > about what absolute time it's associated with in the real world.
> > Treating DateTime as corresponding to a specific point in time is just
> > going to cause problems, because it has no time zone.
> 
> <snip>
> 
> TimeValue and DateTime in my library always store the time in UTC. It uses a global variable for time zone. But a LocalTime could be added to the mix. This would be used to hold a time that, when combined with a date, will become a DateTime set according to the correct time zone.

Which is very different from Date, TimeOfDay, and DateTime in std.datetime, since those are effectively calendar dates/times with no concept of time zone. They're just the date and/or time (e.g. 2012-02-05 or 14:07), which can be _very_ useful, but it means that you have to realize that you should be using SysTime when you actually want the system time and/or an absolute time rather than a generic date and/or time that you're not really going to try and associate to a particular system time. Actually, when I was doing some date/time stuff at work (in C++), I tried to port a version of SysTime over _without_ Date, TimeOfDay, and DateTime, since all we cared about for our stuff was the system time, and I ended up having to add them anyway, because they simplified things so much (if nothing else, SysTime needs them to do a lot of its stuff).

> Interestingly, SQL has
> 
> DATE - just a date, simple as that
> TIME - a time of day in unspecified time zone
> TIMETZ - a time of day with time zone specified
> TIMESTAMP - a date/time combination in unspecified time zone
> TIMESTAMPTZ - an absolute instant in time, which can be constructed and
> examined according to the system time zone
> 
> Notice how different TIMETZ and TIMESTAMPTZ are, even though "TZ" abbreviates " WITH TIME ZONE" in both cases. Moreover, system time zones (in at least some SQL implementations) include DST rules, whereas the zone stored in a TIMETZ is just a UTC offset.
> 
> In my scheme:
> - DateValue corresponds to DATE
> - TimeValue corresponds to a TIMETZ with the zone set as UTC
> - DateTime corresponds to TIMESTAMPTZ
> - LocalTime, if it were added, would correspond to TIME
> 
> I'd also like to add DST handling to my library, but it'll take thinking about. I'm not sure what OS APIs have in the way of retrieving the DST rules for the locale. Though I have just discovered GetDynamicTimeZoneInformation in the Windows API - I'll investigate it later.

LOL. The OS APIs suck at giving proper time info, and Windows' not only has very few time zones, but their data is _frequently_ wrong - especially with regards to DST. You're also stuck reading the registry if you want timezone- specific information rather than simply info for the current time zone. GetDynamicTimeZoneInformation is an attempt to fix their very broken, historical API (GetTimeZoneInformation) which doesn't take into account the fact that DST rules can change. GetDynamicTimeZoneInformation does, but it only exists on Vista+. However, Microsoft made it so that the functions that use the result from GetTimeZoneInformation basically ignore what's in that struct and use the same information that the struct from GetDynamicTimeZoneInformation uses (probably by either using a memcmp or checking the time zone's name to determine that it's a known timezone). And _all_ of that is highly broken in that it bases DST switches off of the _local_ time rather than UTC. It was a nightmare to sort all of that out.

In general, Posix does much better (though you do end up having to read the timezone files yourself if you want to use anything other than the local timezone). It's information is _much_ more accurate, and it bases everything off of UTC. However, unlike Windows, it's a royal pain to figure out what the local timezone is. And the C API that they give you sucks just as much as the Windows one does.

Yeah. I could probably complain for hours about how pathetic the time stuff is that the OSes provide. So, I'll shut up now. I think that std.datetime does a good job of building on top of what's there, but the patheticness of the C APIs made it a lot harder than it should be.

- Jonathan M Davis

On Thursday, March 08, 2012 06:55:17 Steven Schveighoffer wrote:
> On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana <ary@esperanto.org.ar>
> 
> wrote:
> > The problem is not mistaking it with something else. The problem is when you want to write it. In Ruby my mind works like this:
> > 
> > Mind: "How would I get a span for 5 seconds?"
> > Mind: "Let's try 5.seconds"
> > Mind: "Wow, it works!"
> > 
> > I'm trying to remember cases when I just wrote what my mind thought it was correct and I was *so* surprised it worked out of the box in Ruby. Like writing array.last, and get it to work, instead of array[array.length - 1]. But in D, from the docs (http://dlang.org/arrays.html )
> > 
> > bar[$-1] // retrieves last element of the array
> > 
> > I read: bar dollar minus one wait what??
> 
> array.back;
> 
> http://dlang.org/phobos/std_array.html#back
> 
> This is the issue with "intuition". It's easy to say, "hey I guessed
> right in Ruby! Ruby must be more intuitive!". But if you were someone
> who knew the range interfaces, wouldn't you try array.back in Ruby and say
> "well, obviously D is more intuitive, it knew what I wanted without even
> looking up the docs!"
> 
> You are never going to come up with something that's *perfectly* intuitive for everyone in every situation.

Yeah. I don't understand how anyone can expect to just write code and have it work without looking anything up. Best case, the IDE does code completion for you, and maybe you don't have to actually look at the docs, but without knowing what the functions do, that's not necessarily wise even if the functions are well-named, because they still might not do _exactly_ what you expect (and everyone's expectations vary).

The names need to be good enough that the code is reasonably understandable without necessarily having to look at the documentation (though there's a good chance that you're still going to have to look at the docs), and they should be good enough that most people have a good chance of finding what they're looking for when they look for a funcition or type in the docs. But there are so many variations on how things can be named, and so many people expect different things, that you're never going to win. At best, you please the majority. But names are _always_ bikeshedding issues.

A _lot_ of what goes into symbol naming is personal preference and a matter of what you've previously been exposed to rather than anything objective, and there will pretty much always be disagreements on it.

- Jonathan M davis

On Thursday, 8 March 2012 at 19:04:32 UTC, Jonathan M Davis wrote:
> Yeah. I don't understand how anyone can expect to just write code and have it work without looking anything up.


What prompted me to start this thread is that I knew
it was core.time.duration!"hours" already.... except
it was actually "dur".

I had looked it up previously, but filed it in my
brain under "duration" rather than the nonsense "dur".

"Alix Pexton" <alix.DOT.pexton@gmail.DOT.com> wrote in message news:jja8k8$j14$1@digitalmars.com...
>I feel compelled to point out that there is no such thing as "British English". There is English, the written language with all its archaic spellings and there are many spoken dialects, the most formal of which is RP (Received Pronunciation) sometimes called The Queen's English (even though she is German).
>

Yea, that is a good point. OTOH, it's often convenient (and common) to assume one particular "de facto standard" dialict unless otherwise stated. Here in the US, we have regional dialects too (although perhaps not to the same extent as how much the British dialects differ from each other), but when people either inside or outside the US refer to "American English", typically they're referring to the one that's spoken in the US mid-west and on TV/movies. Similarly, in the western world, "Japanese" is, by default, considered to be the Tokyo dialect (as opposed to Kansai or whatever other ones there may be).

It might be different in Europe, but in the US, we think of "British English", unless otherwise specified, as being the London/"Queen's English" version. At least, those of us who are aware of the varied British dialects ;)

FWIW.

> I tolerate USian spellings

I see I'm not the only one with a pet peeve that "'America' is two continents, not one country" :)

> as much as non-English speaking programmers do, because I see it as an accepted "Programmer's English".
>

Being from the US I couldn't be sure, but that's what I has suspected.