On 3/6/12 8:58 PM, 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"?

Also, it becomes long because it has a weird syntax, that either way is going to be hard to read. In Ruby (with active support) I can just do:

44.seconds

Why D doesn't do the same if it has UFCS? (I hope I got the acronym well)

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? 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.

No, dur is not a fantastic name, but when I had to choose between a name which become very long when combined with the required template argument, and dur, which is perfectly clear with minimal explanation - albeit not as clear as duration would be - but makes the symbol name shorter and therefore less of an issue to use in longer expressions, I went with the shorter name.

If anything, I'd argue that std.datetime and core.time have too many symbol names which are overly long in their attempt to be appropriately descriptive. I would have expected people to be complaining about the verboseness of some of them, not that some of them were abbreviated.

- Jonathan M Davis

On Tuesday, March 06, 2012 17:00:19 Brad Anderson wrote:
> I wasn't around for the creation of datetime but I'm curious why a boost
> datetime-like duration construction shortcut approach to durations wasn't
> used. That is, you can write weeks(1), months(6), years(10), hours(17),
> minutes(12), etc. (although there is now days(int) for some reason).

Because then you've got incredibly common names used as top-level symbols. It's also not generic at all. As it stands, you can have a function which does dur!units(value). You can't do that with weeks(1), months(6), etc.

- Jonathan M Davis

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. So, what if there was a way to satisfy both parties and keep backwards compatibility? Is there any compelling reason why simply wrapping Phobos into a different format would be such bad thing? Meaning:

    // system.io

    private import std.stdio;

    alias write   Write;
    alias writeln WriteLine;
    // etc...

Besides keeping things in-sync and error messages referring to the original function names (which could be amended), I don't see why such a library couldn't be written as a way to make the language easier to swallow to potential D users coming from Java/C#. Microsoft used similar tactics with J#/F# to help the Java/Python folks adapt their code to .NET.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.110.1331077432.4860.digitalmars-d@puremagic.com...
> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
>>
>> 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.
>

This is exactly why "dur" never bothered me. Now that Adam's brought it up, I can see how it can be considered bad, but at the same time 'duration!"seconds"(44)' is a rather long to way to refer to x number of seconds.

But, I'm thinking this whole "dur vs duration" matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the "dur" or "duration" for anyway?

I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done:

alias dur!"years" years;
alias dur!"months" months;
alias dur!"weeks" weeks;
alias dur!"days" days;
alias dur!"hours" hours;
alias dur!"minutes" minutes;
alias dur!"seconds" seconds;
alias dur!"msecs" msecs;
alias dur!"usecs" usecs;
alias dur!"hnsecs" hnsecs;

And then we have the brevity issue solved (and in fact, improved over "dur"), so then "dur" can (and should) change to "duration" without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit.

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!
> 
> 
> 
> Why aren't we using real words here? Real words are easier to remember and easier to type.
> 
> 
> This is almost as bad as "creat" and "umount". It's like
> these names are deliberately designed to fail your
> first guess. Our minds are pretty good at remembering
> words and sentences; it is an existing database in there
> that follow established patterns.
> 
> Arbitrary abbreviations only work through special-cased brute force rote memorization.
> 
> 
> And the dmd spellchecker doesn't always help:
> 
> Error: template instance duration!("hours") template 'duration' is not defined, did you mean Duration?
> 
> 
> Nope, apparently, I meant "dur". Ridiculous.
> 
> 
> 
> std.datetime isn't the only one that does this, of course. rndGen() in the middle of sane names like "unpredictableSeed" and "randomShuffle". There's more, too.
> 
> 
> 
> 
> 
> Some abbreviations are justified by precedent. rmdir() has been around for a long time, so we know what it is. Stringz is similarly classic. "printf" is one of the earliest words many of us saw as programmers.
> 
> But "dur"? "curr"?
> 
> 
> What the hell? Can we please stop this?

Agree !!! that this is the the phobos biggest flaw , the lack of a good naming convention . It is time to formulate a good naming convention .

good luck
Bill

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.117.1331079921.4860.digitalmars-d@puremagic.com...
> On Tuesday, March 06, 2012 17:00:19 Brad Anderson wrote:
>> I wasn't around for the creation of datetime but I'm curious why a boost
>> datetime-like duration construction shortcut approach to durations wasn't
>> used. That is, you can write weeks(1), months(6), years(10), hours(17),
>> minutes(12), etc. (although there is now days(int) for some reason).
>
> Because then you've got incredibly common names used as top-level symbols.

In this case, I can't imagine that would be a realistic problem in practice. There aren't many things that can be called, for example, "hours":

1. There's the concept of the duration itself, which is already covered by std.datetime and core.time, so nobody needs to reinvent that wheel (and if they do, they're not going to be importing std.datetime anyway).

2. There's "number of hours". In which case there's plenty of options: A. Change it to "numHours" or something descriptive like "hoursOfPlaytime" (which is a better idea anyway - if you're in the habit of using vars named like "hours", those can just as easily collide with each other as they can collide with "std.datetime.hours"). B. Keep it "hours" and remember this isn't C++: We have many excellent features for dealing with symbol name-collisions. And in many/most cases, you'll never even have a collision anyway.

3. Nothing. That's it, just those two: The "concept of hours as a duration" and "number of hours". Thie first is a complete non-issue, and the second is a miniscule issue at most.

I think the name collision issue (is this case) is just worrying over nothing.

> It's also not generic at all. As it stands, you can have a function which
> does
> dur!units(value). You can't do that with weeks(1), months(6), etc.
>

First of all, I can't imagine that would be needed frequently enough to justify having to always use "dur" or "duration". Second, as I said in another post, just drop this in:

alias duration!"years" years;
alias duration!"months" months;
alias duration!"weeks" weeks;
alias duration!"days" days;
alias duration!"hours" hours;
alias duration!"minutes" minutes;
alias duration!"seconds" seconds;
alias duration!"msecs" msecs;
alias duration!"usecs" usecs;
alias duration!"hnsecs" hnsecs;

All (real) problems solved.

On Tue, Mar 06, 2012 at 09:18:13PM -0500, Nick Sabalausky wrote: [...]
> But, I'm thinking this whole "dur vs duration" matter is stupid anyway.  Seconds, hours, etc *are* durations. What the hell do we even need the "dur" or "duration" for anyway?
> 
> I say fuck it: Let's just toss this into core.time (or std.datetime or
> whatever) and be done:
> 
> alias dur!"years" years;
> alias dur!"months" months;
> alias dur!"weeks" weeks;
> alias dur!"days" days;
> alias dur!"hours" hours;
> alias dur!"minutes" minutes;
> alias dur!"seconds" seconds;
> alias dur!"msecs" msecs;
> alias dur!"usecs" usecs;
> alias dur!"hnsecs" hnsecs;

+1.


> And then we have the brevity issue solved (and in fact, improved over "dur"), so then "dur" can (and should) change to "duration" without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit.

Name collisions can be solved by D's excellent import mechanisms. If somebody imports std.datetime and gets a collision, well just write std.datetime.secs and my.own.module.secs instead. If that's too verbose, import aliases are there precisely for these kinds of situations.

This is an excellent idea.  I say we should go with this.


T

-- 
Food and laptops don't mix.

On Wednesday, 7 March 2012 at 02:38:55 UTC, Nick Sabalausky wrote:
> alias duration!"years" years;
> All (real) problems solved.

I'm Adam D. Ruppe, and I approve this message.

Though, I still say the underlying silliness remains
ridiculous. currentTime >> currTime.

F i L Wrote:

> 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. So, what if there was a way to satisfy both parties and keep backwards compatibility? Is there any compelling reason why simply wrapping Phobos into a different format would be such bad thing? Meaning:
> 
>      // system.io
> 
>      private import std.stdio;
> 
>      alias write   Write;
>      alias writeln WriteLine;
>      // etc...
> 
> Besides keeping things in-sync and error messages referring to the original function names (which could be amended), I don't see why such a library couldn't be written as a way to make the language easier to swallow to potential D users coming from Java/C#. Microsoft used similar tactics with J#/F# to help the Java/Python folks adapt their code to .NET.

good idea ! can refer to the java c # naming specification, to work out d own naming specification

good luck£¡
Bill