"Jacob Carlborg" <doob@me.com> wrote in message news:jj74p4$n9r$3@digitalmars.com...
> On 2012-03-07 03:18, Nick Sabalausky wrote:
>> "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.
>
> I agree, adding these aliases would be a good idea.
>

I like that so many people agree with this. But I do want to point out again, just in case anyone missed it, that I'm hoping it would *actually* be:

alias duration!"years" years;
alias duration!"months" months;
etc...

Since the aliases themselves mitigate the need for "duration" itself to be shortened.

Course, I can still live with just 'alias dur!"years" years;..etc...'. The *main* thing is that we can just do "hours(5)"...(or heck, once UFCS finally gets fixed: "5.hours")

On Wed, Mar 07, 2012 at 01:38:08PM -0500, Nick Sabalausky wrote:
> "Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:sgmfyzmrfygshlmfqsdj@forum.dlang.org...
[[...]
> > But, either option is better than "Clr" or "Col".
> 
> "clr" is the verb "clear" and "col" is "column" :)
[...]

clr == common language runtime
col == polysemous word meaning anything from column to color to collect to colon.

;-)

Jokes aside, though I'm not suggesting we actually do this, I frankly find Col an acceptable abbreviation for *both* "Color" and "Column", because context usually makes it clear which one is meant. The human brain is highly capable of inferring intention from context (which is why function overloading is even remotely workable in the first place). Witness, for example, the variety of meanings the word 'set' may have depending on context. It's a horribly overloaded, overused, and ambiguous word, objectively speaking. But we also use it every day without even thinking twice, even in programming (e.g., set a variable vs. a set of objects vs. an object of type Set vs. language rules set in stone).


T

-- 
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson

On Wed, Mar 07, 2012 at 01:50:03PM -0500, Nick Sabalausky wrote:
> "Jacob Carlborg" <doob@me.com> wrote in message news:jj74p4$n9r$3@digitalmars.com...
> > On 2012-03-07 03:18, Nick Sabalausky wrote:
[...]
> >> 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.
> >
> > I agree, adding these aliases would be a good idea.
> >
> 
> I like that so many people agree with this. But I do want to point out again, just in case anyone missed it, that I'm hoping it would *actually* be:
> 
> alias duration!"years" years;
> alias duration!"months" months;
> etc...
> 
> Since the aliases themselves mitigate the need for "duration" itself to be shortened.

+1.


> Course, I can still live with just 'alias dur!"years" years;..etc...'.
> The *main* thing is that we can just do "hours(5)"...(or heck, once
> UFCS finally gets fixed: "5.hours")
[...]

Hooray! Ruby syntax FTW!

Tangential comment:

Before I discovered D, Ruby was among the top candidates in my list of programming languages close to my ideals. Once D pulls off UFCS, it will trump Ruby in so many more ways... such as being able to effectively extend class methods just by declaring module-level functions of the form:

	retType func(classname obj, ...);

(which I believe is already (somewhat?) supported). Among many other
things.

Supporting stuff like 5.hours will introduce additional complications to
D's lexical structure, though. The lexer will have to understand it as
(int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). And then if
you actually *wanted* a float, you'd have another ambiguity: 5..hours
could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And
5.0.hours just looks... weird.


T

-- 
"How are you doing?" "Doing what?"

On Wednesday, March 07, 2012 08:47:48 Steven Schveighoffer wrote:
> On Tue, 06 Mar 2012 12:09:47 -0500, Andrej Mitrovic
> 
> <andrej.mitrovich@gmail.com> wrote:
> > I'll never forgive std.datetime for this mistake:
> > 
> > auto sw = StopWatch(AutoStart.yes);
> > writeln(sw.peek.hnsecs);
> > writeln(sw.peek.nsecs);
> > writeln(sw.peek.usecs);
> > writeln(sw.peek.msecs);
> > writeln(sw.peek.secs); // bzzzzz NOPE
> > writeln(sw.peek.seconds);
> > 
> > I misspell this thing every single time I use stopwatch to count seconds.
> 
> this is a no-brainer:
> 
> Duration dur(string units)(long length) @safe pure nothrow
> if(units == "weeks" ||
> units == "days" ||
> units == "hours" ||
> units == "minutes" ||
> units == "seconds" ||
> units == "secs" || // added
> units == "msecs" ||
> units == "usecs" ||
> units == "hnsecs" ||
> units == "nsecs")
> {
> return Duration(convert!(units, "hnsecs")(length));
> }
> 
> // etc, everywhere "seconds" is used, add "secs" as well.
> 
> I'll see if I can do a pull request.

I've avoided that primarily because it results in inconsistent code. It's pretty much equivalent to adding extraneous aliases, though it's not as bad, since it's not a general symbol. But if it's a sufficient usability improvement, then maybe it's a good idea.

- Jonathan M Davis

On Tuesday, 6 March 2012 at 18:22:03 UTC, deadalnix wrote:
> Le 06/03/2012 19:08, H. S. Teoh a écrit :
>> On Tue, Mar 06, 2012 at 05:38:09PM +0100, 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.
>> [...]
>>
>> I have to disagree on this one. One of the reasons I hate Java so much
>> is because of its gratuitouslyOverlongFullySpelledOutVariableNames.
>
> Let me stop you just here.
>
> Name come in a context. Hence variable names are in a function, that is in a class, that is in a package, that is in another package, ..., that is in a project.
>
> If you need a very long name to cite something, it doesn't means that it should be abbreviated. It means that it is in the wrong place and you need to refactor.
>
> When you come up with such a variable name, the code is telling you something. « Hey dude, stop here what you do, refactor and put that stuff in a convenient place before continuing ! »
>
> Unfortunately, many dev understands it as « Hey, this name is too long, let use an abbreviation ! ». No you have fucked up variable name in a fucked software architecture.
>
> This happen a lot in java. But remember, 90% of everything is crap.

I fully agree. More over, Java's verbosity problem often comes from redundant repetitions in the language itself such as:
MyWonderfulClass instance = new MyWonderfulClass(); // class name repeated

The Java/C# naming conventions themselves are wonderfully consistent and easy to remember/type (especially in an IDE like Eclipse that knows to match "MWC" to the "MyWonderfulClass").
I honestly believe that people who use horrible C/Unix like conventions should not be allowed to touch a keyboard.

At my previous work I had the "pleasure" to use legacy code in C and Fortran. One time I needed to figure out how to do something and was pointed to an ancient function who's name was an undecipherable 5 letter abbreviation,  probably written by someone who retired long ago. luckily it had comments, *but* the comments themselves were also fucking abbreviated! This is truly the most evil way to torture future junior programmers who will be unfortunate enough to inherit your code.

So no, abbreviations are *NOT* acceptable. Haven't we suffered enough?

On 3/7/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> The human brain is highly capable of inferring intention from context

I don't think our brains should be wasted on decyphering abbreviations. Too much abbreviations could drive a sane person nuts. E.g.:

http://lolcats.icanhascheezburger.com/2012/03/07/funny-cat-pictures-ai-is-not-shy/#comments

All is good with moderation though. :p

On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
> > On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
> > > In fact there is no such thing as a top level in D. (I was quite surprised to learn that a few years ago, and found it quite brilliant of Walter.)
> > 
> > True, but if names conflict, you then have to worry about using the full import paths for symbols, which can get annoying.
> 
> [...]
> 
> I thought that's what module aliases were for.

They can help, but thanks to the fact that they impact any other modules that import that module, they're often unacceptable.

- Jonathan m Davis

On Tuesday, 6 March 2012 at 18:36:08 UTC, Adam D. Ruppe wrote:
> On Tuesday, 6 March 2012 at 18:06:46 UTC, H. S. Teoh wrote:
>> I have to disagree on this one.
>
> If it was actually
> "gratuitouslyOverlongFullySpelledOutVariableNames" I might
> agree, but curr vs current is a whole other story.
>
> Abbreviating a concept makes sense: i, j, rather than
> iterationIndex or whatever. You might say "std.random.uniform"
> rather than "randomNumberFromASetWithAUniformDistribution".
>
> But, abbreviating /words/ is where it gets silly.
> "rndNumSetUniDist" is a worse name than the long one,
> since not only is it verbose, it has bizarre abbreviations
> to remember too!
>
> "dur" is the same concept as "duration"; it isn't a simpler
> name. It isn't even significantly shorter. The biggest
> difference is it isn't my first guess.
>
>> The fault is with inconsistency, not with abbreviations.
>
> It is some of both: inconsistency with words I already
> know (regular English) is what leads to the first guess
> being wrong.

vote +infinity * 2
The most important point IMO - abbreviate concepts, not words.

On Wednesday, 7 March 2012 at 10:08:53 UTC, Timon Gehr wrote:
> On 03/06/2012 10:30 PM, deadalnix wrote:
>>
>> auto helps too.
>
> This remark was explicitly about _Java_ code style.

Wrong. This is an issue with the *language*, NOT the naming convention.

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.179.1331149059.4860.digitalmars-d@puremagic.com...
> On 3/7/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>> The human brain is highly capable of inferring intention from context
>
> I don't think our brains should be wasted on decyphering abbreviations. Too much abbreviations could drive a sane person nuts.

Yes, but OTOH, too much fully-spelled-out stuff makes code much harder to read (even without going as far as the Java extreme). Good use of common abbreviations is easier to read than full words. For example, "i18n". Or "5*2" instead of "five times two". No decyphering is needed at all with good common abbreviations, and they decrease verbosity which improves readability.