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.

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:tppqmlbrqjavpandezzz@forum.dlang.org...
>
> Why aren't we using real words here? Real words are easier to remember and easier to type.
>

Some of the examples you point out are indeed bad. But at the same time, I agree with H.S. Teoh that abbreviations, when used properly (again, some of the ones pointed out are *not* done well) are much better than Java/C#-style overlySpelledOutNames.

>
> But "dur"? "curr"?
>

The "dur" is probably bad (now that you mention it), but I'm very much in favor of "curr". It's a very common need to have some "currentWhatever" (so it makes sence to make it less verbose), and the abbreviation "curr" is very common (so there's no problem with using that abbreviation). I use "curr" all the time.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.70.1331058850.4860.digitalmars-d@puremagic.com...
>
> But my point stands, that I find many of
> these names just way too long for my tastes. Like BufferedOutputStream.
> Ugh. I mean, we're writing programs here, not
> essays.
>

Exactly. Totally agree. I hate programming langauge arguments that amount to "It's not like English!". Yea? So what? It *isn't* English and it's not supposed to be!

It'd be a hell of a lot easier for someone unfamiliar with mathematical symbols to read this:

5 times quantity 7 plus 3 end of quantity

Erm, I mean:

Five times quantity seven plus three end of quantity

Look! It's just normal English! And the editor can highlight it properly! No need to remember arbitrary symbols that aren't spelled-out! I mean, shit, how does a vertical and horizontal line mean "plus"? I can't remember that!

But obviously that would be stupid. You just (trivially) learn that + is shorthand for "plus", ) is shorthand for "end of quantity", etc. (erm, excuse me..."et cetera"), and that verbose mess becomes the far, FAR more readable:

5 * (7+3)

On Tuesday, 6 March 2012 at 18:37:25 UTC, Nick Sabalausky wrote:
> I'm very much in favor of "curr".

If three characters make a big difference in really
anything, that's the real WTF. It is trivial to
type or to see on the line. (It might add up if
you refer to it a bunch of times, but in that case,
just use a local variable instead.)


I see this as more like "creat" and "umount" vs "create" and
"unmount" than "foo" and "thisIsAnExampleFunctionThatWouldNormally-
BeNamedFooButHereIWantedToGiveItAMoreDescriptiveSelfDocumenting-
NameBecauseThatsTheGoodThingToDoAmIRite".

None of the differences matter, except for the remember
difficulty; looking it up, even once, will cost more than
seeing it a thousand times.

On 03/06/2012 10:36 AM, Nick Sabalausky wrote:

> The "dur" is probably bad (now that you mention it)

Some people thought that it was amusing too: :)


http://www.reddit.com/r/programming/comments/pyd8s/parallelism_in_the_d_programming_language/

Ali

On 2012-03-06 18:35:49 +0000, "H. S. Teoh" <hsteoh@quickfur.ath.cx> said:

> Anyway, names like Clock.currentTime() are too long, IMO. There's
> nothing wrong with shortening it. But the abbreviations need to be
> consistent, so it shouldn't be currTime in one case, and curYear in
> another case. And consistency needs to be across the board.

Before abbreviating anything, try removing the superfluous. "Clock.currentTime()" might be unnecessary long, but why does it need to belong to Clock? Isn't "currentTime()" short and precise enough by itself? Now you've saved six characters and one word of clutter instead of three while keeping the same number of words.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2012-03-06 17: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!
>
>
>
> 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?

Yes, please, I completely agree.

-- 
/Jacob Carlborg

On Tue, Mar 06, 2012 at 08:04:49PM +0100, Adam D. Ruppe wrote:
> On Tuesday, 6 March 2012 at 18:37:25 UTC, Nick Sabalausky wrote:
> >I'm very much in favor of "curr".
> 
> If three characters make a big difference in really
> anything, that's the real WTF. It is trivial to
> type or to see on the line. (It might add up if
> you refer to it a bunch of times, but in that case,
> just use a local variable instead.)
> 
> 
> I see this as more like "creat" and "umount" vs "create" and "unmount" than "foo" and "thisIsAnExampleFunctionThatWouldNormally- BeNamedFooButHereIWantedToGiveItAMoreDescriptiveSelfDocumenting- NameBecauseThatsTheGoodThingToDoAmIRite".
> 
> None of the differences matter, except for the remember difficulty; looking it up, even once, will cost more than seeing it a thousand times.

I stand by my point that if the abbreviation is *consistent*, then this is a non-problem. E.g., if "current" is *always* abbreviated "curr", then you know that it's currTime, currDay, currWhatever, and you never need to try "currentDay".

As for looking it up once, you have to do that the first time anyway, to even know what the function does. It's no different from learning D keywords once, and then you know what to call them thereafter.


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??

On 06-03-2012 19:49, Nick Sabalausky wrote:
> "H. S. Teoh"<hsteoh@quickfur.ath.cx>  wrote in message
> news:mailman.70.1331058850.4860.digitalmars-d@puremagic.com...
>>
>> But my point stands, that I find many of
>> these names just way too long for my tastes. Like BufferedOutputStream.
>> Ugh. I mean, we're writing programs here, not
>> essays.
>>
>
> Exactly. Totally agree. I hate programming langauge arguments that amount to
> "It's not like English!". Yea? So what? It *isn't* English and it's not
> supposed to be!
>
> It'd be a hell of a lot easier for someone unfamiliar with mathematical
> symbols to read this:
>
> 5 times quantity 7 plus 3 end of quantity
>
> Erm, I mean:
>
> Five times quantity seven plus three end of quantity
>
> Look! It's just normal English! And the editor can highlight it properly! No
> need to remember arbitrary symbols that aren't spelled-out! I mean, shit,
> how does a vertical and horizontal line mean "plus"? I can't remember that!
>
> But obviously that would be stupid. You just (trivially) learn that + is
> shorthand for "plus", ) is shorthand for "end of quantity", etc. (erm,
> excuse me..."et cetera"), and that verbose mess becomes the far, FAR more
> readable:
>
> 5 * (7+3)
>
>
>

My reply to all of the above: Is 'etc' not a universally well-known abbreviation? ;)

-- 
- Alex

On Tue, Mar 06, 2012 at 08:47:11PM +0100, Alex Rønne Petersen wrote: [...]
> My reply to all of the above: Is 'etc' not a universally well-known abbreviation? ;)
[...]

lol... now you're giving me ideas for another esolang, called Etc. Recognized tokens are 'etc', and recognized keywords are 'etc'. Statements are of the form 'etc'. Multiple occurrences of 'etc' can be shortened to just 'etc', so here's a hello world program:

	etc

And here's an Etc compiler written in Etc:

	etc

And here's a program to cure world hunger and solve world peace:

	etc

Isn't that a great language?! :P


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL