www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Arbitrary abbreviations in phobos considered ridiculous

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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?
Mar 06 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-03-2012 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!


There's also core.time.TickDuration.currSystemTick() which really ought 
to be currentSystemTicks.


 Why aren't we using real words here? Real words are easier
 to remember and easier to type.


+1.


 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?


I agree entirely. Phobos (and druntime) needs to follow the same 
convention the .NET Framework does: Always use whole words, and only 
abbreviate if the abbreviation is universally well-known.

-- 
- Alex
Mar 06 2012
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Mar 06 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 06.03.2012 21:09, Andrej Mitrovic 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.


Me too.
It's coming from separate stopwatch module that got merged with 
std.datetime, so the blame is somewhat misplaced :)

-- 
Dmitry Olshansky
Mar 06 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/6/12, Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 It's coming from separate stopwatch module that got merged with
 std.datetime, so the blame is somewhat misplaced :)


I've argued about it with the current DateTime Czar, so it's not
really missplaced. :)
Mar 06 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, March 06, 2012 19:00:21 Andrej Mitrovic wrote:

 On 3/6/12, Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 It's coming from separate stopwatch module that got merged with
 std.datetime, so the blame is somewhat misplaced :)


 
 I've argued about it with the current DateTime Czar, so it's not
 really missplaced. :)


Units which are sub-second are abbreviated. The others aren't. Making it
secs would be more consistent with the sub-second names, but it would make
it less consistent with the others. The only thing which would be completely
consistent would be to abbreviate them all or to abbreviate none of them.
Abbreviations get very ugly (and harder to remember IMO) with the larger
units, and not abbreviating the smaller ones makes them ludicrously long.
So, the compromise is to abbreviate the sub-second units and not the others.
And I believe that std.datetime and core.time are very consistent with
regards to how units are abbreviated.

Now, as for  TickDuration in specific, there's a good chance that it was the
way that it is when it was created - in which case choosing seconds over secs
for that wasn't me - but it's consistent with all of the rest of the time stuff
regardless.

- Jonathan M Davis
Mar 06 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/03/2012 18:09, Andrej Mitrovic a crit :

 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.


I feel less lonely :D But that doesn't solve the problem.
Mar 06 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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.

-Steve
Mar 07 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/7/12, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 I'll see if I can do a pull request.


For my own purposes what I did was wrap StopWatch in a custom struct
and used alias this to overwrite some of its functions. It's one of
the things that makes D so great, I can basically rewrite an external
API with zero hit on performance.

In fact, maybe we should add a note of this capability to the
http://en.wikipedia.org/wiki/Adapter_pattern page (e.g. a
"compile-time adapter" section)
Mar 07 2012
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 07 Mar 2012 08:47:48 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 I'll see if I can do a pull request.


Almost done, need to test:

https://github.com/schveiguy/druntime/commit/cf9d1ba4f5498c447d91497cb5edbd735d2b4c7e

Actually cleans up a lot of the template constraints too...

-Steve
Mar 07 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 07 Mar 2012 10:25:32 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Wed, 07 Mar 2012 08:47:48 -0500, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:


 I'll see if I can do a pull request.


 Almost done, need to test:

 https://github.com/schveiguy/druntime/commit/cf9d1ba4f5498c447d91497cb5edbd735d2b4c7e

 Actually cleans up a lot of the template constraints too...


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

https://github.com/D-Programming-Language/phobos/pull/483

-Steve
Mar 07 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 07 Mar 2012 17:11:43 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Wed, 07 Mar 2012 10:25:32 -0500, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:


 On Wed, 07 Mar 2012 08:47:48 -0500, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:


 I'll see if I can do a pull request.


 Almost done, need to test:

 https://github.com/schveiguy/druntime/commit/cf9d1ba4f5498c447d91497cb5edbd735d2b4c7e

 Actually cleans up a lot of the template constraints too...


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

 https://github.com/D-Programming-Language/phobos/pull/483


These have been rejected, so I guess you're stuck with seconds instead of  
secs :(

-Steve
Mar 09 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 07, 2012 at 03:30:15PM +0100, Andrej Mitrovic wrote:

 On 3/7/12, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 I'll see if I can do a pull request.


 
 For my own purposes what I did was wrap StopWatch in a custom struct
 and used alias this to overwrite some of its functions. It's one of
 the things that makes D so great, I can basically rewrite an external
 API with zero hit on performance.


+1. And what makes D even greater, is that it can do this without stupid
convoluted syntax that either looks like line noise (*ahem*C++template
syntax*ahem*) or rewrites the entire language (*cough*Cmacros*ahem*).



 In fact, maybe we should add a note of this capability to the
 http://en.wikipedia.org/wiki/Adapter_pattern page (e.g. a
 "compile-time adapter" section)


Beware the deletionists, though, if you do it.


T

-- 
Let's call it an accidental feature. -- Larry Wall
Mar 07 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Mar 07 2012
parent Mike Parker <aldacron gmail.com> writes:
On 3/8/2012 4:27 AM, Jonathan M Davis wrote:

 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.


In this case, I think it very much is. I saw your explanation earlier 
that everything sub-second is abbreviated, but to me (and several 
others, obviously) that's just unintuitive. I see "msecs", "usecs", and 
so on and I naturally think "secs" rather than "seconds", most likely 
because it's a part of each abbreviation. Steve's solution is the right 
one, I think.
Mar 07 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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. I
mean, it takes almost the entire line of code to just refer to a
variable, let alone do anything useful with it. There's nothing wrong
with using abbreviations... BUT they have to be *consistent*.

I do agree with you that arbitrary abbreviations are very bad. One
module abbreviates "current" as "cur" and another module uses "curr". I
agree that's very bad. We do need to standardize on these things so that
they are consistent.

My stance is that variable names *should* be abbreviated, but within
reason, and abbreviations must be *consistent*.  Shortening loop indices
to i, j, k is OK, because we know what they mean. However, renaming,
say, "hours" to "i" is bad. On the other hand, spelling out
"dayOfTheMonthExceptInLeapYears" is bad too. There needs to be a
balance. Which is where consistency comes in, because if "balance" means
"arbitrary point between two extremes", that doesn't work either.

The sec/seconds arbitrary switch as somebody pointed out is an example
of inconsistency. It causes confusion and makes it hard to remember. But
if seconds was *always* abbreviated "sec", then there's no problem at
all, and it's easier to type too.

IOW I don't think abbreviations would be that big an issue if it weren't
for the inconsistency. The fault is with inconsistency, not with
abbreviations.


T

-- 
Life would be easier if I had the source code. -- YHL
Mar 06 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 06-03-2012 19:08, H. S. Teoh wrote:

 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. I
 mean, it takes almost the entire line of code to just refer to a
 variable, let alone do anything useful with it. There's nothing wrong
 with using abbreviations... BUT they have to be *consistent*.

 I do agree with you that arbitrary abbreviations are very bad. One
 module abbreviates "current" as "cur" and another module uses "curr". I
 agree that's very bad. We do need to standardize on these things so that
 they are consistent.

 My stance is that variable names *should* be abbreviated, but within
 reason, and abbreviations must be *consistent*.  Shortening loop indices
 to i, j, k is OK, because we know what they mean. However, renaming,
 say, "hours" to "i" is bad. On the other hand, spelling out
 "dayOfTheMonthExceptInLeapYears" is bad too. There needs to be a
 balance. Which is where consistency comes in, because if "balance" means
 "arbitrary point between two extremes", that doesn't work either.

 The sec/seconds arbitrary switch as somebody pointed out is an example
 of inconsistency. It causes confusion and makes it hard to remember. But
 if seconds was *always* abbreviated "sec", then there's no problem at
 all, and it's easier to type too.

 IOW I don't think abbreviations would be that big an issue if it weren't
 for the inconsistency. The fault is with inconsistency, not with
 abbreviations.


 T


You're arguing about variable names while the original post was about 
function names. IMHO you should not conflate naming of these two; the 
former is about locally scoped symbols while the latter is about 
publicly exposed APIs.

(Also, seriously, I think you're over-dramatizing the Java variable 
naming thing; I rarely see names that are as bad as you claim...)

-- 
- Alex
Mar 06 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 06, 2012 at 07:13:47PM +0100, Alex Rnne Petersen wrote:

 On 06-03-2012 19:08, H. S. Teoh wrote:

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. I
mean, it takes almost the entire line of code to just refer to a
variable, let alone do anything useful with it. There's nothing wrong
with using abbreviations... BUT they have to be *consistent*.

I do agree with you that arbitrary abbreviations are very bad. One
module abbreviates "current" as "cur" and another module uses "curr". I
agree that's very bad. We do need to standardize on these things so that
they are consistent.

My stance is that variable names *should* be abbreviated, but within
reason, and abbreviations must be *consistent*.  Shortening loop indices
to i, j, k is OK, because we know what they mean. However, renaming,
say, "hours" to "i" is bad. On the other hand, spelling out
"dayOfTheMonthExceptInLeapYears" is bad too. There needs to be a
balance. Which is where consistency comes in, because if "balance" means
"arbitrary point between two extremes", that doesn't work either.

The sec/seconds arbitrary switch as somebody pointed out is an example
of inconsistency. It causes confusion and makes it hard to remember. But
if seconds was *always* abbreviated "sec", then there's no problem at
all, and it's easier to type too.

IOW I don't think abbreviations would be that big an issue if it weren't
for the inconsistency. The fault is with inconsistency, not with
abbreviations.


T


 
 You're arguing about variable names while the original post was
 about function names. IMHO you should not conflate naming of these
 two; the former is about locally scoped symbols while the latter is
 about publicly exposed APIs.


The same rule applies. Function names should not be overly long,
especially if they are limited in scope (say, class methods). The
general rule is that the wider the scope of a name, the more unambiguous
it needs to be. (And unambiguous doesn't necessarily mean longer.)

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.



 (Also, seriously, I think you're over-dramatizing the Java variable
 naming thing; I rarely see names that are as bad as you claim...)


[...]

OK, I exaggerated a little. :-) But my point stands, that I find many of
these names just way too long for my tastes. Like BufferedOutputStream.
Or ByteArrayOutputStream.  Ugh. I mean, we're writing programs here, not
essays. Why spell things out in full if we don't need to?


T

-- 
If you think you are too small to make a difference, try sleeping in a
closed room with a mosquito. -- Jan van Steenbergen
Mar 06 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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)
Mar 06 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Mar 06 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 06, 2012 at 08:47:11PM +0100, Alex Rnne 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
Mar 06 2012
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 06/03/2012 18:49, Nick Sabalausky wrote:
<snip>

 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!


<snip>

There's another esolang idea - no symbols to have to remember, you have to
spell 
everything out.

OK, so maybe it's already been done (COBOL, and to some extent SQL).

Stewart.
Mar 07 2012
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
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/
Mar 06 2012
prev sibling parent Jos van Uden <user domain.invalid> writes:
On 6-3-2012 19:35, H. S. Teoh wrote:

 On Tue, Mar 06, 2012 at 07:13:47PM +0100, Alex Rnne Petersen wrote:



 (Also, seriously, I think you're over-dramatizing the Java variable
 naming thing; I rarely see names that are as bad as you claim...)


 [...]

 OK, I exaggerated a little. :-) But my point stands, that I find many of
 these names just way too long for my tastes. Like BufferedOutputStream.
 Or ByteArrayOutputStream.  Ugh. I mean, we're writing programs here, not
 essays. Why spell things out in full if we don't need to?


long time = System.currentTimeMillis();

I use a macro for that one :-)

Jos
Mar 07 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/06/2012 07:13 PM, Alex Rnne Petersen wrote:

 (Also, seriously, I think you're over-dramatizing the Java variable
 naming thing; I rarely see names that are as bad as you claim...)


It is not only about single names, but also about how many times you 
have to spell them out in short intervals.

try{
     SqlConstraintViolatedExceptionFactoryWrapper 
sqlConstraintViolatedExceptionFactoryWrapper = new 
SqlConstraintViolatedExceptionFactoryWrapper(new 
SqlConstraintViolatedExceptionFactory(...));
     SqlConstraintViolatedException sqlConstraintViolatedException = 
sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedException(...);
     throw sqlConstraintViolatedException;
}catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
     // ...
}catch(SqlConstraintViolatedExceptionFactoryException e){
     // ...
}

Deliberately over-dramatized.
Mar 06 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 06/03/2012 21:00, Timon Gehr a crit :

 On 03/06/2012 07:13 PM, Alex Rnne Petersen wrote:

 (Also, seriously, I think you're over-dramatizing the Java variable
 naming thing; I rarely see names that are as bad as you claim...)


 It is not only about single names, but also about how many times you
 have to spell them out in short intervals.

 try{
 SqlConstraintViolatedExceptionFactoryWrapper
 sqlConstraintViolatedExceptionFactoryWrapper = new
 SqlConstraintViolatedExceptionFactoryWrapper(new
 SqlConstraintViolatedExceptionFactory(...));
 SqlConstraintViolatedException sqlConstraintViolatedException =
 sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedException(...);

 throw sqlConstraintViolatedException;
 }catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
 // ...
 }catch(SqlConstraintViolatedExceptionFactoryException e){
 // ...
 }

 Deliberately over-dramatized.


As I said, names comes in a context. Overly long names tell about the 
fact that the name isn't at the right place and things should be 
refactored, to provide a nice place to that named stuff.

auto helps too.
Mar 06 2012
next sibling parent reply James Miller <james aatch.net> writes:
On 7 March 2012 10:30, deadalnix <deadalnix gmail.com> wrote:

 Le 06/03/2012 21:00, Timon Gehr a =C3=A9crit :


 On 03/06/2012 07:13 PM, Alex R=C3=B8nne Petersen wrote:

 (Also, seriously, I think you're over-dramatizing the Java variable
 naming thing; I rarely see names that are as bad as you claim...)


 It is not only about single names, but also about how many times you
 have to spell them out in short intervals.

 try{
 SqlConstraintViolatedExceptionFactoryWrapper
 sqlConstraintViolatedExceptionFactoryWrapper =3D new
 SqlConstraintViolatedExceptionFactoryWrapper(new
 SqlConstraintViolatedExceptionFactory(...));
 SqlConstraintViolatedException sqlConstraintViolatedException =3D

 sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedExcepti=




on(...);

 throw sqlConstraintViolatedException;
 }catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
 // ...
 }catch(SqlConstraintViolatedExceptionFactoryException e){
 // ...
 }

 Deliberately over-dramatized.



 As I said, names comes in a context. Overly long names tell about the fac=


t

 that the name isn't at the right place and things should be refactored, t=


o

 provide a nice place to that named stuff.

 auto helps too.


I agree with whoever was talking about balance. This isn't a
abbreviate vs not abbreviate discussion, its about when to abbreviate
and when not to. Personally, I think Clock.currentTime() is fine,
however Clock.currentTimeWithDST is not. There is also the argument of
line length, less of an issue nowadays, but I try to stick with
reasonable line-lengths, about 100 characters (was 80, but that ended
up being too limiting for most purposes), If I have to use overly
verbose names, then that eats into my "quota" for that line,
especially annoying when I have string arguments that I don't want to
have to split.

"dur" should be "duration" because its silly otherwise. Seconds should
be either "secs" /or/ "seconds", but should be consistent, I'd say
"secs" because it meshes well with the other, sub-second, times
("nsecs", "usecs" etc) and writing out "microseconds" is a bit
verbose, especially when you're probably outputting them as "12 us"
anyway...

--
James Miller
Mar 06 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 06.03.2012, 23:50 Uhr, schrieb James Miller <james aatch.net>:


 On 7 March 2012 10:30, deadalnix <deadalnix gmail.com> wrote:

 Le 06/03/2012 21:00, Timon Gehr a =C3=A9crit :


 On 03/06/2012 07:13 PM, Alex R=C3=B8nne Petersen wrote:

 (Also, seriously, I think you're over-dramatizing the Java variable=









 naming thing; I rarely see names that are as bad as you claim...)


 It is not only about single names, but also about how many times you=







 have to spell them out in short intervals.

 try{
 SqlConstraintViolatedExceptionFactoryWrapper
 sqlConstraintViolatedExceptionFactoryWrapper =3D new
 SqlConstraintViolatedExceptionFactoryWrapper(new
 SqlConstraintViolatedExceptionFactory(...));
 SqlConstraintViolatedException sqlConstraintViolatedException =3D

 sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedExc=






eption(...);

 throw sqlConstraintViolatedException;
 }catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
 // ...
 }catch(SqlConstraintViolatedExceptionFactoryException e){
 // ...
 }

 Deliberately over-dramatized.






I have used Java commercially in Eclipse and I have to make a point for =
the combination of IDE and language here. What you really *type* for tha=
t is (<cs> meaning ctrl+space):

SCVEFW<cs><=E2=86=93><enter> <cs><=E2=86=93><=E2=86=93><=E2=86=93><enter=

 =3D new <cs><enter>new <cs><enter><tab>;<ctrl+1><=E2=86=93><enter><=E2=


=86=91><end>
SCVE<cs><=E2=86=93><enter> <cs><=E2=86=93><=E2=86=93><enter> =3D <cs><=E2=
=86=93><=E2=86=93><=E2=86=93><enter>.<enter>;
throw <cs><=E2=86=93><enter>;

resulting in the following code:

	try {
		SqlConstraintViolatedExceptionFactoryWrapper sqlConstraintViolatedExce=
ptionFactoryWrapper =3D new SqlConstraintViolatedExceptionFactoryWrapper=
(new SqlConstraintViolatedExceptionFactory());
		SqlConstraintViolatedException sqlConstraintViolatedException =3D sqlC=
onstraintViolatedExceptionFactoryWrapper.createSqlConstraintViolatedExce=
ption();
		throw sqlConstraintViolatedException;
	} catch (SqlConstraintViolatedExceptionFactoryWrapperException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	} catch (SqlConstraintViolatedExceptionFactoryException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}

That is 72 key strokes instead of 519. So the spelling (as in typing) it=
self is not a problem with camel-case auto-complete, variable name and t=
ype based parameter guessing.


 "dur" should be "duration" because its silly otherwise. Seconds should=



 be either "secs" /or/ "seconds", but should be consistent, I'd say
 "secs" because it meshes well with the other, sub-second, times
 ("nsecs", "usecs" etc) and writing out "microseconds" is a bit
 verbose, especially when you're probably outputting them as "12 us"
 anyway...

 --
 James Miller


+1
I tried to use "secs", at least two times. It is one of these cases wher=
e a minor annoyance adds up until someone eventually starts a rant about=
 it. And a lot of people realize that they found the situation odd as we=
ll, but not an issue. I can see the reasoning behind making templated fu=
nctions short, as in "dur", but it is inconsistent with Duration and alm=
ost like foo() and bar() :)
Mar 07 2012
next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
P.S.: ... I don't need to repeat the negative aspects of verbose names, but the
benefit is a consistent naming style. Considering ArrayBuffer and OutputStream,
ArrayBufferOutputStream is a natural blend, whereas ArrBufOStr would be
shorter, but difficult to remember.
Mar 07 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:op.waszojl09y6py2 marco-pc.local...

I have used Java commercially in Eclipse and I have to make a point for the
combination of IDE and language here. What you really *type* for that is 
(<cs>
meaning ctrl+space):

SCVEFW<cs><?><enter> <cs><?><?><?><enter> = new <cs><enter>new
<cs><enter><tab>;<ctrl+1><?><enter><?><end>
SCVE<cs><?><enter> <cs><?><?><enter> = <cs><?><?><?><enter>.<enter>;
throw <cs><?><enter>;

resulting in the following code:

try {
SqlConstraintViolatedExceptionFactoryWrapper 
sqlConstraintViolatedExceptionFactoryWrapper = new
SqlConstraintViolatedExceptionFactoryWrapper(new
SqlConstraintViolatedExceptionFactory());
SqlConstraintViolatedException sqlConstraintViolatedException =
sqlConstraintViolatedExceptionFactoryWrapper.createSqlConstraintViolatedException
();
throw sqlConstraintViolatedException;
} catch (SqlConstraintViolatedExceptionFactoryWrapperException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (SqlConstraintViolatedExceptionFactoryException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

That is 72 key strokes instead of 519. So the spelling (as in typing) 
itself is not a
problem with camel-case auto-complete, variable name and type based
parameter guessing.


Yea, but it's still unreadable, though. And even regarding the typing, 
that's really only applicable to Java since Java's the only language which 
pretty much everyone uses with an Eclipse-style IDE. And the only reason why 
everyone does that is because Java's completely unusable without it. Neither 
of those are applicable to D or pretty much *anything* other than Java.


I tried to use "secs", at least two times. It is one of these cases where a
minor annoyance adds up until someone eventually starts a rant about it.
And a lot of people realize that they found the situation odd as well, but 
not
an issue. I can see the reasoning behind making templated functions short,
as in "dur", but it is inconsistent with Duration and almost like foo() and
bar) :)


My thoughts on "secs vs seconds":

1. I don't feel real strongly either way.

2. I like the suggestion someone had of allowing both "secs" and "seconds". 
Normally I'd be against accepting alternate names (except as a transitional 
phase leading up to the deprecation of one of them), but in this case I 
think it could work without causing too much trouble.

3. Jonathan pointed out that both "secs" and "seconds" are inconsistent with 
other durations. He said that "seconds" was chosen to be consistent with 
"minutes", "hours", etc., and that the rule is sub-second durations use 
"*secs". After thinking about that, I've come to the conclusion that it's 
more important for seconds to be consistent with seconds. Ie, Having "msecs" 
and "seconds" is a more major inconsistency than having "secs" and "minutes" 
because with the former you have two different spellings of the *same* word: 
seconds.
Mar 07 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 07, 2012 at 01:24:03PM -0500, Nick Sabalausky wrote:
[...]

 My thoughts on "secs vs seconds":
 
 1. I don't feel real strongly either way.
 
 2. I like the suggestion someone had of allowing both "secs" and
 "seconds".  Normally I'd be against accepting alternate names (except
 as a transitional phase leading up to the deprecation of one of them),
 but in this case I think it could work without causing too much
 trouble.
 
 3. Jonathan pointed out that both "secs" and "seconds" are
 inconsistent with other durations. He said that "seconds" was chosen
 to be consistent with "minutes", "hours", etc., and that the rule is
 sub-second durations use "*secs". After thinking about that, I've come
 to the conclusion that it's more important for seconds to be
 consistent with seconds. Ie, Having "msecs" and "seconds" is a more
 major inconsistency than having "secs" and "minutes" because with the
 former you have two different spellings of the *same* word: seconds.


[...]

I agree. This is one example of what I said about consistency. If we're
going to abbreviate "seconds" to "secs" at all, we should abbreviate
*all* instances to "secs".

While I understand Jonathan's explanation of the rule of durations
longer/shorter than seconds, that's not something that someone
unfamiliar with the system would expect. Picking seconds as the boundary
between spelling it "seconds" vs. "secs" seems arbitrary. Why not pick
hours as the dividing line instead? Make it years, days, hours, mins,
secs, msecs, ...  instead. Or why not days, since days can't be
reasonably abbreviated?  Years, days, hrs, mins, secs, msecs, ....

I think the right thing to do is to consistently abbreviate seconds as
secs. As a compromise with the current state of affairs, alias "seconds"
to "secs", as Nick suggests above.


T

-- 
Don't get stuck in a closet---wear yourself out.
Mar 07 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/06/2012 10:30 PM, deadalnix wrote:

 auto helps too.


This remark was explicitly about _Java_ code style.
Mar 07 2012
next sibling parent reply "foobar" <foo bar.com> writes:
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.
Mar 07 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/07/2012 09:04 PM, foobar wrote:

 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.


It is hard to imagine how it could be concluded that this is not what 
the post has expressed.
Mar 07 2012
parent reply "foobar" <foo bar.com> writes:
On Wednesday, 7 March 2012 at 21:39:39 UTC, Timon Gehr wrote:

 On 03/07/2012 09:04 PM, foobar wrote:

 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.


 It is hard to imagine how it could be concluded that this is 
 not what the post has expressed.


Come on, do we really need to discuss the difference between a 
programming language and its coding conventions?
The fact that Java has flaws *as a language* is completely 
orthogonal to the fact that it has an excellent coding convention 
which can also be used with other languages such as D.

One of the reasons for Java's success is its code style despite 
being a simplistic language. It might be painful to write 
"duration" instead of "dur" when working on your own pet project 
but it's in a different story when dealing with large enterprise 
systems. IMO D will not catch on in a larger setting (in the 
enterprise) as long as it refuses to grow up and keeps it 
advocating its 1337 hacker attitude.
Mar 07 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/08/2012 01:08 AM, foobar wrote:

 On Wednesday, 7 March 2012 at 21:39:39 UTC, Timon Gehr wrote:

 On 03/07/2012 09:04 PM, foobar wrote:

 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.


 It is hard to imagine how it could be concluded that this is not what
 the post has expressed.


 Come on, do we really need to discuss the difference between a
 programming language and its coding conventions?
 The fact that Java has flaws *as a language* is completely orthogonal to
 the fact that it has an excellent coding convention which can also be
 used with other languages such as D.

 One of the reasons for Java's success is its code style despite being a
 simplistic language. It might be painful to write "duration" instead of
 "dur" when working on your own pet project but it's in a different story
 when dealing with large enterprise systems. IMO D will not catch on in a
 larger setting (in the enterprise) as long as it refuses to grow up and
 keeps it advocating its 1337 hacker attitude.


To make this clear, we agree on the relevant issues. There obviously has 
been a misunderstanding, and it does not make sense to argue about it.
Mar 07 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 07/03/2012 11:08, Timon Gehr a crit :

 On 03/06/2012 10:30 PM, deadalnix wrote:

 auto helps too.


 This remark was explicitly about _Java_ code style.


1/ We are not in the java's newsgroup.
2/ In java, the tooling is that awesome that you don't need to type most 
of it anyway.
Mar 09 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
  YOn 03/09/2012 09:12 AM, deadalnix wrote:

 Le 07/03/2012 11:08, Timon Gehr a crit :

 On 03/06/2012 10:30 PM, deadalnix wrote:

 auto helps too.


 This remark was explicitly about _Java_ code style.


 1/ We are not in the java's newsgroup.
 2/ In java, the tooling is that awesome that you don't need to type most
 of it anyway.


1/ We are not in the tooling's newsgroup.
2/ I am aware of that.
Mar 09 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
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.
Mar 06 2012
parent "foobar" <foo bar.com> writes:
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


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?
Mar 07 2012
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Mar 06 2012
parent "foobar" <foo bar.com> writes:
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.
Mar 07 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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 

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.
Mar 06 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Mar 06 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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"??
Mar 06 2012
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Mar 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Mar 06 2012
prev sibling next sibling parent reply Derek <ddparnell bigpond.com> writes:
On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe  
<destructionator gmail.com> wrote:


 Why aren't we using real words here? Real words are easier
 to remember and easier to type.


Should we use American or English spelling? Color verses Colour, for  
example?


-- 
Derek Parnell
Melbourne, Australia
Mar 06 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 6 March 2012 at 20:20:47 UTC, Derek wrote:

 Should we use American or English spelling? Color verses 
 Colour, for example?


I can go either way. I lean toward English spelling
though, simply because America is the exceptional
country (in the world and on the newsgroup too) in
this regard.

But, either option is better than "Clr" or "Col".
Mar 06 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:sgmfyzmrfygshlmfqsdj forum.dlang.org...

 On Tuesday, 6 March 2012 at 20:20:47 UTC, Derek wrote:

 Should we use American or English spelling? Color verses Colour, for 
 example?


 I can go either way. I lean toward English spelling
 though, simply because America is the exceptional
 country (in the world and on the newsgroup too) in
 this regard.


British English may be the more "official" English, with American English as 
a mere variation, but AIUI, the "de facto international language" is 
American English, not British English, as a result of the US being a 
long-time major economic superpower (for better or worse). England used to 
be a major superpower, but that was centuries ago, and from what I can tell, 
American English seems to be the preferred "de facto standard" English now.

'Course, I'm in the US, so I may simply be biased just because, as an 
american, I do,  for example, prefer "color" over "colour". (OTOH, I think 
the word "lorry" is awesome. Not sure if I spelled it right, though.)

Speaking of...do the British actually pronounce colour with a "u" sound? If 
not, I'd argue "color" really is a better spelling ;) (Not as good as 
"kulr", but whatever)


 But, either option is better than "Clr" or "Col".


"clr" is the verb "clear" and "col" is "column" :)
Mar 07 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Mar 07 2012
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 07/03/2012 19:03, H. S. Teoh wrote:
<snip>

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


<snip>

When I went to school, the _word_ "col" meant a mountain pass, not any of those
things.

Stewart.
Mar 07 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
Mar 07 2012
parent "Nick Sabalausky" <a a.a> writes:
"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.
Mar 07 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Wednesday, 7 March 2012 at 18:39:41 UTC, Nick Sabalausky wrote:

 "Adam D. Ruppe" <destructionator gmail.com> wrote in message
 news:sgmfyzmrfygshlmfqsdj forum.dlang.org...

 On Tuesday, 6 March 2012 at 20:20:47 UTC, Derek wrote:

 Should we use American or English spelling? Color verses 
 Colour, for example?


 I can go either way. I lean toward English spelling
 though, simply because America is the exceptional
 country (in the world and on the newsgroup too) in
 this regard.


 British English may be the more "official" English, with 
 American English as
 a mere variation, but AIUI, the "de facto international 
 language" is
 American English, not British English, as a result of the US 
 being a
 long-time major economic superpower (for better or worse). 
 England used to
 be a major superpower, but that was centuries ago, and from 
 what I can tell,
 American English seems to be the preferred "de facto standard" 
 English now.


 But, either option is better than "Clr" or "Col".


 "clr" is the verb "clear" and "col" is "column" :)


In my programs I use British English because that's what I use, 
and anything else looks 'wrong' to me. If the API is particularly 
public, I usually provide an alias. Then again, I'm just a 
colonial hick, so what would I know? :P
Mar 07 2012
prev sibling parent reply Derek <ddparnell bigpond.com> writes:
On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky <a a.a> wrote:



 British English may be the more "official" English, with American  
 English as a mere variation ...



In one sense, American English is often a sort of abbreviated version in  
which seemingly superfluous letters are omitted. But in other cases, it  
more accurately reflects pronunciation (colorize verses colourise).



 Speaking of...do the British actually pronounce colour with a "u" sound?  
 If
 not, I'd argue "color" really is a better spelling ;) (Not as good as
 "kulr", but whatever)


I'm not sure about British pronunciation (I'm Australian) but 'color' is  
said as "kull-ore' and 'colour' is said like 'kull-er' or even 'kull-ah'.

But my point, a part from being a bit whimsical, was that we can even have  
disagreements over fully spelt (spelled?) words let alone abbreviations  
(ironically that is word that *needs* shortening) so I think the criteria  
for publicly exposed function names should hinge on the consistency of  
naming conventions rather than focus on abbrv. vs. FullySpelledOutWords.

-- 
Derek Parnell
Melbourne, Australia
Mar 08 2012
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 08 Mar 2012 10:21:00 -0000, Derek <ddparnell bigpond.com> wrote:

 On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky <a a.a> wrote:



 British English may be the more "official" English, with American  
 English as a mere variation ...



 In one sense, American English is often a sort of abbreviated version in  
 which seemingly superfluous letters are omitted. But in other cases, it  
 more accurately reflects pronunciation (colorize verses colourise).


In Britain (where I live) there are people to pronounce the 'u' in colour,  
and colourise.  The difference is subtle, and I've found many people  
simply cannot hear it.  It's the reason many people (and the brash  
American tourist stereotype springs to mind - but there are people the  
world over) have trouble learning and speaking a foreign language, they  
cannot hear where they're going wrong (or they don't care - which is a  
different issue).  I think my own ear is able to hear some, perhaps a good  
number of the subtleties, for example it was good enough that a local  
Colombian thought I was myself Colombian after having spoken a few short  
(uncomplicated, as my Spanish is basic at best) sentences with them.


 Speaking of...do the British actually pronounce colour with a "u"  
 sound? If
 not, I'd argue "color" really is a better spelling ;) (Not as good as
 "kulr", but whatever)


 I'm not sure about British pronunciation (I'm Australian) but 'color' is  
 said as "kull-ore' and 'colour' is said like 'kull-er' or even 'kull-ah'.


This is why Australians and New Zealanders (myself) should not be asked  
how to pronounce words, our vowels are all either 'wrong' or missing  
completely. :p

Back to the main topic, being from NZ, where British English is the  
standard, I prefer it to American.  But, I can easily adapt to whichever  
is used in a body of code.

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Mar 08 2012
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 08/03/2012 11:04, Regan Heath wrote:

 On Thu, 08 Mar 2012 10:21:00 -0000, Derek <ddparnell bigpond.com> wrote:

 On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky <a a.a> wrote:


 British English may be the more "official" English, with American English as a
mere
 variation ...


 In one sense, American English is often a sort of abbreviated version in which
seemingly
 superfluous letters are omitted. But in other cases, it more accurately
reflects
 pronunciation (colorize verses colourise).




Indeed.  Sometimes the British spelling is more logical (judgement versus
judgment). 
Sometimes the American spelling is more logical (skeptical versus sceptical).


 In Britain (where I live) there are people to pronounce the 'u' in colour, and
colourise.
 The difference is subtle, and I've found many people simply cannot hear it.


<snip>

I'm finding it hard to figure how someone would pronounce the "o" and "u" in
"colour" 
separately.

But to me, it's just the same phoneme as found in most -er and -or words.

Stewart.
Mar 08 2012
parent reply James Miller <james aatch.net> writes:
On 9 March 2012 01:23, Stewart Gordon <smjg_1998 yahoo.com> wrote:

 On 08/03/2012 11:04, Regan Heath wrote:

 On Thu, 08 Mar 2012 10:21:00 -0000, Derek <ddparnell bigpond.com> wrote:

 On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky <a a.a> wrote:


 British English may be the more "official" English, with American
 English as a mere
 variation ...



 In one sense, American English is often a sort of abbreviated version i=






n

 which seemingly
 superfluous letters are omitted. But in other cases, it more accurately
 reflects
 pronunciation (colorize verses colourise).





 Indeed. =C2=A0Sometimes the British spelling is more logical (judgement v=


ersus

 judgment). Sometimes the American spelling is more logical (skeptical ver=


sus

 sceptical).


 In Britain (where I live) there are people to pronounce the 'u' in colou=




r,

 and colourise.
 The difference is subtle, and I've found many people simply cannot hear
 it.


 <snip>

 I'm finding it hard to figure how someone would pronounce the "o" and "u"=


 in

 "colour" separately.

 But to me, it's just the same phoneme as found in most -er and -or words.

 Stewart.


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!

--
James Miller
Mar 08 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"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).
Mar 08 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 01:55:45PM -0500, Nick Sabalausky wrote:

 "James Miller" <james aatch.net> wrote in message 
 news:mailman.235.1331210469.4860.digitalmars-d puremagic.com...


[...]

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.


I couldn't agree more! When I first started learning Russian, I simply
could not hear the difference between И and Ы. At all. They sounded
identical to me. Or rather, I notice there's a difference when a native
speaker says both sounds, but I couldn't pinpoint what that difference
was, nor could I reproduce the sounds, or distinguish between them when
heard in isolation. It took a lot of research to find out exactly how to
pronounce Ы (И is relatively easy), and a lot of effort to learn how to
tell them apart in different contexts, before I started "hearing" the
difference.

Now I was somewhat lucky that my mother tongue distinguishes between an
aspirated T (the T at the beginning of an English word) and a
non-aspirated T (the Russian Т, or, for that matter, the Spanish T). So
I had no trouble pronouncing the Russian T correctly, but another guy
who was also learning Russian couldn't tell the difference, and as a
result always spoke with a heavy "foreigner accent".

I can't say I've mastered it all, though... one thing that still throws
me off is Л and ЛЬ right before a consonant. I can do it right if a
vowel immediately follows, but I have a lot of trouble if ЛЬ is followed
by a consonant. I couldn't hear the difference at all. Now I can
somewhat tell, but I still slip up all the time when I try to pronounce
it myself.

Another thing is, I can't roll my R's. My tongue as stiff as a stick and
just refuses to roll anything, no matter how hard I try. I've tried to
follow online tutorials, but it just doesn't work for me. :-(


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind
should be open at both ends, like the food-pipe, with the capacity for
excretion as well as absorption. -- Northrop Frye
Mar 08 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 08/03/2012 19:29, H. S. Teoh wrote:
<snip>

 Another thing is, I can't roll my R's. My tongue as stiff as a stick and
 just refuses to roll anything, no matter how hard I try.


<snip>

I can't roll my tongue either.  I'm told it's genetic. :)

But anyway, to me, rolling Rs seems pretentious....

Stewart.
Mar 08 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 10:29:05PM +0000, Stewart Gordon wrote:

 On 08/03/2012 19:29, H. S. Teoh wrote:
 <snip>

Another thing is, I can't roll my R's. My tongue as stiff as a stick
and just refuses to roll anything, no matter how hard I try.


 <snip>
 
 I can't roll my tongue either.  I'm told it's genetic. :)
 
 But anyway, to me, rolling Rs seems pretentious....


[...]

Well, it's pretentious in English, but quite mellifluous in Russian. :-)
Though I'm told that even for native Russian speakers, it's one of the
last sounds acquired, so it must be pretty difficult. (And to make
things worse, they have *two* rolled R's, one palatized, one not. As if
one R isn't hard enough already.)


T

-- 
Doubt is a self-fulfilling prophecy.
Mar 08 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.270.1331248862.4860.digitalmars-d puremagic.com...

 On Thu, Mar 08, 2012 at 10:29:05PM +0000, Stewart Gordon wrote:

 On 08/03/2012 19:29, H. S. Teoh wrote:
 <snip>

Another thing is, I can't roll my R's. My tongue as stiff as a stick
and just refuses to roll anything, no matter how hard I try.


 <snip>

 I can't roll my tongue either.  I'm told it's genetic. :)

 But anyway, to me, rolling Rs seems pretentious....


 [...]

 Well, it's pretentious in English, but quite mellifluous in Russian. :-)
 Though I'm told that even for native Russian speakers, it's one of the
 last sounds acquired, so it must be pretty difficult. (And to make
 things worse, they have *two* rolled R's, one palatized, one not. As if
 one R isn't hard enough already.)


R in general is a very difficult sound no matter what variation of R. In 
native English countries, R is one of the most (if not the most) common 
sounds for kids to have touble with.
Mar 08 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 06:30:05PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.270.1331248862.4860.digitalmars-d puremagic.com...

 On Thu, Mar 08, 2012 at 10:29:05PM +0000, Stewart Gordon wrote:




[...]

 But anyway, to me, rolling Rs seems pretentious....


 [...]

 Well, it's pretentious in English, but quite mellifluous in Russian.
 :-) Though I'm told that even for native Russian speakers, it's one
 of the last sounds acquired, so it must be pretty difficult. (And to
 make things worse, they have *two* rolled R's, one palatized, one
 not. As if one R isn't hard enough already.)


 
 R in general is a very difficult sound no matter what variation of R.
 In native English countries, R is one of the most (if not the most)
 common sounds for kids to have touble with.


                                 ^^^^^^
                            ahh, the irony :-)
			    I mean, iony.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees
and try again."
Mar 08 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:jjbbrn$2o1n$1 digitalmars.com...

 On 08/03/2012 19:29, H. S. Teoh wrote:
 <snip>

 Another thing is, I can't roll my R's. My tongue as stiff as a stick and
 just refuses to roll anything, no matter how hard I try.


 <snip>

 I can't roll my tongue either.  I'm told it's genetic. :)


I couldn't pronounce R at all until I was taught it sometime around third or 
fourth grade (Interestingly, I didn't even know that I couldn't pronounce 
it). When I was learning it, rolling the R was the *only* way I could 
pronounce R. Once I learned to speak a non-rolled R, I completely *lost* the 
ability to roll my R's. Fast-foward many years until now, and I can *kinda* 
roll them.

Anyway, I just always thought that was weird.


 But anyway, to me, rolling Rs seems pretentious....


It seems Spanish to me ;) "Get your yappy 'perro' off my leg!"
Mar 08 2012
parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 08 Mar 2012 23:27:18 -0000, Nick Sabalausky <a a.a> wrote:

 But anyway, to me, rolling Rs seems pretentious....


 It seems Spanish to me ;) "Get your yappy 'perro' off my leg!"


LOL :)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Mar 09 2012
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 08/03/2012 18:55, Nick Sabalausky wrote:
<snip>

 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.


Yes, it seems that people's ears are tailored to the language they speak.  But
then again, 
even native English speakers have trouble with sounds that are distinguished by
others; a 
consequence is that the distinction between the "w" and "wh" sounds has largely
been lost.

On the Royal Institution Christmas Lectures last year, there was a bit on
speech 
perception.  Two sound samples both sounded like "duck" to typical English
ears, but the 
Hindi speaker in the audience heard them to be different (it's probably down to 
short-breath and long-breath consonants, which we would transliterate as "d"
and "dh").

<snip>

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


Indeed.  But English speakers aren't used "ts" occurring at the beginning of a
word, and 
so might drop either the "t" or the "s".  There are a number of initial
consonant clusters 
in African languages that, likewise, occur only in the middle or at the end of
a word in 
English, and so an English speaker will find these African words hard to
pronounce.

Stewart.
Mar 08 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jjavf2$1v3p$1 digitalmars.com...

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


Out of curiosity, I just asked her about this and she said that "hearing" it 
*does* typically come first, so I guess I was wrong about that. But she did 
say that failing that, yea, bringing in instruction on the mouth movements 
can be a reasonable next step as it brings other senses into play.
Mar 08 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 06:45:34PM -0500, Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:jjavf2$1v3p$1 digitalmars.com...


[...]

 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.


 
 Out of curiosity, I just asked her about this and she said that
 "hearing" it *does* typically come first, so I guess I was wrong about
 that. But she did say that failing that, yea, bringing in instruction
 on the mouth movements can be a reasonable next step as it brings
 other senses into play.


[...]

The problem with learning by 'hearing' is that, past a certain age, you
lose the sensitivity to certain sound distinctions that are not present
in your mother tongue. I suppose it's a sort of instinctive
"optimization" done by your brain: if a certain set of sound differences
don't matter, then there's no need to retain the extra resources to
distinguish between them. Lump them all together and treat them as the
same sound for higher efficiency.

English speakers trying to learn Chinese, for example, have an
incredible difficulty in hearing the "tones" -- because there is simply
not such a distinction made in English that saying something in a
different tone can *completely* change the meaning. Korean speakers
learning English, OTOH, have the hardest time telling the difference
between "fork" and "pork" -- because in Korean, "p" and "f" are not
distinguished. They just don't hear it, or if they do, they can't
reliably reproduce it. (Makes for hilarious dinner conversations --
"please pass the [fp]ork".)


T

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth? -- Michael Beibl
Mar 08 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.278.1331251506.4860.digitalmars-d puremagic.com...

 The problem with learning by 'hearing' is that, past a certain age, you
 lose the sensitivity to certain sound distinctions that are not present
 in your mother tongue. I suppose it's a sort of instinctive
 "optimization" done by your brain: if a certain set of sound differences
 don't matter, then there's no need to retain the extra resources to
 distinguish between them. Lump them all together and treat them as the
 same sound for higher efficiency.


Hmm, I don't doubt that theory.


 English speakers trying to learn Chinese, for example, have an
 incredible difficulty in hearing the "tones" -- because there is simply
 not such a distinction made in English that saying something in a
 different tone can *completely* change the meaning.


I've heared that in countries like China which have a tonal language, the 
percentage of people with "perfect pitch" is incredibly high - something 
like 90-99%. Whereas in other places, like the US, it's *way* below half the 
population (something like 10%, IIRC).


 Korean speakers
 learning English, OTOH, have the hardest time telling the difference
 between "fork" and "pork" -- because in Korean, "p" and "f" are not
 distinguished. They just don't hear it, or if they do, they can't
 reliably reproduce it. (Makes for hilarious dinner conversations --
 "please pass the [fp]ork".)


Fun :)
Mar 08 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 07:14:30PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.278.1331251506.4860.digitalmars-d puremagic.com...


[...]

 I've heared that in countries like China which have a tonal language,
 the percentage of people with "perfect pitch" is incredibly high -
 something like 90-99%. Whereas in other places, like the US, it's
 *way* below half the population (something like 10%, IIRC).


[...]

I'm not sure if there's a direct correlation though... because Chinese
tones are not pitch-perfect; they are relative to a reference pitch
which differs from person to person.


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC
Mar 08 2012
prev sibling next sibling parent reply James Miller <james aatch.net> writes:
On 9 March 2012 12:45, Nick Sabalausky <a a.a> wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:jjavf2$1v3p$1 digitalmars.com...

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


 Out of curiosity, I just asked her about this and she said that "hearing" it
 *does* typically come first, so I guess I was wrong about that. But she did
 say that failing that, yea, bringing in instruction on the mouth movements
 can be a reasonable next step as it brings other senses into play.



For a university project, I had to do a group assignment building a
psycholinguistic demo platform for a textbook. While it was more
focused on how the brain interprets language (very interesting in
itself), we spent a lot of time talking to a linguistics professor,
and he can produce the strangest sounds! I assume its because he's
studied how these sounds get made so well that he can make them
himself, despite not speaking the languages the sounds originate from.

--
James Miller
Mar 08 2012
parent "Nick Sabalausky" <a a.a> writes:
"James Miller" <james aatch.net> wrote in message 
news:mailman.282.1331251951.4860.digitalmars-d puremagic.com...

 For a university project, I had to do a group assignment building a
 psycholinguistic demo platform for a textbook. While it was more
 focused on how the brain interprets language (very interesting in
 itself), we spent a lot of time talking to a linguistics professor,
 and he can produce the strangest sounds!


lol, I love how you worded that :)

Speaking of strange human-produced [vocal] sounds, I've always wished I 
could do *half* of what Michael Winslow can do ( 
http://en.wikipedia.org/wiki/Michael_Winslow ).
Mar 08 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 09, 2012 at 01:12:20PM +1300, James Miller wrote:
[...]

 For a university project, I had to do a group assignment building a
 psycholinguistic demo platform for a textbook. While it was more
 focused on how the brain interprets language (very interesting in
 itself), we spent a lot of time talking to a linguistics professor,
 and he can produce the strangest sounds! I assume its because he's
 studied how these sounds get made so well that he can make them
 himself, despite not speaking the languages the sounds originate from.


[...]

I know someone who is studying linguistics, and she told us that in one
phonology class, they were taught how to make all kinds of strange
sounds. I assume that must be part and parcel of being a linguist. :-)


T

-- 
It's amazing how careful choice of punctuation can leave you hanging:
Mar 08 2012
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
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).

If we went to the effort of re-spelling words to match how they were 
spoken, then we would just end up with multiple accepted spellings (and 
some new letters), or a nation of 1920s radio newscasters, neither of 
which appeals to me. As it is, the archaic spellings help to make words 
more visually distinct, after all, we have some words that are spoken 
the same but spelled differently (and vice versa >< ).

As for identifiers and abbreviations, as long as they are sufficiently 
visually distinct, I'd be happy. I tolerate USian spellings as much as 
non-English speaking programmers do, because I see it as an accepted 
"Programmer's English".

Secondly, D has its "the obvious solution is the right solution" 
philosophy. so the "right" identifiers should also be the obvious ones, 
but they should also be short especially when used frequently. Longer 
identifiers should be used sparingly, but are useful to convey 
subtleties such as different side effects and of course, to make 
non-safe code stand out.

A...
Mar 08 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Mar 08 2012
parent reply Matt Soucy <msoucy csh.rit.edu> writes:
On 03/08/2012 02:13 PM, Nick Sabalausky wrote:

 "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 recall my theater director telling me that the closest modern dialect 
to "Shakespearean English" was somewhere near the south side of the 
state of New York...not sure how much truth there is to that, but it's a 
cool idea.
Regional dialects are definitely a thing in the US, but I agree that 
they're not always noticeable...unless you find just the right words for 
someone to say that accent their pronunciation, like the classic "pahk 
the cah in hahvahd yahd" that goes with a Bostonian accent.


 I tolerate USian spellings


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


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


 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.


To be honest, I've occasionally wondered why there aren't any (commonly 
used) programming languages using other human languages as bases. I 
mean, English doesn't exactly have the nicest syntax ever...USian here, 
though.
Mar 08 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Matt Soucy" <msoucy csh.rit.edu> wrote in message 
news:jjb75b$2en4$1 digitalmars.com...

 I recall my theater director telling me that the closest modern dialect to 
 "Shakespearean English" was somewhere near the south side of the state of 
 New York...not sure how much truth there is to that, but it's a cool idea.


Interesting. And amusingly ironic.


 Regional dialects are definitely a thing in the US, but I agree that 
 they're not always noticeable...unless you find just the right words for 
 someone to say that accent their pronunciation, like the classic "pahk the 
 cah in hahvahd yahd" that goes with a Bostonian accent.


My dad's mother is from Pittsburgh, and both of them talk in "normal" US 
English until they say something like "wash" which will come out as either 
"wush", "warsh" or occasionally "wursh" (although after my occasional 
teasing, they've both been getting better :( ).


 I tolerate USian spellings


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


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


Yea, that's why I always give in and use the word "American" even though it 
kinda makes me cringe sometimes.


 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.


 To be honest, I've occasionally wondered why there aren't any (commonly 
 used) programming languages using other human languages as bases. I mean, 
 English doesn't exactly have the nicest syntax ever...USian here, though.


I'm sure it's because much of computer history is heavily rooted in the US.

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.
Mar 08 2012
next sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 09.03.2012, 01:07 Uhr, schrieb Nick Sabalausky <a a.a>:


 But yea, it would be interesting to see a langauge that was based on
 something very different. A German-based one would be fun.


Has been done: http://www.ph-ludwigsburg.de/fileadmin/subsites/2e-imix-t=
-01/user_files/logo/befehld.pdf
(A beginner's language that evolved around "turtle graphics")


 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.


You are free too use Hebrew, Cyrillic or Arabic characters for your iden=
tifiers right now. Only the keywords and druntime/Phobos would remain En=
glish:

	int main()
	{
		int =D8=A7=D9=84=D8=B9=D8=B1=D8=A8=D9=8A=D8=A9 =3D 42; // <- I really =
love this mind-fuck !!!
		return =D8=A7=D9=84=D8=B9=D8=B1=D8=A8=D9=8A=D8=A9;
	}


 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.
Mar 08 2012
parent "Nick Sabalausky" <a a.a> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:op.wavn0e059y6py2 marco-leise.homedns.org...

You are free too use Hebrew, Cyrillic or Arabic characters for your
identifiers right now. Only the keywords and druntime/Phobos
would remain English:

int main()
{
int ??????? = 42; // <- I really love this mind-fuck !!!
return ???????;
}


Yea, I love that about D.
Mar 08 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 07:07:04PM -0500, 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.


[...]

You *do* realize that D allows non-Latin characters for identifiers,
right? With suitable use of alias, you could write some really funky
code:

	import std.stdio;
	alias std.stdio.writeln показать;
	alias size_t размер;
	alias string строка;
	alias void пустой;

	размер количество(Тип)(Тип[] массив) {
		return массив.length;
	}

	пустой main(строка[] параметров) {
		размер к = количество(параметров);
		показать("Я получил ", к, " параметров из
командой строки");
	}

(Pity D doesn't let you alias keywords, else you could get rid of
"return" and "main" too. :-P)

However, this is only the lexical aspect of things. The grammar is still
essentially inherited from C, which inherited from a primarily
English-speaking tradition. So the above code is still rather awkward
because many nouns are in the wrong case.

We can do better. What about a language that has inflections, like Greek
or Russian? Function calls can then be indicated by putting the function
name (verb) in imperative mood, whereas using the function name in
nominative case (gerund) turns it into a function pointer.  Variables
(nouns) can have nominative case to indicate the object a particular
method should be invoked on, and accusative case for other parameters.

Now of course, to keep things manageable (and consistent), we'll have to
eliminate the nasty complicated special-cases, spelling exceptions, and
all that stuff that we find in natural languages. All word endings are
universally applied, and must all be unambiguous.  Furthermore, most of
human language is descriptive, whereas in a programming language,
especially an imperative one, you'd want to be using imperatives almost
all the time. So some natural language features won't be very useful.

So what we want is to identify common functionality that programming
languages need, and encode those in our "verbs" and "nouns". Here's my
first stab at it:

- Verbs represent functions, and can have an imperative form (function
  call), a gerund form (function pointer/delegate), or an indicative
  form (function declaration).

- Nouns represent variables, and can have a nominative form (variable
  declaration), an instrumental form (indicating the object a method is
  invoked from), a genitive form (indicating data source, i.e. "in" in
  D), a dative form (indicating data sink, or "out" in D), an accusative
  form (generic parameter), or a construct form (member access).

- Furthermore, plural nouns represent arrays, and have their own set of
  endings for nominative, instrumental, genitive, dative, accusative.
  (So you get array notation for free, no need for special symbols.)

- Adjectives represent types, and agree with the modified noun in case
  and number, so they can appear anywhere in a command without
  ambiguity, even separated from the modified noun proper. Adjectives
  have no construct form.

Here's an arbitrary assignment of endings to word forms, just for
illustration's sake:

	Imperative verb:	-ize
	Gerundive verb:		-ing
	Indicative verb:	-ation

			Nouns		Adjectives
			sg	pl	sg	pl
	Nominative:	-on	-ons	-dic	-tic
	Instrumental:	-ect	-ects	-oid	-idic
	Genitive:	-in	-ins	-nous	-rous
	Dative:		-out	-outs	-ny	-ney
	Accusative:	-or	-ors	-like	-ive
	Construct:	-'s	-s'

Some grammatical particles we might need:

	is		Introduces function body
	;		Separates statements
	.		Ends function body

So here's some sample code. For illustration purposes I'm just
transliterating D keywords, though in an actual implementation of such a
language you'd want language-specific words instead.

	stringtic truncation stringrous arrayins is
		returnize arrays' 1..$ons

	intdic maination stringtic argumentors is
		intdic lenon arguments' lengthin;
		writelnize stdoutout lenor;
		writelnize stdoutout truncize argumentors;
		returnize 0or.

Here's the equivalent D code:

	string[] trunc(string[] array) {
		return array[1..$];
	}
	int main(string[] argument) {
		int len = argument.length;
		stdout.writeln(len);
		stdout.writeln(trunc(argument));
	}

Note that word order is relatively free, because word endings make the
function of each word unambiguous. So the above code could be written
like this instead:

	stringtic stringrous arrayins truncation is
		1..$ons arrays' returnize

	intdic maination stringtic argumentors is
		intdic lenon lengthin arguments';
		lenor stdoutout writelnize;
		stdoutout writelnize truncize argumentors;
		0or returnize.

OK, this sounds like a horrendous butchering of English, but imagine if
the root words were non-English, and the endings weren't butcherings of
English endings. You'd have a really unique language with almost free
word order.

Or, if spelt-out endings are too annoying to type, we can use symbols
instead, like this:

	stdout> writeln! arguments<


T

-- 
Creativity is not an excuse for sloppiness.
Mar 08 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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

-- 
They say that "guns don't kill people, people kill people." Well I think
the gun helps. If you just stood there and yelled BANG, I don't think
you'd kill too many people. -- Eddie Izzard, Dressed to Kill
Mar 08 2012
parent Don Clugston <dac nospam.com> writes:
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().
Mar 09 2012
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
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...
Mar 09 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Alix Pexton" <alix.DOT.pexton gmail.DOT.com> wrote in message 
news:jjcn41$2g4g$1 digitalmars.com...

 and I have a theory that poetic languages would be good for programming 
 in.


http://shakespearelang.sourceforge.net/

Hello World: 
http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello
Mar 09 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 09, 2012 at 01:29:03PM -0500, Nick Sabalausky wrote:

 "Alix Pexton" <alix.DOT.pexton gmail.DOT.com> wrote in message 
 news:jjcn41$2g4g$1 digitalmars.com...

 and I have a theory that poetic languages would be good for programming 
 in.


 
 http://shakespearelang.sourceforge.net/
 
 Hello World: 
 http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello


[...]

+1. I've seen that one before, but it cracks me up every time. Using
insults to represent negative numbers and praises to represent positive
numbers is just hilarious.

What would be really funny is if you wrote an actual play (with actual
plot and dramatic buildup) that also does something useful.


T

-- 
If you think you are too small to make a difference, try sleeping in a closed
room with a mosquito. -- Jan van Steenbergen
Mar 09 2012
prev sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 09/03/2012 18:29, Nick Sabalausky wrote:

 "Alix Pexton"<alix.DOT.pexton gmail.DOT.com>  wrote in message
 news:jjcn41$2g4g$1 digitalmars.com...

 and I have a theory that poetic languages would be good for programming
 in.


 http://shakespearelang.sourceforge.net/

 Hello World:
 http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello


Not quite what I had in mind, but still amusing ^^

A...
Mar 09 2012
prev sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
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...
Mar 09 2012
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Derek" <ddparnell bigpond.com> wrote in message 
news:op.warmsnem34mv3i red-beast...

 On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe 
 <destructionator gmail.com> wrote:


 Why aren't we using real words here? Real words are easier
 to remember and easier to type.


 Should we use American or English spelling? Color verses Colour, for 
 example?


 -- 
 Derek Parnell
 Melbourne, Australia


American.  Always.
Mar 06 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 07.03.2012, 07:17 Uhr, schrieb Daniel Murphy <yebblies nospamgmail.com>:


 "Derek" <ddparnell bigpond.com> wrote in message
 news:op.warmsnem34mv3i red-beast...

 On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe
 <destructionator gmail.com> wrote:


 Why aren't we using real words here? Real words are easier
 to remember and easier to type.


 Should we use American or English spelling? Color verses Colour, for
 example?


 --
 Derek Parnell
 Melbourne, Australia


 American.  Always.


Whatever Java uses.
Mar 07 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 07.03.2012, 15:17 Uhr, schrieb Marco Leise <Marco.Leise gmx.de>:


 Am 07.03.2012, 07:17 Uhr, schrieb Daniel Murphy <yebblies nospamgmail.com>:


 "Derek" <ddparnell bigpond.com> wrote in message
 news:op.warmsnem34mv3i red-beast...

 On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe
 <destructionator gmail.com> wrote:


 Why aren't we using real words here? Real words are easier
 to remember and easier to type.


 Should we use American or English spelling? Color verses Colour, for
 example?


 --
 Derek Parnell
 Melbourne, Australia


 American.  Always.


 Whatever Java uses.


Ok, that *was* a bad idea: http://en.wikipedia.org/wiki/Java#Languages
Mar 08 2012
parent "Nick Sabalausky" <a a.a> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:op.wave6bo49y6py2 marco-leise.homedns.org...

 Am 07.03.2012, 15:17 Uhr, schrieb Marco Leise <Marco.Leise gmx.de>:


 Am 07.03.2012, 07:17 Uhr, schrieb Daniel Murphy 
 <yebblies nospamgmail.com>:


 "Derek" <ddparnell bigpond.com> wrote in message
 news:op.warmsnem34mv3i red-beast...

 On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe
 <destructionator gmail.com> wrote:


 Why aren't we using real words here? Real words are easier
 to remember and easier to type.


 Should we use American or English spelling? Color verses Colour, for
 example?


 --
 Derek Parnell
 Melbourne, Australia


 American.  Always.


 Whatever Java uses.


 Ok, that *was* a bad idea: http://en.wikipedia.org/wiki/Java#Languages


What, you don't think that'd be fun? :)
Mar 08 2012
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 06/03/2012 20:20, Derek wrote:
<snip>

 Should we use American or English spelling? Color verses Colour, for example?


Make one an alias of the other.

Stewart.
Mar 07 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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.

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.

Symbol names should be descriptive while still being as short as they can 
reasonably be without losing meaning.

- Jonathan M Davis
Mar 06 2012
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
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.


 Symbol names should be descriptive while still being as short as they can
 reasonably be without losing meaning.

 - Jonathan M Davis
Mar 06 2012
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
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)
Mar 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-03-07 01:01, Ary Manzana wrote:

 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)


Yeah, time and dates are ridicules easy in Ruby with active support. Say 
I want the date from two weeks ago, I just say that:

a = 2.weeks.ago

Super easy.

-- 
/Jacob Carlborg
Mar 07 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Mar 06 2012
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
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.


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.
Mar 07 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jj94mb$1i7v$1 digitalmars.com...

 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]}]


When you format it like that (that is to say, when you *don't* format it), 
yea, it's unreadable. Which is why I do such things like this:

parent_ids =
    results
    .map{|x| x['_source']['parent_ids']}
    .flatten.uniq
    .compactHash[
        Site.find(parent_ids).map{|x| [x.id, x]}
    ]
Mar 07 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:

 "Ary Manzana" <ary esperanto.org.ar> wrote in message
 news:jj94mb$1i7v$1 digitalmars.com...
 

 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]}]


 
 When you format it like that (that is to say, when you *don't* format it),
 yea, it's unreadable. Which is why I do such things like this:
 
 parent_ids =
     results
     .map{|x| x['_source']['parent_ids']}
     .flatten.uniq
     .compactHash[
         Site.find(parent_ids).map{|x| [x.id, x]}
     ]


I actually tend to find code like that hard to read, because all of the 
operations are inside out in comparison to normal. But since the only 
difference between his example and yours is the formatting, I agree yours is 
easier to read. Still, I'd much prefer if such code didn't use UFCS, since I 
find it much harder to read that way. It's just so backwards.

- Jonathan M Davis
Mar 07 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.214.1331187413.4860.digitalmars-d puremagic.com...

 On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:

 "Ary Manzana" <ary esperanto.org.ar> wrote in message
 news:jj94mb$1i7v$1 digitalmars.com...


 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]}]


 When you format it like that (that is to say, when you *don't* format 
 it),
 yea, it's unreadable. Which is why I do such things like this:

 parent_ids =
     results
     .map{|x| x['_source']['parent_ids']}
     .flatten.uniq
     .compactHash[
         Site.find(parent_ids).map{|x| [x.id, x]}
     ]


 I actually tend to find code like that hard to read, because all of the
 operations are inside out in comparison to normal. But since the only
 difference between his example and yours is the formatting, I agree yours 
 is
 easier to read. Still, I'd much prefer if such code didn't use UFCS, since 
 I
 find it much harder to read that way. It's just so backwards.


Aside from the problems of excess paren nesting, I tend to think this is 
backwards:

foo(bar(baz(x+2)))

...because the order it's read/written is the complete opposite of the order 
of exectution. First "x+2" is evaluated, then "baz", then "bar", then "foo". 
Ie, it's executed right-to-left even though you read/write it left-to-right. 
Completely backwards. Contrast that with:

(x+2).baz().bar().foo()

...which we may be less accustomed to (unless you think of it like bash 
piping), but in addition to the decrease in nesting, it's written and read 
in the *same* order as exection: left to right. This also means that it's no 
longer the complete reverse of statements which are (sensibly) 
left-to-right:

y = x+2; baz(); bar(); foo();

If I were writing code in Arabic, I would probably like 
"foo(bar(baz(x+2)))". (I would also wonder "What a minute, when did I learn 
Arabic? How did I manage to learn a langauge without even knowing? This is 
really weird! But fun. Wheee!!")
Mar 08 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 04:26:11 Nick Sabalausky wrote:

 Aside from the problems of excess paren nesting, I tend to think this is
 backwards:
 
 foo(bar(baz(x+2)))


Yes, but that's how functions normally work, so flipping it around _is_ 
backwards from the normal, even if some people find it easier to understand. 
And I've written enough in functional languages that flipping it around just 
seems _really_ backwards to me. At this point, I always have a harder time 
reading code when someone insists on chaining UFCS calls rather than using 
normal function calls. But obviously YMMV.

- Jonathan M Davis
Mar 08 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 08/03/2012 07:15, Jonathan M Davis a écrit :

 On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:

 "Ary Manzana"<ary esperanto.org.ar>  wrote in message
 news:jj94mb$1i7v$1 digitalmars.com...


 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]}]


 When you format it like that (that is to say, when you *don't* format it),
 yea, it's unreadable. Which is why I do such things like this:

 parent_ids =
      results
      .map{|x| x['_source']['parent_ids']}
      .flatten.uniq
      .compactHash[
          Site.find(parent_ids).map{|x| [x.id, x]}
      ]


 I actually tend to find code like that hard to read, because all of the
 operations are inside out in comparison to normal. But since the only
 difference between his example and yours is the formatting, I agree yours is
 easier to read. Still, I'd much prefer if such code didn't use UFCS, since I
 find it much harder to read that way. It's just so backwards.

 - Jonathan M Davis


You got tricked by your experience. You are used to read backward. The 
function are written in the order they are executed in the example 
above. This isn't very traditional, and may be the reverse order of what 
people expect due to previous experience, but definitively is the 
forward way.
Mar 08 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 11:54:21PM +0100, deadalnix wrote:

 Le 08/03/2012 07:15, Jonathan M Davis a écrit :

On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:

"Ary Manzana"<ary esperanto.org.ar>  wrote in message
news:jj94mb$1i7v$1 digitalmars.com...






[...]

parent_ids =
     results
     .map{|x| x['_source']['parent_ids']}
     .flatten.uniq
     .compactHash[
         Site.find(parent_ids).map{|x| [x.id, x]}
     ]


I actually tend to find code like that hard to read, because all of
the operations are inside out in comparison to normal. But since the
only difference between his example and yours is the formatting, I
agree yours is easier to read. Still, I'd much prefer if such code
didn't use UFCS, since I find it much harder to read that way. It's
just so backwards.

- Jonathan M Davis


 
 You got tricked by your experience. You are used to read backward.
 The function are written in the order they are executed in the example
 above. This isn't very traditional, and may be the reverse order of
 what people expect due to previous experience, but definitively is the
 forward way.


Yeah, modern function composition syntax is totally backwards. This is
most obvious when you use the f∘g notation in math. It means f(g), that
is, apply g first, then f. So if you use this notation in functional
programming, writing something like a∘b∘c∘d∘e∘f means run steps a..f
*backwards*. Written on multiple lines, it totally goes against the flow
of control. It's the programming language version of top-posting. ;-)

Unfortunately, the alternative is reverse Polish notation, which isn't
all that readable either.

Chained object notation is a good compromise, which happens quite often
when you use jQuery:

	$(selector)
		.html(htmlcode)
		.add(more_nodes)
		.css(some_styles)
		.filter(unwanted_nodes)
		.click(click_handler)
		.show();

Writing this in function composition order would cause an instant
quantum leap in unreadability.


T

-- 
I see that you JS got Bach.
Mar 08 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.275.1331250663.4860.digitalmars-d puremagic.com...

 On Thu, Mar 08, 2012 at 11:54:21PM +0100, deadalnix wrote:

 Le 08/03/2012 07:15, Jonathan M Davis a crit :

On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:

"Ary Manzana"<ary esperanto.org.ar>  wrote in message
news:jj94mb$1i7v$1 digitalmars.com...






 [...]

parent_ids =
     results
     .map{|x| x['_source']['parent_ids']}
     .flatten.uniq
     .compactHash[
         Site.find(parent_ids).map{|x| [x.id, x]}
     ]


I actually tend to find code like that hard to read, because all of
the operations are inside out in comparison to normal. But since the
only difference between his example and yours is the formatting, I
agree yours is easier to read. Still, I'd much prefer if such code
didn't use UFCS, since I find it much harder to read that way. It's
just so backwards.

- Jonathan M Davis


 You got tricked by your experience. You are used to read backward.
 The function are written in the order they are executed in the example
 above. This isn't very traditional, and may be the reverse order of
 what people expect due to previous experience, but definitively is the
 forward way.


 Yeah, modern function composition syntax is totally backwards. This is
 most obvious when you use the f?g notation in math. It means f(g), that
 is, apply g first, then f. So if you use this notation in functional
 programming, writing something like a?b?c?d?e?f means run steps a..f
 *backwards*. Written on multiple lines, it totally goes against the flow
 of control.


That's why I'll always use std.functional.pipe instead of 
std.functional.compose. (Though if my math background was stronger than my 
programming backgroud, I'd probably prefer std.functional.compose)


It's the programming language version of top-posting. ;-)


Forth using like just It's.


 Unfortunately, the alternative is reverse Polish notation, which isn't
 all that readable either.


My Calculus class in high-school uses a graphing calculator that used 
reverse polish notation. I had less trouble with it than some of the 
students because of my programming background and prior understanding of 
stacks. But boy did it still seem goofy. I like the TI's so much better.


 Chained object notation is a good compromise, which happens quite often
 when you use jQuery:

 $(selector)
 .html(htmlcode)
 .add(more_nodes)
 .css(some_styles)
 .filter(unwanted_nodes)
 .click(click_handler)
 .show();

 Writing this in function composition order would cause an instant
 quantum leap in unreadability.


Ziggy says there's an 80% chance you're here to decrease excess parenthesis 
nesting and set straight what once went backwards.
Mar 08 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 15:52:37 H. S. Teoh wrote:

 Yeah, modern function composition syntax is totally backwards. This is
 most obvious when you use the f∘g notation in math. It means f(g), that
 is, apply g first, then f. So if you use this notation in functional
 programming, writing something like a∘b∘c∘d∘e∘f means run steps a..f
 *backwards*. Written on multiple lines, it totally goes against the flow
 of control. It's the programming language version of top-posting. ;-)
 
 Unfortunately, the alternative is reverse Polish notation, which isn't
 all that readable either.
 
 Chained object notation is a good compromise, which happens quite often
 when you use jQuery:
 
 $(selector)
 .html(htmlcode)
 .add(more_nodes)
 .css(some_styles)
 .filter(unwanted_nodes)
 .click(click_handler)
 .show();
 
 Writing this in function composition order would cause an instant
 quantum leap in unreadability.


Which just goes to show that it's also a question of what you're used to, 
because I find that using the order that you did here rather than normal 
function call chaining is what causes an instance quantum leap in 
unreadibility.

- Jonathan M Davis
Mar 08 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 23:54:21 deadalnix wrote:

 Le 08/03/2012 07:15, Jonathan M Davis a écrit :

 On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:

 "Ary Manzana"<ary esperanto.org.ar> wrote in message
 news:jj94mb$1i7v$1 digitalmars.com...
 

 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]}]


 
 When you format it like that (that is to say, when you *don't* format
 it),
 yea, it's unreadable. Which is why I do such things like this:
 
 parent_ids =
 
 results
 .map{|x| x['_source']['parent_ids']}
 .flatten.uniq
 .compactHash[
 
 Site.find(parent_ids).map{|x| [x.id, x]}
 
 ]


 
 I actually tend to find code like that hard to read, because all of the
 operations are inside out in comparison to normal. But since the only
 difference between his example and yours is the formatting, I agree yours
 is easier to read. Still, I'd much prefer if such code didn't use UFCS,
 since I find it much harder to read that way. It's just so backwards.
 
 - Jonathan M Davis


 
 You got tricked by your experience. You are used to read backward. The
 function are written in the order they are executed in the example
 above. This isn't very traditional, and may be the reverse order of what
 people expect due to previous experience, but definitively is the
 forward way.


I mean that it is backwards from what is normal. The result of that is that I 
find it harder to read. So yes, you could say that it's executing "forward," 
since the functions are executed from left-to-right instead of right-to-left, 
but regardless, it's backwards from what is normal and therefore feels very 
backwards to me, which is my point.

- Jonathan M Davis
Mar 08 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 07:07:49PM -0500, Jonathan M Davis wrote:

 On Thursday, March 08, 2012 15:52:37 H. S. Teoh wrote:


[...]

 $(selector)
 .html(htmlcode)
 .add(more_nodes)
 .css(some_styles)
 .filter(unwanted_nodes)
 .click(click_handler)
 .show();
 
 Writing this in function composition order would cause an instant
 quantum leap in unreadability.


 
 Which just goes to show that it's also a question of what you're used
 to, because I find that using the order that you did here rather than
 normal function call chaining is what causes an instance quantum leap
 in unreadibility.


[...]

The order I did it here can be read from top to bottom, just like a
sequence of statements. The function composition order would have to be
read from bottom to top, contrary to the general flow of control in the
rest of the code. That's what makes it unreadable.


T

-- 
If it tastes good, it's probably bad for you.
Mar 08 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/08/2012 03:14 AM, Ary Manzana wrote:

 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,


uniq.
Mar 08 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/8/12 7:27 AM, Timon Gehr wrote:

 On 03/08/2012 03:14 AM, Ary Manzana wrote:

 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,


 uniq.


Oh, right, I didn
Mar 08 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 05:45:47PM -0300, Ary Manzana wrote:

 On 3/8/12 7:27 AM, Timon Gehr wrote:

On 03/08/2012 03:14 AM, Ary Manzana wrote:

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,


uniq.




[...]

And ids.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi
Mar 08 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/08/2012 10:07 PM, H. S. Teoh wrote:

 On Thu, Mar 08, 2012 at 05:45:47PM -0300, Ary Manzana wrote:

 On 3/8/12 7:27 AM, Timon Gehr wrote:

 On 03/08/2012 03:14 AM, Ary Manzana wrote:

 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,


 uniq.




 [...]

 And ids.


 T


Is that in some standard library interface?
Mar 09 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-03-09 15:39, Timon Gehr wrote:

 On 03/08/2012 10:07 PM, H. S. Teoh wrote:

 On Thu, Mar 08, 2012 at 05:45:47PM -0300, Ary Manzana wrote:

 On 3/8/12 7:27 AM, Timon Gehr wrote:

 On 03/08/2012 03:14 AM, Ary Manzana wrote:

 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,


 uniq.




 [...]

 And ids.


 T


 Is that in some standard library interface?


Site.find is part of ActiveRecord (part of Rails), the rest is part of 
the core (standard) library.

-- 
/Jacob Carlborg
Mar 09 2012
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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.

The nice thing about dur!"seconds" is that only one module-level symbol is  
introduced (dur), and it's unlikely to conflict with local symbols

It may not be as intuitive, but it's certainly readable, and not too  
verbose to type.

-Steve
Mar 08 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 08 2012
parent "Nick Sabalausky" <a a.a> writes:
"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:jjat9r$1pvp$2 digitalmars.com...

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


Which is annoying:

http://d.puremagic.com/issues/show_bug.cgi?id=7291
Mar 08 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Mar 08 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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".
Mar 08 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 08 Mar 2012 14:07:13 -0500, Adam D. Ruppe  
<destructionator gmail.com> wrote:


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


Thanks to this thread, I bet you never forget that again ;)  I know I  
won't...

-Steve
Mar 08 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 8 March 2012 at 19:48:19 UTC, Steven Schveighoffer 
wrote:

 Thanks to this thread, I bet you never forget that again ;)  I 
 know I won't...


Indeed. I actually did get currTime() right this time around,
thanks to etching it in after getting it wrong the last two times.

Eventually, we get used to whatever name and can remember it.
(Unless it is PHP's library which I swear self-mutates any time
you aren't looking at it.)


Still though, we've spent a lot of time in phobos on things
like capitalization so we can remember it without special
thought. I really want to do the same on the abbreviations too.
Mar 08 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 08:53:44PM +0100, Adam D. Ruppe wrote:

 On Thursday, 8 March 2012 at 19:48:19 UTC, Steven Schveighoffer wrote:

Thanks to this thread, I bet you never forget that again ;)  I
know I won't...


 
 Indeed. I actually did get currTime() right this time around,
 thanks to etching it in after getting it wrong the last two times.
 
 Eventually, we get used to whatever name and can remember it.
 (Unless it is PHP's library which I swear self-mutates any time
 you aren't looking at it.)


[...]

Heh, I didn't know PHP had quantum mechanical properties. ;-) Can you
imagine PHP being the first language to run on a quantum computer? Oh
the horrors!



 Still though, we've spent a lot of time in phobos on things like
 capitalization so we can remember it without special thought. I really
 want to do the same on the abbreviations too.


IMO, making all abbreviations in Phobos consistent would be a big step
forward.

But Walter didn't seem to pleased about the recent pull request to add
aliases for seconds/secs, so this may or may not actually happen. :-(


T

-- 
It is the quality rather than the quantity that matters. -- Lucius Annaeus
Seneca
Mar 08 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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?

AFAIK, core.time and std.datetime are 100% consistent with all of their 
abbreviations. Stuff is always abbreviated or not - it's never abbreviated in 
some places and not in others - and stuff that's abbreviated is always 
abbreviated the same way. The _only_ argument for inconsistency that I see is 
that seconds is never abbreviated, while the sub-second units (which have 
seconds in their names) are always abbreviated. But the API is completely 
consistent on what it does and doesn't abbreviate it and how it abbreviates 
it.

And no examples outside of core.time and std.datetime have been given. What 
else is inconsistent in Phobos with regards to abbreviations. It's not like we 
have a ton of stuff that we keep abbreviating differently all over the place. 
It's quite possible that there is an occasional case of two versions of a 
particular abbreviation being used somewhere (e.g. cur vs curr), but AFAIK, 
that's quite rare. We _do_ use abbreviations, but we don't use them heavily. 
Most functions are one or two words, many with no abbreviations at all.

I really get the impression that this whole abbreviation "inconconsistency" 
thing is being blown out of proportion based on a few function names that some 
of the people in this thread don't like (e.g. currTime). I don't buy that the 
abbreviation inconsistency really exists.

And we've actually _reduced_ the number of inconsistencies in Phobos by fixing 
most of the functions and enums which weren't camelcased so that they're 
properly camelcased. I just don't see any real problem here.

- Jonathan M Davis
Mar 08 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.

But at the end of the day, this *is* just bikeshedding, so perhaps it's
not worth spending so much time and energy on. People will get used to
the quirky names eventually, and life goes on. *shrug*


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL
Mar 08 2012
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Mar 09 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 09:55:50 deadalnix wrote:

 Le 09/03/2012 05:42, H. S. Teoh a =C3=A9crit :

 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.


=20
 You know, people keep saying that the abbreviations are inconsiste=






nt,

 but I don't buy that. _What_ abbreviations are inconsistent?


=20
 [...]
=20
 My comment was referring specifically to the pull request that adds=





 "secs" as an alternative for "seconds". From what Walter said, he s=




eems

 to be against any renaming changes, so any existing inconsistencies=




 that

 we might find seems likely to be rejected as well.


=20
 Why it isn't possible to support both ? And miliseconds as well a use=


cs

 ? This make sense, as long as they are both common.


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

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

- Jonathan M Davis
Mar 09 2012
parent reply deadalnix <deadalnix gmail.com> writes:
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 ?).
Mar 09 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 10:28:12 deadalnix wrote:

 Le 09/03/2012 10:07, Jonathan M Davis a =C3=A9crit :

 On Friday, March 09, 2012 09:55:50 deadalnix wrote:

 Le 09/03/2012 05:42, H. S. Teoh a =C3=A9crit :

 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 b=












ig

 step forward.


=20
 You know, people keep saying that the abbreviations are inconsis=










tent,

 but I don't buy that. _What_ abbreviations are inconsistent?


=20
 [...]
=20
 My comment was referring specifically to the pull request that ad=








ds

 "secs" as an alternative for "seconds". From what Walter said, he=








 seems

 to be against any renaming changes, so any existing inconsistenci=








es that

 we might find seems likely to be rejected as well.


=20
 Why it isn't possible to support both ? And miliseconds as well a =






usecs

 ? This make sense, as long as they are both common.


=20
 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 rea=




ding

 code will wonder what the difference is. It just adds more confusio=




n 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?
=20
 Walter and Andrei are very much against having aliases in the libra=




ry just

 to create different names for the same stuff. And adding more optio=




ns 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 horri=




bly

 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. Th=




is is

 no different.
=20
 - Jonathan M Davis


=20
 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 con=
sistent=20
as they're going to get. seconds are _always_ seconds, and _no_ units g=
reater=20
than seconds are ever abbreviated. Only the sub-second units are abbrev=
iated.=20
And they're abbreviated only because they would have been way too long=20=

otherwise. And making seconds secs would create even _more_ inconsisten=
cies.=20
Just read the discusion in the pull request:

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

- Jonathan M Davis
Mar 09 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 09/03/2012 11:58, Jonathan M Davis a écrit :

 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


Yes, this is consistent in this regards. What isn't consistent is to 
choose to not abbreviate seconds, hours, minutes, but to abbreviate 
nsecs, usecs.

Considering the existing codebase, I think the best option now is to 
allow both. In an ideal worlds, I would argue that we go for all 
abbreviation or none.

I did read, the topic. Interesting, but I think walter isn't consistent 
with its own argumentation on point 6. Consider that in french, « dur » 
means « hard ». Even associated with keyword like dlang, this is 100% 
ungooglable. He is also plain wrong on point 5. No progress is made for 
experienced D programmers (arghuably, it is a step backward for such 
people), but for newcomers it is. At some point, we will have to 
consider newcomers as an important subject.

I do agree with most other points, this is not good to have 2 names for 
the same thing. However, the actual names are confusing, it seems that 
this thread make it pretty much clear. A lot of people have trouble with 
dur and seconds. Now, instead of changing everything that exists, lets 
make secs available. This isn't perfect, but it is the consequence of 
the inconsistency of naming convention that occurs (between sub seconds 
units and other units) in a first place, not the ideal case.
Mar 09 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
PS: just to be clear, I do agree with most of what you said here : 
https://github.com/D-Programming-Language/druntime/pull/173
Mar 09 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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 =C3=A9crit :

 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 b=










ig

 step forward.


=20
 You know, people keep saying that the abbreviations are inconsis=








tent,

 but I don't buy that. _What_ abbreviations are inconsistent?


=20
 [...]
=20
 My comment was referring specifically to the pull request that ad=






ds

 "secs" as an alternative for "seconds". From what Walter said, he=






 seems

 to be against any renaming changes, so any existing inconsistenci=






es that

 we might find seems likely to be rejected as well.


=20
 Why it isn't possible to support both ? And miliseconds as well a u=




secs

 ? This make sense, as long as they are both common.


=20
 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 readi=


ng

 code will wonder what the difference is. It just adds more confusion =


to the

 library and reduces its cohesiveness and consistency. It works far be=


tter

 to just have the one symbol. Isn't that one of the major complaints a=


bout

 PHP? That it has a ton of different ways to do the same thing?
=20
 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 t=


he

 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 wr=


ong.

 They just don't happen to be the names that you prefer. You have to l=


earn

 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 de=
tailed=20
discussion on this particular case, then just read the comments in the =
now=20
closed pull requested for adding "secs":

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

- Jonathan M Davis
Mar 09 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/9/12 6:17 AM, Jonathan M Davis wrote:

 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


Sample Ruby session:


 irb


ruby-1.8.7-p352 :001 > [1, 2, 3].count
  => 3
ruby-1.8.7-p352 :002 > [1, 2, 3].length
  => 3
ruby-1.8.7-p352 :003 > [1, 2, 3].size
  => 3

I never saw *anyone* complaining about this. When you write, you choose 
whatever is convenient to you (whatever comes to your mind first). When 
you read it, it's understandable. Nobody wonders "why didn't he wrote 
'length' instead of 'size'", because the meaning is clear.
Mar 09 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jjd21r$6ni$1 digitalmars.com...

 Sample Ruby session:


 irb


 ruby-1.8.7-p352 :001 > [1, 2, 3].count
  => 3
 ruby-1.8.7-p352 :002 > [1, 2, 3].length
  => 3
 ruby-1.8.7-p352 :003 > [1, 2, 3].size
  => 3

 I never saw *anyone* complaining about this. When you write, you choose 
 whatever is convenient to you (whatever comes to your mind first). When 
 you read it, it's understandable. Nobody wonders "why didn't he wrote 
 'length' instead of 'size'", because the meaning is clear.


I would wonder what the subtle distinction is. FWIW.
Mar 09 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 09, 2012 at 01:34:38PM -0500, Nick Sabalausky wrote:

 "Ary Manzana" <ary esperanto.org.ar> wrote in message 
 news:jjd21r$6ni$1 digitalmars.com...

 Sample Ruby session:


 irb


 ruby-1.8.7-p352 :001 > [1, 2, 3].count
  => 3
 ruby-1.8.7-p352 :002 > [1, 2, 3].length
  => 3
 ruby-1.8.7-p352 :003 > [1, 2, 3].size
  => 3

 I never saw *anyone* complaining about this. When you write, you
 choose whatever is convenient to you (whatever comes to your mind
 first). When you read it, it's understandable. Nobody wonders "why
 didn't he wrote 'length' instead of 'size'", because the meaning is
 clear.


 
 I would wonder what the subtle distinction is. FWIW.


[...]

Me too. I would assume that 'count' counts array elements whereas 'size'
counts the number of bytes the array uses up.

IMAO, this sort of "write your mind and somehow it just works" thing
only encourages lazy programming (guessing what something does without
knowing for sure, and copy-n-pasting code without understanding it,
which leads to bit rot and hideous patchwork code that houses all sorts
of subtle bugs and corner-case failures).


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at
it. -- Pete Bleackley
Mar 09 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/9/12 4:09 PM, H. S. Teoh wrote:

 On Fri, Mar 09, 2012 at 01:34:38PM -0500, Nick Sabalausky wrote:

 "Ary Manzana"<ary esperanto.org.ar>  wrote in message
 news:jjd21r$6ni$1 digitalmars.com...

 Sample Ruby session:


 irb


 ruby-1.8.7-p352 :001>  [1, 2, 3].count
   =>  3
 ruby-1.8.7-p352 :002>  [1, 2, 3].length
   =>  3
 ruby-1.8.7-p352 :003>  [1, 2, 3].size
   =>  3

 I never saw *anyone* complaining about this. When you write, you
 choose whatever is convenient to you (whatever comes to your mind
 first). When you read it, it's understandable. Nobody wonders "why
 didn't he wrote 'length' instead of 'size'", because the meaning is
 clear.


 I would wonder what the subtle distinction is. FWIW.


 [...]

 Me too. I would assume that 'count' counts array elements whereas 'size'
 counts the number of bytes the array uses up.


Indeed, count can be used to count elements:

ruby-1.8.7-p352 :002 > [1, 2, 3, 3, 3].count 3
  => 3
ruby-1.8.7-p352 :004 > [1, 2, 3, 3, 3].count &:odd?
  => 4
ruby-1.8.7-p352 :005 > [1, 2, 3, 3, 3].count { |x| x <= 2 }
  => 2

Just that when you use it without arguments it just counts everything.

size is an alias of length. But count just work as an alias as well, 
without arguments.


 IMAO, this sort of "write your mind and somehow it just works" thing
 only encourages lazy programming (guessing what something does without
 knowing for sure, and copy-n-pasting code without understanding it,
 which leads to bit rot and hideous patchwork code that houses all sorts
 of subtle bugs and corner-case failures).


We also write lots of tests in Ruby. :-P
Mar 09 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jjdqe4$1oeb$1 digitalmars.com...

 Indeed, count can be used to count elements:

 ruby-1.8.7-p352 :002 > [1, 2, 3, 3, 3].count 3
  => 3
 ruby-1.8.7-p352 :004 > [1, 2, 3, 3, 3].count &:odd?
  => 4
 ruby-1.8.7-p352 :005 > [1, 2, 3, 3, 3].count { |x| x <= 2 }
  => 2


Interesting idea.


 IMAO, this sort of "write your mind and somehow it just works" thing
 only encourages lazy programming (guessing what something does without
 knowing for sure, and copy-n-pasting code without understanding it,
 which leads to bit rot and hideous patchwork code that houses all sorts
 of subtle bugs and corner-case failures).


 We also write lots of tests in Ruby. :-P


Writing plenty of tests is good no matter what, but it's an inferior 
substitute for proper compile-time checks. Not that that's applicable to 
this "count vs length vs size" subdiscussion, of course. Just a general 
comment on the dynamic world's fairly common "lots of tests" excuse.
Mar 09 2012
parent Ary Manzana <ary esperanto.org.ar> writes:
On 3/9/12 6:21 PM, Nick Sabalausky wrote:

 "Ary Manzana"<ary esperanto.org.ar>  wrote in message
 news:jjdqe4$1oeb$1 digitalmars.com...

 Indeed, count can be used to count elements:

 ruby-1.8.7-p352 :002>  [1, 2, 3, 3, 3].count 3
   =>  3
 ruby-1.8.7-p352 :004>  [1, 2, 3, 3, 3].count&:odd?
   =>  4
 ruby-1.8.7-p352 :005>  [1, 2, 3, 3, 3].count { |x| x<= 2 }
   =>  2


 Interesting idea.


 IMAO, this sort of "write your mind and somehow it just works" thing
 only encourages lazy programming (guessing what something does without
 knowing for sure, and copy-n-pasting code without understanding it,
 which leads to bit rot and hideous patchwork code that houses all sorts
 of subtle bugs and corner-case failures).


 We also write lots of tests in Ruby. :-P


 Writing plenty of tests is good no matter what, but it's an inferior
 substitute for proper compile-time checks. Not that that's applicable to
 this "count vs length vs size" subdiscussion, of course. Just a general
 comment on the dynamic world's fairly common "lots of tests" excuse.


True. I'd like to find (or do) a language that combines both of two worlds.

I started one, but I don't have much time to continue it and also I'm 
stuck with design/implementation decisions. :-P

https://github.com/asterite/crystal

(not everything in the bullet list is implemented, those are just 
wishes, but everything in "samples" compiles and runs)

And other people had similar ideas:

http://whitequark.org/blog/2011/12/21/statically-compiled-ruby/
Mar 09 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/9/12 5:54 AM, Ary Manzana wrote:

 Sample Ruby session:

  > irb
 ruby-1.8.7-p352 :001 > [1, 2, 3].count
 => 3
 ruby-1.8.7-p352 :002 > [1, 2, 3].length
 => 3
 ruby-1.8.7-p352 :003 > [1, 2, 3].size
 => 3

 I never saw *anyone* complaining about this. When you write, you choose
 whatever is convenient to you (whatever comes to your mind first). When
 you read it, it's understandable. Nobody wonders "why didn't he wrote
 'length' instead of 'size'", because the meaning is clear.


I don't think this sits well in the D culture.

Andrei
Mar 09 2012
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/8/12 4:04 PM, Jonathan M Davis wrote:

 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.


I just stumbled upon this again in Ruby. I have a time object. I want to 
know if it's in the past. I wrote:

time.past?

it worked! :-)
Mar 08 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jjbg62$2vi3$1 digitalmars.com...

 On 3/8/12 4:04 PM, Jonathan M Davis wrote:

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








[...]

 Yeah. I don't understand how anyone can expect to just write code and 
 have it
 work without looking anything up.


 I just stumbled upon this again in Ruby. I have a time object. I want to 
 know if it's in the past. I wrote:

 time.past?

 it worked! :-)


I don't like to do such things (especially in dynamic languages). I'd be 
concerned about it *seeming* to work, but not exactly as I expect. Just 
seems to be programming by guesswork and assumptions. I don't trust it.
Mar 08 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 07:40:09PM -0500, Nick Sabalausky wrote:

 "Ary Manzana" <ary esperanto.org.ar> wrote in message 
 news:jjbg62$2vi3$1 digitalmars.com...


[...]

 I just stumbled upon this again in Ruby. I have a time object. I
 want to know if it's in the past. I wrote:

 time.past?

 it worked! :-)


 
 I don't like to do such things (especially in dynamic languages). I'd
 be concerned about it *seeming* to work, but not exactly as I expect.
 Just seems to be programming by guesswork and assumptions. I don't
 trust it.


[...]

Exactly! What if it just happened to do what you *think* it does that
one time, but actually does something different? Then you'd end up with
nasty subtle bugs everywhere that only show up when you run into
boundary conditions or when you pass in parameters that break your
initial (wrong) assumptions.


T

-- 
Having a smoking section in a restaurant is like having a peeing section
in a swimming pool. -- Edward Burr
Mar 08 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.289.1331260526.4860.digitalmars-d puremagic.com...
[...]

 T

 -- 
 Having a smoking section in a restaurant is like having a peeing section
 in a swimming pool. -- Edward Burr


That's one great thing about Ohio: A few years back we had a state law 
passed here (by public vote! I had been convinced it wouldn't pass) 
prohibiting smoking in workplaces and public buildings/businesses. That 
includes, of course, restaurants. No more smoking sections! I feel so 
spoiled now when I travel to a state that still has public indoor smoking. 
It's like stepping back into the stone age.
Mar 08 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 01:45:13 Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.289.1331260526.4860.digitalmars-d puremagic.com...
 [...]
 

 T


 
 That's one great thing about Ohio: A few years back we had a state law
 passed here (by public vote! I had been convinced it wouldn't pass)
 prohibiting smoking in workplaces and public buildings/businesses. That
 includes, of course, restaurants. No more smoking sections! I feel so
 spoiled now when I travel to a state that still has public indoor smoking.
 It's like stepping back into the stone age.


I'm from California, where it's been illegal to smoke in restaurants for 15+ 
years now, and it always shocks me to see a smoking section in restaurants in 
other states. It's not something that I even think about.

- Jonathan M Davis
Mar 08 2012
parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Friday, 9 March 2012 at 07:02:47 UTC, Jonathan M Davis wrote:

 On Friday, March 09, 2012 01:45:13 Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.289.1331260526.4860.digitalmars-d puremagic.com...
 [...]
 

 T


 
 That's one great thing about Ohio: A few years back we had a 
 state law
 passed here (by public vote! I had been convinced it wouldn't 
 pass)
 prohibiting smoking in workplaces and public 
 buildings/businesses. That
 includes, of course, restaurants. No more smoking sections! I 
 feel so
 spoiled now when I travel to a state that still has public 
 indoor smoking.
 It's like stepping back into the stone age.


 I'm from California, where it's been illegal to smoke in 
 restaurants for 15+
 years now, and it always shocks me to see a smoking section in 
 restaurants in
 other states. It's not something that I even think about.

 - Jonathan M Davis


I smoke, but smoking inside is weird to me. I'll do it sometimes 
in my own home, but even then not usually.
Mar 08 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 11:01:21PM -0800, Jonathan M Davis wrote:

 On Friday, March 09, 2012 01:45:13 Nick Sabalausky wrote:


[...]

 That's one great thing about Ohio: A few years back we had a state
 law passed here (by public vote! I had been convinced it wouldn't
 pass) prohibiting smoking in workplaces and public
 buildings/businesses. That includes, of course, restaurants. No more
 smoking sections! I feel so spoiled now when I travel to a state
 that still has public indoor smoking.  It's like stepping back into
 the stone age.


 
 I'm from California, where it's been illegal to smoke in restaurants
 for 15+ years now, and it always shocks me to see a smoking section in
 restaurants in other states. It's not something that I even think
 about.


[...]

You think it's bad to have a smoking section in restaurants? Back in the
old days (I'm pretty sure it isn't the case anymore -- at least I sure
hope not!), Japan Airlines used to have a smoking section in the cabin.
I was on a *transatlantic* flight like that once. You cannot imagine my
relief after the flight was finally over.


T

-- 
Give me some fresh salted fish, please.
Mar 09 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 02:04:20PM -0500, Jonathan M Davis wrote:
[...]

 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.


+1.



 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.


[...]

That's true. Most of the abbreviations I've been comfortable with are
those that I've learned when I was a teenage aspiring programmer. In
retrospect, a lot of it makes no sense. I just preferred it that way
'cos that's the way I first learned it, and AFAICT at the time, that was
the way it had *always* been (which is, of course, not true in
retrospect).


T

-- 
Любишь кататься - люби и саночки возить.
Mar 08 2012
parent Derek <ddparnell bigpond.com> writes:
On Fri, 09 Mar 2012 06:42:15 +1100, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:


 Most of the abbreviations I've been comfortable with are
 those that I've learned when I was a teenage aspiring programmer.


You've just reminded me about an incident that happened to me. In a  
previous age, I was a Computer Operator (IBM System 360/25 - a mainframe)  
and was teaching myself COBOL during the night shifts. I wrote a little  
program to solve quadratic equations and called it QUADCALC. One day my  
boss called me into his office because he noticed it was run only a night  
time and wanted to know what it was. I explained and everything turned out  
ok for me (I was promoted in fact to a trainee programmer). But he  
initially thought I'd written a program to calculate horse racing  
Quadrella predictions, which would have been very inappropriate use of  
company time. Gotta love those abbreviations.

-- 
Derek Parnell
Melbourne, Australia
Mar 08 2012
prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/8/12 8:55 AM, 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.


Thanks, I didn't know that function.

The problem is, you don't go saying "Hey, I want the back of an array", 
(or the back element of an array) you usually say "I want the last 
element of an array" (or range, whatever). I can't understand why "back" 
was used instead of last.
Mar 08 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 08 Mar 2012 15:51:59 -0500, Ary Manzana <ary esperanto.org.ar>  
wrote:


 On 3/8/12 8:55 AM, 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.


 Thanks, I didn't know that function.

 The problem is, you don't go saying "Hey, I want the back of an array",  
 (or the back element of an array) you usually say "I want the last  
 element of an array" (or range, whatever). I can't understand why "back"  
 was used instead of last.


I think front and back were used for two reasons.  One, to avoid confusion  
with first and last as it applies to list-based languages.  Two, because  
STL uses those terms.

This is when it was decided:  
http://forum.dlang.org/post/gltq4k$93i$2 digitalmars.com

There was much discussion before that thread, look around to see what was  
said.

-Steve
Mar 08 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 08/03/2012 12:55, Steven Schveighoffer a écrit :

 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.

 The nice thing about dur!"seconds" is that only one module-level symbol
 is introduced (dur), and it's unlikely to conflict with local symbols

 It may not be as intuitive, but it's certainly readable, and not too
 verbose to type.

 -Steve


the shorter the symbol, the higher the probability of collision. This is 
math. Definitively an argument in favor of not abbreviating.
Mar 08 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 11:56:58PM +0100, deadalnix wrote:

 Le 08/03/2012 12:55, Steven Schveighoffer a crit :


[...]

The nice thing about dur!"seconds" is that only one module-level
symbol is introduced (dur), and it's unlikely to conflict with local
symbols

It may not be as intuitive, but it's certainly readable, and not too
verbose to type.

-Steve


 
 the shorter the symbol, the higher the probability of collision.
 This is math. Definitively an argument in favor of not abbreviating.


That's not the whole story, though. Languages don't use all combinations
of symbols equally. A symbol like 'abc' collides very easily, whereas
'kqx' is much less likely to collide, even though both are the same
length.  (cf. http://en.wikipedia.org/wiki/Zipf's_law)


T

-- 
Once bitten, twice cry...
Mar 08 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Mar 08 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 07/03/2012 01:25, Jonathan M Davis a écrit :

 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.


You read way more code than you write. By way more I mean WAY WAY MORE !

Additionally, this make the task harder for any new dev. This is 
nonsense, and a recipe for failure. D has enough in it to scare 
beginners. No need to add some more.

BTW, I'm not aware of any successful recent language using a lot of 
abbreviations in its standard lib. That is not a proof, but definitively 
should be looked at.
Mar 08 2012
parent "Nick Sabalausky" <a a.a> writes:
"deadalnix" <deadalnix gmail.com> wrote in message 
news:jjbcok$2pm9$1 digitalmars.com...

 BTW, I'm not aware of any successful recent language using a lot of 
 abbreviations in its standard lib. That is not a proof, but definitively 
 should be looked at.


I interpret that as a trend of "If you *can* do something [use 
non-abbreviated symbol names], you *should*." Just like games industry: They 
*can* use smaller text now that TVs have higher resolutions, so now they 
*insist* on making all their text as tiny as possible just because they can. 
(Never mind the pesky fact that tiny text in a higher resolution is *STILL 
TINY TEXT!* Erm, ok, ranty side-track over...)
Mar 08 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Mar 06 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Mar 06 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 07/03/2012 03:42, H. S. Teoh a crit :

 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.


+1 if it can be used as a property. Which require explicit modification 
of dur.
Mar 09 2012
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 07.03.2012 6: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.


+111
By the way name collisions are not that bad, I mean one still can have 
say hours variable an it still going to work. At least the following 
works with std.regex:

auto match = match("abc", "abc");
if(match)
	writeln("Wow!");

Probably it won't work if one have match func with 0 arguments.

-- 
Dmitry Olshansky
Mar 06 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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.

-- 
/Jacob Carlborg
Mar 07 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"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")
Mar 07 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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?"
Mar 07 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.175.1331147548.4860.digitalmars-d puremagic.com...

 On Wed, Mar 07, 2012 at 01:50:03PM -0500, Nick Sabalausky wrote:

 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.


I'm not really much of a ruby fan, except in comparison to python (I think 
ruby's whole "It's like English, just write it like you'd expect it to be 
written" thing is both untrue and misguided). But yea, UFCS is awesome 
(erm..."will be" awesome...eventually...I hope...).


 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.


That "5."/".5" float syntax need to die anyway. It's just pointless and gets 
in the way of things that *aren't* pointless like UFCS.

I agree that "5.0.hours" looks a little weird, but meh, it's good enough and 
there's no fundamental problem with it (and it's a hell of a lot better than 
"5. .hours"). And you can just do "(5.0).hours" if you really want.
Mar 07 2012
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote:

 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


Actually, Kenji's pull request for UFCS already takes care of 
this. Things like 5. aren't allowed, nor is 5.f; a number has to 
follow the decimal. So 5.f would invoke UFCS function f with the 
integer 5. I believe this change is already merged, though the 
rest of the UFCS pull request isn't unfortunately.
Mar 07 2012
next sibling parent Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 3/7/2012 8:20 PM, Kapps wrote:

 On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote:

 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


 Actually, Kenji's pull request for UFCS already takes care of this.
 Things like 5. aren't allowed, nor is 5.f; a number has to follow the
 decimal. So 5.f would invoke UFCS function f with the integer 5. I
 believe this change is already merged, though the rest of the UFCS pull
 request isn't unfortunately.


I can definitely confirm that porting C/C++ floating point literals to D 
is a huge pain in the ass because of this change, so its definitely in 
to the degree it breaks my math and physics libs heavily :)
Mar 07 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/08/2012 03:20 AM, Kapps wrote:

 On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote:

 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


 Actually, Kenji's pull request for UFCS already takes care of this.
 Things like 5. aren't allowed, nor is 5.f; a number has to follow the
 decimal. So 5.f would invoke UFCS function f with the integer 5. I
 believe this change is already merged, though the rest of the UFCS pull
 request isn't unfortunately.


5. is still allowed.
Mar 08 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-07 19:50, 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:

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


That's what I was hoping for as well.


 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")


That would be so nice. Actually UFCS seems to have been merged now:

https://github.com/D-Programming-Language/dmd/commit/b7742f7a733ff73d364c6ed54af70d875d7e911b

-- 
/Jacob Carlborg
Mar 08 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jj6gjm$2m6a$1 digitalmars.com...

 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.


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

https://github.com/D-Programming-Language/phobos/pull/485

https://github.com/D-Programming-Language/tools/pull/23

I completely understand the "secs==seconds" pull request being rejected and 
I think that's perfectly reasonable...

But I'm going to be really pissed if this one's rejected out of some 
misapplied, overly-puritanical obsession with "no aliases".
Mar 09 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jjdru9$1rv5$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:jj6gjm$2m6a$1 digitalmars.com...

 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.


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

 https://github.com/D-Programming-Language/phobos/pull/485

 https://github.com/D-Programming-Language/tools/pull/23

 I completely understand the "secs==seconds" pull request being rejected 
 and I think that's perfectly reasonable...

 But I'm going to be really pissed if this one's rejected out of some 
 misapplied, overly-puritanical obsession with "no aliases".


Note how much *nicer* it makes all the sample and unittest code.
Mar 09 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-03-09 22:16, Nick Sabalausky wrote:


 Note how much *nicer* it makes all the sample and unittest code.


So much better.

-- 
/Jacob Carlborg
Mar 10 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a a.a> wrote:


 "Nick Sabalausky" <a a.a> wrote in message
 news:jj6gjm$2m6a$1 digitalmars.com...

 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.


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

 https://github.com/D-Programming-Language/phobos/pull/485

 https://github.com/D-Programming-Language/tools/pull/23

 I completely understand the "secs==seconds" pull request being rejected  
 and
 I think that's perfectly reasonable...

 But I'm going to be really pissed if this one's rejected out of some
 misapplied, overly-puritanical obsession with "no aliases".


You'll need to have dur aliased to duration to follow the normal  
deprecation procedure.

I can't say I agree with this, as it pollutes the global namespace with  
several common terms that could be used for fields.

-Steve
Mar 09 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote:

 On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a a.a> wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:jj6gjm$2m6a$1 digitalmars.com...
 

 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.


 
 https://github.com/D-Programming-Language/druntime/pull/174
 
 https://github.com/D-Programming-Language/phobos/pull/485
 
 https://github.com/D-Programming-Language/tools/pull/23
 
 I completely understand the "secs==seconds" pull request being rejected
 and
 I think that's perfectly reasonable...
 
 But I'm going to be really pissed if this one's rejected out of some
 misapplied, overly-puritanical obsession with "no aliases".


 
 You'll need to have dur aliased to duration to follow the normal
 deprecation procedure.
 
 I can't say I agree with this, as it pollutes the global namespace with
 several common terms that could be used for fields.


Yeah. My general reaction is that this is a _bad_ idea. It creates aliases and 
uses names for free functions which are commonly used. We'll see if Walter says 
anything about this one, but my first reaction is to reject it. I'll wait for 
comments on it though.

- Jonathan M Davis
Mar 09 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.357.1331329638.4860.digitalmars-d puremagic.com...

 On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote:

 On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a a.a> wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:jj6gjm$2m6a$1 digitalmars.com...


 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.


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

 https://github.com/D-Programming-Language/phobos/pull/485

 https://github.com/D-Programming-Language/tools/pull/23

 I completely understand the "secs==seconds" pull request being rejected
 and
 I think that's perfectly reasonable...

 But I'm going to be really pissed if this one's rejected out of some
 misapplied, overly-puritanical obsession with "no aliases".


 You'll need to have dur aliased to duration to follow the normal
 deprecation procedure.

 I can't say I agree with this, as it pollutes the global namespace with
 several common terms that could be used for fields.


 Yeah. My general reaction is that this is a _bad_ idea. It creates aliases 
 and
 uses names for free functions which are commonly used. We'll see if Walter 
 says
 anything about this one, but my first reaction is to reject it. I'll wait 
 for
 comments on it though.


If that's the case, then this alias-phobia will have *truly* gotten 
completely out of hand.
Mar 09 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 09 Mar 2012 16:47:01 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote:

 On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a a.a> wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:jj6gjm$2m6a$1 digitalmars.com...


 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.


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

 https://github.com/D-Programming-Language/phobos/pull/485

 https://github.com/D-Programming-Language/tools/pull/23

 I completely understand the "secs==seconds" pull request being  


 rejected

 and
 I think that's perfectly reasonable...

 But I'm going to be really pissed if this one's rejected out of some
 misapplied, overly-puritanical obsession with "no aliases".


 You'll need to have dur aliased to duration to follow the normal
 deprecation procedure.

 I can't say I agree with this, as it pollutes the global namespace with
 several common terms that could be used for fields.


 Yeah. My general reaction is that this is a _bad_ idea. It creates  
 aliases and
 uses names for free functions which are commonly used. We'll see if  
 Walter says
 anything about this one, but my first reaction is to reject it. I'll  
 wait for
 comments on it though.


I'll say I *don't* agree with the rejection of aliases on principle --  
aliases can be extremely useful/helpful, and they cost literally nothing  
(the "cognitive cost" on the docs is a BS argument IMO).  I just don't  
agree with consuming so many common symbols for the sake of sugar.

-Steve
Mar 09 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:

 I'll say I *don't* agree with the rejection of aliases on principle --
 aliases can be extremely useful/helpful, and they cost literally nothing
 (the "cognitive cost" on the docs is a BS argument IMO). I just don't
 agree with consuming so many common symbols for the sake of sugar.


aliases need to have a really good argument for existing. If UFCS is fully 
implemented, then I think that there is _some_ argument for having stuff like 
hours and minutes, because then you can do stuff like 5.seconds() (though 
honestly, I really don't like the idea). The alias enables different usages 
rather than simply being another name for the same thing.

Now, in this particular case, it's that much worse for exactly the reason that 
you're against it: it uses common names for free functions. It's not as big a 
problem as it would be in C or C++, but it's still a problem. There's also 
some risk that it will break code.

- Jonathan M Davis
Mar 09 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:

 I'll say I *don't* agree with the rejection of aliases on principle --
 aliases can be extremely useful/helpful, and they cost literally nothing
 (the "cognitive cost" on the docs is a BS argument IMO). I just don't
 agree with consuming so many common symbols for the sake of sugar.


 aliases need to have a really good argument for existing. If UFCS is fully
 implemented, then I think that there is _some_ argument for having stuff
 like
 hours and minutes, because then you can do stuff like 5.seconds() (though
 honestly, I really don't like the idea). The alias enables different usages
 rather than simply being another name for the same thing.


What remains on UFCS? I've heard someone (Nick?) say he'd like it to match
static member functions too.  I haven't tested but it seems like
5.seconds() should work ever since Kenji's pull request was merged a couple
of days ago (thanks Kenji and Walter, I'm really looking forward to that
change).

Regards,
Brad Anderson



 Now, in this particular case, it's that much worse for exactly the reason
 that
 you're against it: it uses common names for free functions. It's not as
 big a
 problem as it would be in C or C++, but it's still a problem. There's also
 some risk that it will break code.

 - Jonathan M Davis
Mar 09 2012
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:

 I'll say I *don't* agree with the rejection of aliases on principle --
 aliases can be extremely useful/helpful, and they cost literally nothing
 (the "cognitive cost" on the docs is a BS argument IMO). I just don't
 agree with consuming so many common symbols for the sake of sugar.


 aliases need to have a really good argument for existing. If UFCS is fully
 implemented, then I think that there is _some_ argument for having stuff
 like
 hours and minutes, because then you can do stuff like 5.seconds() (though
 honestly, I really don't like the idea). The alias enables different usages
 rather than simply being another name for the same thing.

 Now, in this particular case, it's that much worse for exactly the reason
 that
 you're against it: it uses common names for free functions. It's not as
 big a
 problem as it would be in C or C++, but it's still a problem. There's also
 some risk that it will break code.


Oh, and I'd just like to add some of my experience to this. These names are
used by Boost's datetime library and they've never been a problem for me
and at work we make extensive use of Boost datetime.  There is risk but I
think in this specific case they are fairly small (especially in D, over
C++).  We switched to Boost datetime after we had hundreds of thousands of
lines of code written using a different system and I didn't encounter any
problems with the duration shortcut functions clashing.

Anyway, it sounds like Walter is probably opposed from what he was saying
in the other thread so this conversation is probably moot.

Regards,
Brad Anderson

- Jonathan M Davis





 Mar 09 2012



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Fri, 09 Mar 2012 18:16:56 -0500, Brad Anderson <eco gnuk.net> wrote:


 On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis  
 <jmdavisProg gmx.com>wrote:


 On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:

 I'll say I *don't* agree with the rejection of aliases on principle --
 aliases can be extremely useful/helpful, and they cost literally  


 nothing

 (the "cognitive cost" on the docs is a BS argument IMO). I just don't
 agree with consuming so many common symbols for the sake of sugar.


 aliases need to have a really good argument for existing. If UFCS is  
 fully
 implemented, then I think that there is _some_ argument for having stuff
 like
 hours and minutes, because then you can do stuff like 5.seconds()  
 (though
 honestly, I really don't like the idea). The alias enables different  
 usages
 rather than simply being another name for the same thing.

 Now, in this particular case, it's that much worse for exactly the  
 reason
 that
 you're against it: it uses common names for free functions. It's not as
 big a
 problem as it would be in C or C++, but it's still a problem. There's  
 also
 some risk that it will break code.


 Oh, and I'd just like to add some of my experience to this. These names  
 are
 used by Boost's datetime library and they've never been a problem for me
 and at work we make extensive use of Boost datetime.  There is risk but I
 think in this specific case they are fairly small (especially in D, over
 C++).


I want to stress again the difference between C++'s namespaces, and D's  
module import mechanism.  In C++, you *deliberately* pull a namespace into  
your scope (and usually only in the implementation file, which doesn't  
affect any other implementation files), whereas in D, a standard "import  
std.datetime" *automatically* pulls its namespace into your scope, and any  
public imports it has made.

I've used boost's datetime.  I didn't really like the whole "different  
types for each unit" mechanism, but I used it with success, and was glad I  
didn't have to re-invent it :)  But then again, I used it as the original  
date/time lib for my project.

-Steve



 Mar 09 2012



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Friday, March 09, 2012 18:39:25 Steven Schveighoffer wrote:

 I want to stress again the difference between C++'s namespaces, and D's
 module import mechanism. In C++, you *deliberately* pull a namespace into
 your scope (and usually only in the implementation file, which doesn't
 affect any other implementation files), whereas in D, a standard "import
 std.datetime" *automatically* pulls its namespace into your scope, and any
 public imports it has made.


Yeah. D has great tools for getting around conflicts, but things tend to 
conflict by default, which means that it's very easy to break code by 
introducing conflicts when adding functions.

- Jonathan M Davis



 Mar 09 2012



prev sibling next sibling parent  Brad Anderson <eco gnuk.net>  writes:


On Fri, Mar 9, 2012 at 4:45 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Friday, March 09, 2012 18:39:25 Steven Schveighoffer wrote:

 I want to stress again the difference between C++'s namespaces, and D's
 module import mechanism. In C++, you *deliberately* pull a namespace into
 your scope (and usually only in the implementation file, which doesn't
 affect any other implementation files), whereas in D, a standard "import
 std.datetime" *automatically* pulls its namespace into your scope, and


 any

 public imports it has made.


 Yeah. D has great tools for getting around conflicts, but things tend to
 conflict by default, which means that it's very easy to break code by
 introducing conflicts when adding functions.


Hmm, fair enough.  In our case they were essentially pulled into the global
namespace due to some questionable decisions with regard to namespaces made
in our project.  The difference between D and C++ is important to point out
though so thanks for clarifying.

Regards,
Brad Anderson



 - Jonathan M Davis





 Mar 09 2012



prev sibling  parent reply "David Nadlinger" <see klickverbot.at>  writes:


On Friday, 9 March 2012 at 23:39:25 UTC, Steven Schveighoffer 
wrote:

 I want to stress again the difference between C++'s namespaces, 
 and D's module import mechanism.  In C++, you *deliberately* 
 pull a namespace into your scope (and usually only in the 
 implementation file, which doesn't affect any other 
 implementation files), whereas in D, a standard "import 
 std.datetime" *automatically* pulls its namespace into your 
 scope, and any public imports it has made.


To be honest, I don't quite see the big difference here. Just as 
you can only #include a »namespaced« file without using a using 
directive, you can »static import« a module in D. You seem to 
be arguing that we shouldn't encourage use of these features (cf. 
the std.log discussion), but I can't quite follow you there.

Why would _not_ using static and selective imports be desirable? 
Don't we generally discourage people from write »using namespace 
std« in C++ or »import *« in Python as well? (I'm aware that 
the D module system is different, but the general idea is the 
same)

David



 Mar 09 2012



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Fri, 09 Mar 2012 19:32:06 -0500, David Nadlinger <see klickverbot.at>=
  =

wrote:


 On Friday, 9 March 2012 at 23:39:25 UTC, Steven Schveighoffer wrote:

 I want to stress again the difference between C++'s namespaces, and D=




's  =


 module import mechanism.  In C++, you *deliberately* pull a namespace=




  =


 into your scope (and usually only in the implementation file, which  =





 doesn't affect any other implementation files), whereas in D, a  =





 standard "import std.datetime" *automatically* pulls its namespace in=




to  =


 your scope, and any public imports it has made.


 To be honest, I don't quite see the big difference here. Just as you c=


an  =


 only #include a =C2=BBnamespaced=C2=AB file without using a using dire=


ctive, you  =


 can =C2=BBstatic import=C2=AB a module in D. You seem to be arguing th=


at we  =


 shouldn't encourage use of these features (cf. the std.log discussion)=


,  =


 but I can't quite follow you there.


The big difference is, the most straightforward and most exemplified  =

import syntax is:

import modulename;

So to argue this is not the default syntax, or not the most desirable/us=
ed  =

syntax is just plain invalid.

In contrast, C++'s import syntax is:

#include "modulename.h"

which does not import any namespaces into your scope.


 Why would _not_ using static and selective imports be desirable? Don't=


  =


 we generally discourage people from write =C2=BBusing namespace std=C2=


=AB in C++  =


 or =C2=BBimport *=C2=AB in Python as well? (I'm aware that the D modul=


e system is  =


 different, but the general idea is the same)


I don't think we should make the default the most conflicting or difficu=
lt  =

to use method.  For example, to say:

"always import log using:

import log =3D std.log"

Is not as good as just not having to say that (i.e. import std.log like =
 =

you would any other module).  I remember Tango had a couple of modules  =

like that, and I thought it was pretty confusing.

That doesn't mean you can't utilize those facilities (and I *don't*  =

discourage them).  I just don't think it should be a barrier to usage.

-Steve



 Mar 09 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/9/12 4:59 PM, Steven Schveighoffer wrote:

 I don't think we should make the default the most conflicting or
 difficult to use method. For example, to say:

 "always import log using:

 import log = std.log"

 Is not as good as just not having to say that (i.e. import std.log like
 you would any other module). I remember Tango had a couple of modules
 like that, and I thought it was pretty confusing.

 That doesn't mean you can't utilize those facilities (and I *don't*
 discourage them). I just don't think it should be a barrier to usage.


Yah, I'm a bit "ehm" about the sudden recommendation to use named 
import, too. However, I've been "ehm" about similar things in the past 
and came to figure that some things are just useful idioms in the 
forming (e.g. returning locally-defined structs).

I find "import log = std.log" better and using the language more 
naturally than the alternative - a struct/class in conjunction with the 
"stuttering" convention std.log.log.


Andrei



 Mar 09 2012



  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Saturday, 10 March 2012 at 04:56:13 UTC, Andrei Alexandrescu 
wrote:


 Yah, I'm a bit "ehm" about the sudden recommendation to use 
 named import, too. However, I've been "ehm" about similar 
 things in the past and came to figure that some things are just 
 useful idioms in the forming (e.g. returning locally-defined 
 structs).

 I find "import log = std.log" better and using the language 
 more naturally than the alternative - a struct/class in 
 conjunction with the "stuttering" convention std.log.log.


There are other solutions, such as naming the functions something 
less common. And there's always selective import with renaming.

Who knows, it's hard to predict what the actual effect will be.

-Steve



 Mar 10 2012



prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Friday, 9 March 2012 at 21:36:28 UTC, Steven Schveighoffer 
wrote:

 I can't say I agree with this, as it pollutes the global 
 namespace with several common terms that could be used for 
 fields.


There's no such thing as a global namespace in D, and
field names wouldn't be affected even if there was one.

int minutes(int i) {
	return i;
}

struct A {
	int minutes; // not a problem
         void foo() {
              minutes = .minutes(1); // works
	}
}



 Mar 09 2012



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Fri, 09 Mar 2012 16:50:22 -0500, Adam D. Ruppe  
<destructionator gmail.com> wrote:


 On Friday, 9 March 2012 at 21:36:28 UTC, Steven Schveighoffer wrote:

 I can't say I agree with this, as it pollutes the global namespace with  
 several common terms that could be used for fields.


 There's no such thing as a global namespace in D, and
 field names wouldn't be affected even if there was one.


Of course there isn't.  What I meant was the module level namespace.  Any  
file you import by default goes into your current module namespace.  In  
effect it's the global namespace *for your module*.

But if I have to spell that out every time, it's going to be a lot of  
typing.  It's generally understood that the "global namespace" is the  
effective global namespace during your module.  Yes, there are ways to  
rename imports, I find it poor design to *require* renaming imports.


 int minutes(int i) {
 	return i;
 }

 struct A {
 	int minutes; // not a problem
          void foo() {
               minutes = .minutes(1); // works
 	}
 }


Again, I find this just as descriptive and not terrible to type:

struct A {
   Duration minutes;
   void foo() {
       minutes = dur!"minutes"(1);
   }
}

-Steve



 Mar 09 2012



  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Friday, 9 March 2012 at 22:54:37 UTC, Steven Schveighoffer 
wrote:

 Again, I find this just as descriptive and not terrible to type:


Yeah, that's fine by me (though duration is still better
than dur :-D )

I'm just the name conflict isn't a big deal either
since writing ".minutes" in some places to disambiguate
the scope works in most cases too.



 Mar 09 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.waxaa1s1eav7ka localhost.localdomain...

 On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a a.a> wrote:


 "Nick Sabalausky" <a a.a> wrote in message
 news:jj6gjm$2m6a$1 digitalmars.com...

 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.


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

 https://github.com/D-Programming-Language/phobos/pull/485

 https://github.com/D-Programming-Language/tools/pull/23

 I completely understand the "secs==seconds" pull request being rejected 
 and
 I think that's perfectly reasonable...

 But I'm going to be really pissed if this one's rejected out of some
 misapplied, overly-puritanical obsession with "no aliases".


 You'll need to have dur aliased to duration to follow the normal 
 deprecation procedure.


Yea, I already have that in there. (I was going to link to the line in the 
diff, but github's being it's usual steaming piece of shit again...)


 I can't say I agree with this, as it pollutes the global namespace with 
 several common terms that could be used for fields.


I'd argue that should not be considered a problem in this case:
http://forum.dlang.org/post/jj6hnv$2o9s$1 digitalmars.com



 Mar 09 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:jjdu0j$209o$1 digitalmars.com...

 I can't say I agree with this, as it pollutes the global namespace with 
 several common terms that could be used for fields.


 I'd argue that should not be considered a problem in this case:
 http://forum.dlang.org/post/jj6hnv$2o9s$1 digitalmars.com


Plus, having to [**occasionally**] change a "minutes" to "numMinutes" (or 
something, frankly, much more descriptive) is a hell of a lot better than 
having to use 'dur!"minutes"(5)' instead of 'minutes(5)'.



 Mar 09 2012



  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Fri, 09 Mar 2012 17:38:08 -0500, Nick Sabalausky <a a.a> wrote:


 "Nick Sabalausky" <a a.a> wrote in message
 news:jjdu0j$209o$1 digitalmars.com...

 I can't say I agree with this, as it pollutes the global namespace with
 several common terms that could be used for fields.


 I'd argue that should not be considered a problem in this case:
 http://forum.dlang.org/post/jj6hnv$2o9s$1 digitalmars.com


 Plus, having to [**occasionally**] change a "minutes" to "numMinutes" (or
 something, frankly, much more descriptive) is a hell of a lot better than
 having to use 'dur!"minutes"(5)' instead of 'minutes(5)'.


I find both equally descriptive and neither one too offensive.  All things  
being equal, dur wins because it consumes only one top-level symbol, and  
is already there.

This is all my opinion of course, and we've already seen how much affect  
that has ;)

-Steve



 Mar 09 2012



prev sibling next sibling parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Tue, Mar 06, 2012 at 06:43:39PM -0500, 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.


You *could* shorten String to Str, but that would be inconsistent with
everything else (e.g. toString), so that's a no-go.



 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.


[...]

I'm on the fence about this one. It's true that duration!"seconds"(44)
is uncomfortably long, but 'dur' also tends towards the side of
meaningless, esp. if it occurs only once or twice in otherwise-unrelated
code. I'm inclined to leave it as 'duration' since I can't think of any
good abbreviations for it either.


T

-- 
A bend in the road is not the end of the road unless you fail to make
the turn. -- Brian White



 Mar 06 2012



prev sibling next sibling parent  Brad Anderson <eco gnuk.net>  writes:


On Tue, Mar 6, 2012 at 4:53 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:


 On Tue, Mar 06, 2012 at 06:43:39PM -0500, 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.


 You *could* shorten String to Str, but that would be inconsistent with
 everything else (e.g. toString), so that's a no-go.



 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.


 [...]

 I'm on the fence about this one. It's true that duration!"seconds"(44)
 is uncomfortably long, but 'dur' also tends towards the side of
 meaningless, esp. if it occurs only once or twice in otherwise-unrelated
 code. I'm inclined to leave it as 'duration' since I can't think of any
 good abbreviations for it either.


 T

 --
 A bend in the road is not the end of the road unless you fail to make
 the turn. -- Brian White


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



 Mar 06 2012



prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


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



 Mar 06 2012



 next sibling parent reply "F i L" <witte2008 gmail.com>  writes:


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 


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/Python folks adapt their code to .NET.



 Mar 06 2012



 next sibling parent reply Bill  <dolive89 sina.com>  writes:


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 

 
 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/Python folks adapt their code to .NET.



naming specification

good luck
Bill



 Mar 06 2012



  parent  deadalnix <deadalnix gmail.com>  writes:


Le 07/03/2012 04:05, Bill a écrit :

 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


 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/Python folks adapt their code to .NET.



naming specification

 good luck��
 Bill


This is an horrible idea. That make code easier to write, and harder to 
read. Some language beat D at this game, consider PERL, which is close 
to write only.



 Mar 09 2012



prev sibling  parent reply deadalnix <deadalnix gmail.com>  writes:


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


 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.



 Mar 09 2012



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Friday, March 09, 2012 09:33:20 deadalnix wrote:

 Le 07/03/2012 02:00, F i L a =C3=A9crit :

 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 t=




hey

 justify rather well. Still, if D's goal is to gain popularity, I th=




ink


=20
 The problem with making any change to Phobos is backwards compatibi=




lity.

=20
 We just need a politic for the change. IE: make the old name a warnin=


g,

 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=20=

deprecation process that allows us to change them if we need to, but it=
's=20
still disruptive.

- Jonathan M Davis



 Mar 09 2012



prev sibling  parent  Brad Anderson <eco gnuk.net>  writes:


On Fri, Mar 9, 2012 at 1:46 AM, Jonathan M Davis <jmdavisProg gmx.com>wrote=
:


 On Friday, March 09, 2012 09:33:20 deadalnix wrote:

 Le 07/03/2012 02:00, F i L a =E9crit :

 I personally find it much easier to remember and use longer, more
 sentance-like method names. However, Jonathan and others obviously fe=






el

 more comfortable writing with a high level of abbreviation, which the=






y

 justify rather well. Still, if D's goal is to gain popularity, I thin=






k



 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


The "secs" and "seconds" inconsistency is something I've seen people in IRC
hit and complain about on several occasions.  The dur!"seconds"(1) syntax
I've seen complained about or confusion over on both IRC and on reddit by
active and potential users.  While I don't feel particularly strong about
these issues I feel I should point out that actual users are hitting them
and the issues bug them enough that they feel the need to
complain publicly.  Changes must be made with care but the former issue on
inconsistency, I would argue, is a bigger issue than, say, the current
symbol deprecation/replace of toISOExtendedString (though I don't know the
history of the decision to make the change).

There shouldn't be two ways of expressing the exact same thing so the
"secs"/"seconds" should be a substitute and deprecate process rather than
just a simple alias if it were made. It looks like it's been rejected
already, though, which is unfortunate.  phobos is still a young library (or
at least parts of it, like datetime, are) and so these types of wart
removal could be made with limited disruption to current users.

The dur aliases would be welcome because they increase readability,
intuitive design, and brevity.  I know I just said their shouldn't be two
ways of doing the same thing but I don't feel this is the case here.  It's
a shortcut to doing exactly one thing and, as I said before, I wouldn't
want to lose the option of genericity. I just want to make specification of
it optional since I would use seconds(5) a great deal more often than
dur!base(5) (though I would use the latter fairly frequently in my line of
work).

Anyway, I just felt I'd share my opinion and what I've witnessed of other
users so it's at least it's heard and taken into consideration. The
decision is ultimately yours and Walter's.

Regards,
Brad Anderson



 Mar 09 2012



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


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



 Mar 06 2012



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


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.



 Mar 06 2012



  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Wednesday, March 07, 2012 03:49:46 Adam D. Ruppe wrote:

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


I don't understand this complaint at all. curr is an incredibly common 
abbreviation for current.

- Jonathan M Davis



 Mar 06 2012



 next sibling parent  "Brad Anderson" <eco gnuk.net>  writes:


On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis 
wrote:

 On Wednesday, March 07, 2012 03:49:46 Adam D. Ruppe wrote:

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


 I don't understand this complaint at all. curr is an incredibly 
 common
 abbreviation for current.

 - Jonathan M Davis


I agree.  curr isn't exactly uncommon.  I'd personally probably 
go with currentTime but it's perfectly readable as currTime.

Since it's already in Clock I'd even consider just using 'time' 
or 'now' but I don't feel strongly about it.

Regards,
Brad Anderson



 Mar 06 2012



prev sibling  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


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?



 Mar 06 2012



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Wednesday, March 07, 2012 04:42:50 Adam D. Ruppe wrote:

 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?


Definitely. I would pretty much never use current, because curr will do the job 
just as well, and it's shorter.

- Jonathan M Davis



 Mar 06 2012



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


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



 Mar 06 2012



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-03-07 04:46, Nick Sabalausky wrote:

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


Yeah, Clock.now() would be good and Data.today() as well.

-- 
/Jacob Carlborg



 Mar 07 2012



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Jacob Carlborg" <doob me.com> wrote in message 
news:jj755f$r7u$1 digitalmars.com...

 On 2012-03-07 04:46, Nick Sabalausky wrote:

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


 Yeah, Clock.now() would be good and Data.today() as well.


I dunno, on the second one, I think I'd prefer "Date.today()" ;)

(Nyuk nyuk nyuk)



 Mar 07 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-03-07 19:40, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:jj755f$r7u$1 digitalmars.com...

 On 2012-03-07 04:46, Nick Sabalausky wrote:

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


 Yeah, Clock.now() would be good and Data.today() as well.


 I dunno, on the second one, I think I'd prefer "Date.today()" ;)

 (Nyuk nyuk nyuk)


Hehe, missed that :)

-- 
/Jacob Carlborg



 Mar 08 2012



prev sibling  parent reply Stewart Gordon <smjg_1998 yahoo.com>  writes:


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.



 Mar 07 2012



 next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


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. It could correspond to over 24 different times. By restricting 
getting the time to SysTime, it encourages the writing of correct code.

- Jonathan M Davis



 Mar 07 2012



  parent reply Stewart Gordon <smjg_1998 yahoo.com>  writes:


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.

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.

Stewart.



 Mar 08 2012



  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


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



 Mar 08 2012



prev sibling next sibling parent  James Miller <james aatch.net>  writes:


On 8 March 2012 15:56, Jonathan M Davis <jmdavisProg gmx.com> 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. It could correspond to over 24 different times. By restricting
 getting the time to SysTime, it encourages the writing of correct code.

 - Jonathan M Davis


It tends to be better to go for proper timezoned code from the outset,
a workmate just had to add timezone support to the entire app
recently, took him about 2 weeks.

--
James Miller



 Mar 07 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


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



 Mar 08 2012



  parent  Stewart Gordon <smjg_1998 yahoo.com>  writes:


On 08/03/2012 13:45, Jacob Carlborg wrote:

 On 2012-03-08 02:22, Stewart Gordon wrote:


<snip>

 My utility library has, for consistency, DateValue.now, TimeValue.now
 and DateTime.now.


 Cool. Why the "Value" suffix?


As far as I can remember, DateValue was named to avert confusion with the Date
struct in 
Phobos.  TimeValue was named analogously.

OTOH, there wasn't anything called DateTime in Phobos at the time, and
DateTimeValue was 
unnecessarily wordy, so I just stuck with DateTime.

Steawrt.



 Mar 08 2012



prev sibling  parent reply deadalnix <deadalnix gmail.com>  writes:


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.



 Mar 09 2012



  parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Friday, March 09, 2012 09:39:23 deadalnix wrote:

 Le 07/03/2012 04:46, Nick Sabalausky a =C3=A9crit :

 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:bwqkuqhyiygvgqswicvz forum.dlang.org...
=20

 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 c=








ommon

 abbreviation for current.


=20
 Is it your *first* choice?


=20
 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 agre=




e with

 whoever it was (Brad?) that said "Clock.now()" would be even better=




.

=20
 The usage of current is often a smell that is saying =C2=AB I had no =


clue how

 to name that, so I did name it using current =C2=BB.
=20
 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 sam=
e=20
thing.

- Jonathan M Davis



 Mar 09 2012



prev sibling  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Wed, Mar 07, 2012 at 04:42:50AM +0100, Adam D. Ruppe wrote:

 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?


My first choice is actually 'cur', but I'm OK with 'curr'. I've
consistently used 'cur' for 'current' for at least the last decade and a
half, probably more.


T

-- 
Famous last words: I wonder what will happen if I do *this*...



 Mar 06 2012



  parent  deadalnix <deadalnix gmail.com>  writes:


Le 07/03/2012 06:54, H. S. Teoh a crit :

 On Wed, Mar 07, 2012 at 04:42:50AM +0100, Adam D. Ruppe wrote:

 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?


 My first choice is actually 'cur', but I'm OK with 'curr'. I've
 consistently used 'cur' for 'current' for at least the last decade and a
 half, probably more.


Don't want to be mean, but this isn't about what whoever is used to use. 
I know many people in non English speaking country that are used to name 
things using local language. SO what, do we should also consider  
courrant ,  corrente  and so on ?

Note that I'm not advocating for naming in local languages. This is a 
dumb idea, but anyway, this is used in the industry quite a lot. So ?

Shouldn't English should be the default, international language ? And 
so, English words isn't better than a double translation ?



 Mar 09 2012



prev sibling  parent reply "Brad Anderson" <eco gnuk.net>  writes:


On Wednesday, 7 March 2012 at 00:25:19 UTC, Jonathan M Davis 
wrote:

 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.


I understand the concern but, for what it's worth, I write 
project scheduling software professionally so I spend a lot of 
time working with dates and durations.  I'd have no problem with 
these being top level even though the chance of symbol clashing 
would be much higher for me than most programmers.  A standard 
library's datetime module seems like it should have first dibs on 
those names anyway.  I think it should gobble up that real estate.


 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.


That is a very nice feature for me as I have to work in arbitrary 
base units (seconds, minutes, days, hours, etc.) extensively.  I 
definitely would want that genericity to remain.  The aliases 
Nick wrote appear to be a good addition (unless I'm overlooking a 
problem with them).  You keep the genericity but get brevity with 
the package.

Although I still haven't really made use of it yet, it was really 
relieving to find D had such an extensive datetime module.  A lot 
of languages and libraries try to get away with doing the bare 
minimum (often just very thin and obvious wrappers over what the 
OS does) so thank you for putting so much time (I can only assume 
with how large the module is) and thought into designing 
something powerful that befits a powerful language.

Regards,
Brad Anderson



 - Jonathan M Davis





 Mar 06 2012



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/6/12 7:32 PM, Brad Anderson wrote:

 On Wednesday, 7 March 2012 at 00:25:19 UTC, Jonathan M Davis wrote:

 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.


 I understand the concern but, for what it's worth, I write project
 scheduling software professionally so I spend a lot of time working with
 dates and durations. I'd have no problem with these being top level even
 though the chance of symbol clashing would be much higher for me than
 most programmers. A standard library's datetime module seems like it
 should have first dibs on those names anyway. I think it should gobble
 up that real estate.


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

Andrei



 Mar 06 2012



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


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. On some level, it's unavoidable, 
and D has some great tools for minimizing the impact, but I also don't think 
that there's much reason to pick a name which is likely to cause conflicts with 
other modules when another name wouldn't, unless the other name is just 
horrible in comparison.

- Jonathan M Davis



 Mar 06 2012



prev sibling  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


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.


T

-- 
Let's call it an accidental feature. -- Larry Wall



 Mar 06 2012



prev sibling next sibling parent  Bill  <dolive89 sina.com>  writes:


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 



 Mar 06 2012



prev sibling next sibling parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 06 Mar 2012 11:38:09 -0500, Adam D. Ruppe  
<destructionator gmail.com> wrote:


 One of the stumbling blocks on using std.datetime is how
 many bizarre abbreviations it has.

 auto time = Clock.currentTime(); // bzzt, wrong


I would have guessed Clock.now();


 if(time - something > duration!"hours"(4)) // bzzt, wrong


I would have guessed Duration.hours(4);


 writeln(time.toISOExtendedString()); // bzzt, wrong, but this used to  
 work!


I would have looked this one up regardless :)


 Why aren't we using real words here? Real words are easier
 to remember and easier to type.


First, it doesn't matter what you pick.  People have their expectations,  
and nobody has the same ones.  It's all about learning the library and  
getting used to what is there.

Second, I agree that to abbreviate a couple characters is somewhat petty.

Third, I don't think any of the names in datetime are horrible.   
dur!"seconds" is immediately clear what it means.

Fourth, I kind of like having names that aren't going to be common field  
names.  For example, duration may be a common field that I would put in  
some kind of timer object.

You could make the same argument against dup vs. duplicate, or writeln vs.  
writeLine, I could go on forever.  There are no perfect names, because  
everyone has a different opinion.


 And the dmd spellchecker doesn't always help:

 Error: template instance duration!("hours") template 'duration' is not  
 defined, did you mean Duration?


This is a red herring.  The spellchecker cannot possibly know what you  
meant unless you were only a couple characters off.  It's not a  
mind-reader.


 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.



you have to learn Console.Out instead of System.out.  Neither is intuitive  
or perfect, you just have to learn it.

On your grounds, I would object to your proposed names as much as I do the  
current ones, since I didn't guess them to begin with.

-Steve



 Mar 07 2012



prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


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



 Mar 07 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.180.1331149159.4860.digitalmars-d puremagic.com...

 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.


That's just an implementation bug, though, isn't it? And wasn't it recently 
fixed? 



 Mar 07 2012



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.180.1331149159.4860.digitalmars-d puremagic.com...
 

 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.


 
 That's just an implementation bug, though, isn't it? And wasn't it recently
 fixed?


It's a design issue. Yes, the bug that private didn't affect aliases was fixed, 
but private does _not_ hide symbols. It only makes them inaccessible. So, for 
instance, if std.datetime were to alias std.string.indexOf to indexOf, then 
every module which imports both std.algorithm and std.datetime would then have 
to either alias std.algorithm.indexOf themselves or use the full import path. 
So, as it stands, private aliases are pretty much useless. It's just like how 
private functions can affect function overloading in spite of the fact that 
other modules can't use them.

This completely follows how private is designed. So, it's not a bug. But there 
are definitely arguments for changing how private works (e.g. the fact that you 
can't really alias stuff within a module without affecting other modules). The 
trick is convincing Walter to change it.

- Jonathan M Davis



 Mar 07 2012



 next sibling parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 03/07/2012 10:47 PM, Jonathan M Davis wrote:

 On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:

 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.180.1331149159.4860.digitalmars-d puremagic.com...


 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.


 That's just an implementation bug, though, isn't it? And wasn't it recently
 fixed?


 It's a design issue. Yes, the bug that private didn't affect aliases was fixed,
 but private does _not_ hide symbols. It only makes them inaccessible. So, for
 instance, if std.datetime were to alias std.string.indexOf to indexOf, then
 every module which imports both std.algorithm and std.datetime would then have
 to either alias std.algorithm.indexOf themselves or use the full import path.
 So, as it stands, private aliases are pretty much useless. It's just like how
 private functions can affect function overloading in spite of the fact that
 other modules can't use them.

 This completely follows how private is designed. So, it's not a bug. But there
 are definitely arguments for changing how private works (e.g. the fact that you
 can't really alias stuff within a module without affecting other modules). The
 trick is convincing Walter to change it.

 - Jonathan M Davis


There is absolutely no remotely valid argument against changing the 
behavior that does not involve a discussion of the compiler internals.



 Mar 07 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.186.1331156894.4860.digitalmars-d puremagic.com...

 On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.180.1331149159.4860.digitalmars-d puremagic.com...


 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:

 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.


 That's just an implementation bug, though, isn't it? And wasn't it 
 recently
 fixed?


 It's a design issue. Yes, the bug that private didn't affect aliases was 
 fixed,
 but private does _not_ hide symbols. It only makes them inaccessible. So, 
 for
 instance, if std.datetime were to alias std.string.indexOf to indexOf, 
 then
 every module which imports both std.algorithm and std.datetime would then 
 have
 to either alias std.algorithm.indexOf themselves or use the full import 
 path.
 So, as it stands, private aliases are pretty much useless.


Ahh, yea I remember now. I'd argue (strongly) that if a symbol is 
inaccessible than it should never conflict with a symbol that is accessible. 
After all, is there really much more point to the "visible vs accessible" 
distinction besides just being able to say "Symbol xxxx is private" instead 
of "Unrecognzed symbol xxxx"?



 Mar 07 2012



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:

 Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
 inaccessible than it should never conflict with a symbol that is accessible.
 After all, is there really much more point to the "visible vs accessible"
 distinction besides just being able to say "Symbol xxxx is private" instead
 of "Unrecognzed symbol xxxx"?


Well, truth be told, it should be possible for the compiler to still say that 
the symbol is private rather than that it's unrecognized. Just because it's 
hidden for overload resolution and the like doesn't mean that the compiler 
couldn't still recognize it as existing but inaccessible in cases where 
there's no other match. It _is_ probably easier to implement it with the 
"unrecognized symbol" behavior though.

The only real downside that I can think of of making private symbols hidden is 
that it could cause issues when symbols are changed to or from private, but 
the way that overload sets are handled probably prevents that from being a 
real issue. It may break code, but I don't think that it would silently break 
code to change a symbol to or from private, which would be the real problem.

- Jonathan M Davis



 Mar 07 2012



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 03/07/2012 11:30 PM, Jonathan M Davis wrote:

 On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:

 Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
 inaccessible than it should never conflict with a symbol that is accessible.
 After all, is there really much more point to the "visible vs accessible"
 distinction besides just being able to say "Symbol xxxx is private" instead
 of "Unrecognzed symbol xxxx"?


 Well, truth be told, it should be possible for the compiler to still say that
 the symbol is private rather than that it's unrecognized. Just because it's
 hidden for overload resolution and the like doesn't mean that the compiler
 couldn't still recognize it as existing but inaccessible in cases where
 there's no other match. It _is_ probably easier to implement it with the
 "unrecognized symbol" behavior though.

 The only real downside that I can think of of making private symbols hidden is
 that it could cause issues when symbols are changed to or from private, but
 the way that overload sets are handled probably prevents that from being a
 real issue. It may break code, but I don't think that it would silently break
 code to change a symbol to or from private, which would be the real problem.

 - Jonathan M Davis


Yes, private symbols probably shouldn't be hidden completely. For 
example, private constructors convey special semantics. (their existence 
also removes the default constructor) But private symbols should never 
conflict with public symbols. Probably it is best to also disallow 
overloading private symbols against public symbols.



 Mar 07 2012



  parent  "Martin Nowak" <dawg dawgfoto.de>  writes:


On Thu, 08 Mar 2012 01:00:48 +0100, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 03/07/2012 11:30 PM, Jonathan M Davis wrote:

 On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:

 Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
 inaccessible than it should never conflict with a symbol that is  
 accessible.
 After all, is there really much more point to the "visible vs  
 accessible"
 distinction besides just being able to say "Symbol xxxx is private"  
 instead
 of "Unrecognzed symbol xxxx"?


 Well, truth be told, it should be possible for the compiler to still  
 say that
 the symbol is private rather than that it's unrecognized. Just because  
 it's
 hidden for overload resolution and the like doesn't mean that the  
 compiler
 couldn't still recognize it as existing but inaccessible in cases where
 there's no other match. It _is_ probably easier to implement it with the
 "unrecognized symbol" behavior though.




Private symbols can be proposed during the spell correction lookup.


 The only real downside that I can think of of making private symbols  
 hidden is
 that it could cause issues when symbols are changed to or from private,  
 but
 the way that overload sets are handled probably prevents that from  
 being a
 real issue. It may break code, but I don't think that it would silently  
 break
 code to change a symbol to or from private, which would be the real  
 problem.

 - Jonathan M Davis


 Yes, private symbols probably shouldn't be hidden completely. For  
 example, private constructors convey special semantics. (their existence  
 also removes the default constructor) But private symbols should never  
 conflict with public symbols. Probably it is best to also disallow  
 overloading private symbols against public symbols.


It doesn't work out if you want to overload private/public constructors.

https://github.com/D-Programming-Language/dmd/pull/739



 Mar 07 2012



prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com>  writes:


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.



 Mar 07 2012



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Wednesday, March 07, 2012 22:55:51 Stewart Gordon wrote:

 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.


I'm completely in favor of treating acronyms as being all captalized if the 
first letter is capitilized and all lowercase if the first letter is lowercase. 
It's actually a bit of a pet peeve of mine when people do stuff like Ascii 
instead of ASCII. And most of Phobos goes with fully capitilizing rather than 
just capitilizing the first letter. It's not completely consistent though.


 But it's confusing enough that there are still many functions in Phobos
 whose names are all lowercase when they should be camelCase.


That's _mostly_ been fixed. The main remaining culprits that I'm aware of are 
the std.string functions which take patterns. There was some discussion of 
replacing them with functions which take regexes. If we do that, then they'll 
be replaced with properly camelcased names. But _most_ of the function names 
in Phobos have been fixed to be properly camelcased.

- Jonathan M Davis



 Mar 07 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


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



 Mar 08 2012



  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Thursday, 8 March 2012 at 13:36:56 UTC, Jacob Carlborg wrote:

 auto isoExtendedString = time.toIsoExtendedString()


That's my preference as well.



 Mar 08 2012



prev sibling next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Thursday, March 08, 2012 16:18:39 James Miller wrote:

 On 8 March 2012 15:56, Jonathan M Davis <jmdavisProg gmx.com> 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. It could correspond to over
 24 different times. By restricting getting the time to SysTime, it
 encourages the writing of correct code.
 
 - Jonathan M Davis


 
 It tends to be better to go for proper timezoned code from the outset,
 a workmate just had to add timezone support to the entire app
 recently, took him about 2 weeks.


Definitely. The whole reason that I wrote std.datetime and that SysTime works 
the way that it does is because I've had to deal with enough time-related bugs 
at work that I was sick of it, and I wanted to make sure that D had a solution 
that did it right. And by maintaining its time in UTC internally and just 
adjusting the time to a particular time zone when required for output (e.g. 
getting the year of the SysTime or converting it to a string), a whole host of 
conversion errors are avoided (DST is _the_ largest mistake with regards to 
time in the history of computing IMHO).

Unfortunately, errors are still possible (e.g. sometimes you have to create a 
SysTime from a DateTime, and that can't be done without risking DST-related 
errors), but I believe that SysTime manages to reduce them about as much as is 
possible. So, in general, if you use SysTime, time should just be handled 
correctly without you having to worry about all of the details - like the time 
zone. But it also gives you the power to do more if you _do_ care about the 
details (e.g. selecting a specific time zone).

- Jonathan M Davis



 Mar 07 2012



prev sibling next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Thursday, March 08, 2012 18:46:56 H. S. Teoh wrote:

 On Thu, Mar 08, 2012 at 07:07:49PM -0500, Jonathan M Davis wrote:

 On Thursday, March 08, 2012 15:52:37 H. S. Teoh wrote:


 [...]
 

 $(selector)
 .html(htmlcode)
 .add(more_nodes)
 .css(some_styles)
 .filter(unwanted_nodes)
 .click(click_handler)
 .show();
 
 Writing this in function composition order would cause an instant
 quantum leap in unreadability.


 
 Which just goes to show that it's also a question of what you're used
 to, because I find that using the order that you did here rather than
 normal function call chaining is what causes an instance quantum leap
 in unreadibility.


 
 [...]
 
 The order I did it here can be read from top to bottom, just like a
 sequence of statements. The function composition order would have to be
 read from bottom to top, contrary to the general flow of control in the
 rest of the code. That's what makes it unreadable.


I see where you're coming from. It's just not the same for me. I find function 
chaining to be much easier to read when it's done the normal way. And if I'm 
looking for functions to be like a sequence of statements, then I'm going to 
write them that way instead of chaining them.

- Jonathan M Davis



 Mar 08 2012



prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Thursday, March 08, 2012 20:42:31 H. S. Teoh wrote:

 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.
 
 But at the end of the day, this *is* just bikeshedding, so perhaps it's
 not worth spending so much time and energy on. People will get used to
 the quirky names eventually, and life goes on. *shrug*


I think that most of the major issues with inconsistencies have been fixed. 
Sure, there may be a few left, but the longer that they're there, the more 
costly it is to fix them. And D is reaching the point where it needs to be 
stable. Constantly tweaking the standard library just doesn't cut it. I made 
quite a few changes to try and fix inconsistencies (such as function names 
which weren't camelcased like they were supposed to be), and that was painful 
enough, and engendered plenty of complaints in spite of the fact that there 
were quite a few people arguing for fixing the names to make Phobos consistent.

I really don't think that Phobos is really any more quirky or inconsistent 
than your average standard library. It's not perfect, but it isn't 
particularly inconsistent either. We'll continue to make improvement to it 
(primarily by adding new stuff), but it's increasingly costly to make breaking 
changes. And, on the whole, it's not like what we have is horrible. The 
biggest problems involve whole modules (which are generally older) which need 
to be redesigned, and those will happen. But minor stuff like tweaking function 
names doesn't really buy us enough to be worth it anymore. If a function 
changes sufficiently to merit a full replacement, then maybe we can change its 
name and phase out the old one (e.g. if we change the functions in std.string 
which take patterns to take regexes instead), but changing a name to change a 
name just isn't worth it when we're trying to provide a serious offering with D 
and Phobos. We're too far along.

- Jonathan M Davis



 Mar 08 2012



  parent  dolive <dolive89 sina.com>  writes:


Jonathan M Davis Wrote:


 On Thursday, March 08, 2012 20:42:31 H. S. Teoh wrote:

 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.
 
 But at the end of the day, this *is* just bikeshedding, so perhaps it's
 not worth spending so much time and energy on. People will get used to
 the quirky names eventually, and life goes on. *shrug*


 
 I think that most of the major issues with inconsistencies have been fixed. 
 Sure, there may be a few left, but the longer that they're there, the more 
 costly it is to fix them. And D is reaching the point where it needs to be 
 stable. Constantly tweaking the standard library just doesn't cut it. I made 
 quite a few changes to try and fix inconsistencies (such as function names 
 which weren't camelcased like they were supposed to be), and that was painful 
 enough, and engendered plenty of complaints in spite of the fact that there 
 were quite a few people arguing for fixing the names to make Phobos consistent.
 
 I really don't think that Phobos is really any more quirky or inconsistent 
 than your average standard library. It's not perfect, but it isn't 
 particularly inconsistent either. We'll continue to make improvement to it 
 (primarily by adding new stuff), but it's increasingly costly to make breaking 
 changes. And, on the whole, it's not like what we have is horrible. The 
 biggest problems involve whole modules (which are generally older) which need 
 to be redesigned, and those will happen. But minor stuff like tweaking
function 
 names doesn't really buy us enough to be worth it anymore. If a function 
 changes sufficiently to merit a full replacement, then maybe we can change its 
 name and phase out the old one (e.g. if we change the functions in std.string 
 which take patterns to take regexes instead), but changing a name to change a 
 name just isn't worth it when we're trying to provide a serious offering with
D 
 and Phobos. We're too far along.
 
 - Jonathan M Davis


make breaking changes at the same time provide a change list and provide a
automatically batch changes the tools of third - party source code.

good luck

dolive



 Mar 09 2012



prev sibling next sibling parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Thu, Mar 08, 2012 at 08:48:43PM -0800, Jonathan M Davis wrote:
[...]

 I really don't think that Phobos is really any more quirky or
 inconsistent than your average standard library. It's not perfect, but
 it isn't particularly inconsistent either.


In fact, in spite of its present shortcomings, Phobos as a whole is a
lot *more* consistent than, say, your average C library.



 We'll continue to make improvement to it (primarily by adding new
 stuff), but it's increasingly costly to make breaking changes. And, on
 the whole, it's not like what we have is horrible. The biggest
 problems involve whole modules (which are generally older) which need
 to be redesigned, and those will happen.


Personally, I can't wait for the day std.io merges, and std.stream and
std.stdio are deprecated. The current std.stream/std.stdio dichotomy
just makes no sense at all. Plus, a significant part of std.stdio needs
to be tweaked to use Ranges anyway.



 But minor stuff like tweaking function names doesn't really buy us
 enough to be worth it anymore. If a function changes sufficiently to
 merit a full replacement, then maybe we can change its name and phase
 out the old one (e.g. if we change the functions in std.string which
 take patterns to take regexes instead), but changing a name to change
 a name just isn't worth it when we're trying to provide a serious
 offering with D and Phobos.  We're too far along.


[...]

True.

And +1 for std.string functions to take regexes. In this day and age,
hack jobs for doing string operations just don't cut it anymore. Regexes
rule string processing. (Well, they do have their limitations, but
anything *weaker* than regexes is certainly too weak to be generally
useful.)


T

-- 
Guns don't kill people. Bullets do.



 Mar 08 2012



prev sibling next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Friday, March 09, 2012 10:01:19 Brad Anderson wrote:

 On Fri, Mar 9, 2012 at 1:46 AM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 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

 
 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


 
 The "secs" and "seconds" inconsistency is something I've seen people in IRC
 hit and complain about on several occasions. The dur!"seconds"(1) syntax
 I've seen complained about or confusion over on both IRC and on reddit by
 active and potential users. While I don't feel particularly strong about
 these issues I feel I should point out that actual users are hitting them
 and the issues bug them enough that they feel the need to
 complain publicly. Changes must be made with care but the former issue on
 inconsistency, I would argue, is a bigger issue than, say, the current
 symbol deprecation/replace of toISOExtendedString (though I don't know the
 history of the decision to make the change).
 
 There shouldn't be two ways of expressing the exact same thing so the
 "secs"/"seconds" should be a substitute and deprecate process rather than
 just a simple alias if it were made. It looks like it's been rejected
 already, though, which is unfortunate. phobos is still a young library (or
 at least parts of it, like datetime, are) and so these types of wart
 removal could be made with limited disruption to current users.


As I explained in the pull request, if we switched to secs, it would just 
create a different set of inconsistencies:

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

There would just be a different set of complaints if seconds were changed to 
secs. No matter what we do here, we lose. Someone's going to be complaining. 
There is no perfect solution.

And while the library is young, it really needs to be stabilizing given that 
we want D to be real player in the programming world, and there is increasing 
resistance to changing it - especially from Walter and Andrei. If a breaking 
change is made, the change needs to be a clear win. And while using secs would 
certainly please some people, it would create it's own set of problems, so 
it's not at all a clear win IMHO.

- Jonathan M Davis



 Mar 09 2012



prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Friday, March 09, 2012 16:08:34 Brad Anderson wrote:

 On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:

 I'll say I *don't* agree with the rejection of aliases on principle --
 aliases can be extremely useful/helpful, and they cost literally nothing
 (the "cognitive cost" on the docs is a BS argument IMO). I just don't
 agree with consuming so many common symbols for the sake of sugar.


 
 aliases need to have a really good argument for existing. If UFCS is fully
 implemented, then I think that there is _some_ argument for having stuff
 like
 hours and minutes, because then you can do stuff like 5.seconds() (though
 honestly, I really don't like the idea). The alias enables different
 usages
 rather than simply being another name for the same thing.


 
 What remains on UFCS? I've heard someone (Nick?) say he'd like it to match
 static member functions too. I haven't tested but it seems like
 5.seconds() should work ever since Kenji's pull request was merged a couple
 of days ago (thanks Kenji and Walter, I'm really looking forward to that
 change).


I don't know what the current state of UFCS is. I know that Kenji has been 
working on it and that at least some portion of it has been checked in, but 
what exactly it enables at this point, I don't know.

- Jonathan M Davis



 Mar 09 2012



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Jonathan M Davis:


 I don't know what the current state of UFCS is.


I have found a possible problem in it, and probably there are some missing
parts, but it's working well.

At first I didn't like it a lot because it's cheap syntax sugar that adds no
new power and gives programmers more freedom to write different-looking
versions of the the same code (and this is often bad). But I have soon found
that it's able to make functional-style code more readable, because you write:
x.foo().bar().baz().spam()

Instead of this, where my eye sometimes loses count of the nesting level:
spam(baz(bar(foo(x))))

Bye,
bearophile



 Mar 09 2012



 next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Mar 09, 2012 at 06:50:50PM -0500, bearophile wrote:

 Jonathan M Davis:
 

 I don't know what the current state of UFCS is.


 
 I have found a possible problem in it, and probably there are some
 missing parts, but it's working well.


I found that x.foo doesn't work, it needs to be x.foo(). But we're
deprecating omission of parentheses of non- property functions anyway,
and an external function can hardly be a  property of anything, so I
don't think this needs to be fixed.



 At first I didn't like it a lot because it's cheap syntax sugar that
 adds no new power and gives programmers more freedom to write
 different-looking versions of the the same code (and this is often
 bad).


But it also allows you to write pseudo-members for generic templates
that want to access built-in types via some abstract interface. This
makes template code much much cleaner.



 But I have soon found that it's able to make functional-style code
 more readable, because you write:
 x.foo().bar().baz().spam()
 
 Instead of this, where my eye sometimes loses count of the nesting level:
 spam(baz(bar(foo(x))))


[...]

Personally, I find the chained syntax rather jarring if the object of
each . is different. I'm OK with things like jQuery where the base
object is always the same, but if it changes across the .'s, it can get
confusing to read.

OTOH, this is a refreshing change from centuries of silly backwards
function notation that we inherited from math, so maybe this is a good
thing after all. :-)


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com



 Mar 09 2012



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 03/10/2012 01:10 AM, H. S. Teoh wrote:

 On Fri, Mar 09, 2012 at 06:50:50PM -0500, bearophile wrote:

 Jonathan M Davis:


 I don't know what the current state of UFCS is.


 I have found a possible problem in it, and probably there are some
 missing parts, but it's working well.


 I found that x.foo doesn't work, it needs to be x.foo(). But we're
 deprecating omission of parentheses of non- property functions anyway,
 and an external function can hardly be a  property of anything, so I
 don't think this needs to be fixed.


UFCS for  properties seems to work according to the unit tests.
However, this makes  property ambiguous. foo = 2 will be the same as 2.foo.



 Mar 09 2012



  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sat, Mar 10, 2012 at 01:43:35AM +0100, Timon Gehr wrote:

 On 03/10/2012 01:10 AM, H. S. Teoh wrote:

On Fri, Mar 09, 2012 at 06:50:50PM -0500, bearophile wrote:

Jonathan M Davis:


I don't know what the current state of UFCS is.


I have found a possible problem in it, and probably there are some
missing parts, but it's working well.


I found that x.foo doesn't work, it needs to be x.foo(). But we're
deprecating omission of parentheses of non- property functions anyway,
and an external function can hardly be a  property of anything, so I
don't think this needs to be fixed.


 
 UFCS for  properties seems to work according to the unit tests.
 However, this makes  property ambiguous. foo = 2 will be the same as
 2.foo.


But 2.foo can never be interpreted as obj.foo = 2. I can't imagine any
way to write 2.something and have it come out as obj.foo(2).

The only remote possibility is inside a class/struct method, but in that
case doesn't class/struct scope take precedence anyway? And presumably,
you wouldn't be using pseudo-members if you're the one writing the
class.  Otherwise, if the programmer is deliberately trying to break the
system, well, he shouldn't be surprised if things break. :-)


T

-- 
Тише едешь, дальше будешь.



 Mar 09 2012



prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Friday, March 09, 2012 18:50:50 bearophile wrote:

 Jonathan M Davis:

 I don't know what the current state of UFCS is.


 
 I have found a possible problem in it, and probably there are some missing
 parts, but it's working well.
 
 At first I didn't like it a lot because it's cheap syntax sugar that adds no
 new power and gives programmers more freedom to write different-looking
 versions of the the same code (and this is often bad).


Which is one of the reasons that I really don't like the idea. Sometimes it's 
nice with strings, but it creates inconsistencies, and stuff like 5.max(7) just 
seems insane. UFCS will give people more freedom and may help templates in 
some cases, but I think that it's a major step back for readibility in 
general.


 But I have soon
 found that it's able to make functional-style code more readable, because
 you write: x.foo().bar().baz().spam()
 
 Instead of this, where my eye sometimes loses count of the nesting level:
 spam(baz(bar(foo(x))))


I must be in the minority in that I find chaining with UFCS to be _harder_ to 
read than the more traditional way. It just feels insanely backwards to me. 
But some people definitely seem to prefer the UFCS chaining. YMMV.

- Jonathan M Davis



 Mar 09 2012



 next sibling parent reply "David Nadlinger" <see klickverbot.at>  writes:


On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis 
wrote:

 UFCS will give people more freedom and may help templates in
 some cases, […]


Note aside: I think people tend to overestimate the amount of 
generic code that becomes easier to write/extend with UFCS, as D, 
in contrast to C++, doesn't have ADL.

David



 Mar 09 2012



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Saturday, March 10, 2012 01:22:49 David Nadlinger wrote:

 On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis
 
 wrote:

 UFCS will give people more freedom and may help templates in
 some cases, […]


 
 Note aside: I think people tend to overestimate the amount of
 generic code that becomes easier to write/extend with UFCS, as D,
 in contrast to C++, doesn't have ADL.


That wouldn't surprise me at all. But then again, aside from using
arrays as ranges, I don't recall _ever_ running into a function in D where 
a user-defined type had a member function with that name, and a free
function had that name, and I wanted to call that function in a template and 
therefore had to use static ifs to separate the two. So, personally, I don't 
think that it will help me _at all_. I can see there being a few cases where 
it would though. If C++ had it, then could have implemented begin and end 
differently and not have to try and get everyone to switch over to using the 
free function versions for C++11. And in the case of arrays, having that sort 
of syntax has been _very_ useful for ranges.

But I don't buy that that's really the case for other primitive types 
(certainly not frequently), and unless you don't control the user-defined type 
that you're trying to operate on, you'd just put the function on the type 
itself when dealing with a user-defined type.

So, it'll probably help _some_, but I think that there's a good chance that 
you're right and that it won't be as useful as some people are expecting. But 
for better or worse, it looks like we're getting it.

- Jonathan M Davis



 Mar 09 2012



prev sibling next sibling parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Mar 09, 2012 at 07:32:55PM -0500, Jonathan M Davis wrote:

 On Saturday, March 10, 2012 01:22:49 David Nadlinger wrote:

 On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis wrote:

 UFCS will give people more freedom and may help templates in
 some cases, […]






[...]

 So, it'll probably help _some_, but I think that there's a good chance
 that you're right and that it won't be as useful as some people are
 expecting. But for better or worse, it looks like we're getting it.


[...]

We already have it. Latest DMD in git understands stuff like 2.5.sqrt(),
and supports pseudo-members.


T

-- 
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not yet
been conceived. -- Michael B. Allen



 Mar 09 2012



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 03/10/2012 01:22 AM, David Nadlinger wrote:

 On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis wrote:

 UFCS will give people more freedom and may help templates in
 some cases, […]


 Note aside: I think people tend to overestimate the amount of generic
 code that becomes easier to write


If you're writing it yourself there are no restrictions on what symbols 
can be made visible.

/extend

This OTOH is a valid point.


 with UFCS, as D, in contrast to
 C++, doesn't have ADL.


This is a good thing. D symbol lookup is already the most complicated 
I've seen (for the compiler). DMD does not get it right. It is possible 
to write programs whose semantics depend on the order the modules are 
passed on the command line.



 Mar 09 2012



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.375.1331338580.4860.digitalmars-d puremagic.com...

 Which is one of the reasons that I really don't like the idea. Sometimes 
 it's
 nice with strings, but it creates inconsistencies, and stuff like 5.max(7) 
 just
 seems insane. UFCS will give people more freedom and may help templates in
 some cases, but I think that it's a major step back for readibility in
 general.



actualy use it with UFCS syntax (although they don't call it UFCS). I used 
to be pretty strongly in favor of that, but I've since gotten used to D's 
lax-ness about it.



 Mar 09 2012



prev sibling  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:

 At first I didn't like it a lot because it's cheap syntax sugar 
 that adds no new power and gives programmers more freedom to 
 write different-looking versions of the the same code (and this 
 is often bad).


What I like about is the encapsulation benefits. You
don't have to know if the function is a method or an
external function, it just works.

External, non-friend (so separate module in D) functions
are often preferable to methods because they don't have
access to the class' private members, so they cannot rely
on those implementation details.

Extending objects with new functions in this way also
means you don't break binary compatibility with the
existing code, since it isn't modified at all!


Of course, you could always do this with the old
syntax too, but then the syntax preference means
you are biased toward one implementation or the
other - it doesn't mesh as well and you may be
tempted to make things methods for the syntax,
despite the cost in compatibility.

UFCS rox.



 Mar 09 2012



 next sibling parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sat, Mar 10, 2012 at 02:05:38AM +0100, Adam D. Ruppe wrote:
[...]

 What I like about is the encapsulation benefits. You
 don't have to know if the function is a method or an
 external function, it just works.
 
 External, non-friend (so separate module in D) functions
 are often preferable to methods because they don't have
 access to the class' private members, so they cannot rely
 on those implementation details.
 
 Extending objects with new functions in this way also
 means you don't break binary compatibility with the
 existing code, since it isn't modified at all!
 
 
 Of course, you could always do this with the old
 syntax too, but then the syntax preference means
 you are biased toward one implementation or the
 other - it doesn't mesh as well and you may be
 tempted to make things methods for the syntax,
 despite the cost in compatibility.
 
 UFCS rox.


+1. Thanks for bringing this up; this is a very significant benefit.  It
makes it possible for you to adapt a class which you can't change (e.g.,
shipped as a binary-only library) to work with, say, templates that
expect certain class members that aren't there but can be implemented
using what is available.  UFCS makes this possible without lots of
bandaging, mummy-wrapping, or special-casing that adds lots of bloat to
template code.

UFCS also makes it possible to implement operator overloading to make
diverse types work nicely with each other (esp. if you're importing
multiple numerical libraries that don't know of each other's existence).


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond



 Mar 09 2012



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/9/12 5:05 PM, Adam D. Ruppe wrote:

 On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:

 At first I didn't like it a lot because it's cheap syntax sugar that
 adds no new power and gives programmers more freedom to write
 different-looking versions of the the same code (and this is often bad).


 What I like about is the encapsulation benefits. You
 don't have to know if the function is a method or an
 external function, it just works.

 External, non-friend (so separate module in D) functions
 are often preferable to methods because they don't have
 access to the class' private members, so they cannot rely
 on those implementation details.

 Extending objects with new functions in this way also
 means you don't break binary compatibility with the
 existing code, since it isn't modified at all!


 Of course, you could always do this with the old
 syntax too, but then the syntax preference means
 you are biased toward one implementation or the
 other - it doesn't mesh as well and you may be
 tempted to make things methods for the syntax,
 despite the cost in compatibility.

 UFCS rox.


Insert obligatory link: http://drdobbs.com/184401197

Very insightful article.


Andrei



 Mar 09 2012



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jjengv$agm$1 digitalmars.com...

 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


Jesus christ what the FUCK is wrong with Dr Dobbs? The article shows up 
*just fine* - *at first*, and then once all the excess junk around the edges 
finishes loading, the stupid fucking thing redirects me (WITH NO BACK 
BUTTON!) to this useless shit: http://m.drdobbs.com/

What the fuck is wrong with web developers? You'd think at a 
***PROGRAMMING*** MAGAZINE they could fucking get basic shit straight 
without scrwing up things that a NOVICE wouldn't even KNOW how to fuck up! 
Goddamn.

It sounds like a great article, judging by the first paragraph, but I have 
to read it a couple sentences at a time. How the hell do "professions" botch 
things up *that* badly?



 Mar 09 2012



 next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 3/10/12, Nick Sabalausky <a a.a> wrote:

 It sounds like a great article, judging by the first paragraph, but I have
 to read it a couple sentences at a time.


Yikes. Here's a print version:
http://drdobbs.com/article/print?articleId=184401197&siteSectionName=



 Mar 10 2012



prev sibling next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/9/12 11:18 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jjengv$agm$1 digitalmars.com...

 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


 Jesus christ what the FUCK is wrong with Dr Dobbs? The article shows up
 *just fine* - *at first*, and then once all the excess junk around the edges
 finishes loading, the stupid fucking thing redirects me (WITH NO BACK
 BUTTON!) to this useless shit: http://m.drdobbs.com/

 What the fuck is wrong with web developers? You'd think at a
 ***PROGRAMMING*** MAGAZINE they could fucking get basic shit straight
 without scrwing up things that a NOVICE wouldn't even KNOW how to fuck up!
 Goddamn.

 It sounds like a great article, judging by the first paragraph, but I have
 to read it a couple sentences at a time. How the hell do "professions" botch
 things up *that* badly?


Doesn't happen on my machine. Would the printer-friendly view help?

http://drdobbs.com/article/print?articleId=184401197&siteSectionName=


Andrei



 Mar 10 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-03-10 08:18, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jjengv$agm$1 digitalmars.com...

 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


 Jesus christ what the FUCK is wrong with Dr Dobbs? The article shows up
 *just fine* - *at first*, and then once all the excess junk around the edges
 finishes loading, the stupid fucking thing redirects me (WITH NO BACK
 BUTTON!) to this useless shit: http://m.drdobbs.com/

 What the fuck is wrong with web developers? You'd think at a
 ***PROGRAMMING*** MAGAZINE they could fucking get basic shit straight
 without scrwing up things that a NOVICE wouldn't even KNOW how to fuck up!
 Goddamn.

 It sounds like a great article, judging by the first paragraph, but I have
 to read it a couple sentences at a time. How the hell do "professions" botch
 things up *that* badly?


Happens to me as well. Mac OS X, Firefox 10.0.2, JavaScript turned off 
by default.

-- 
/Jacob Carlborg



 Mar 10 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jacob Carlborg" <doob me.com> wrote in message 
news:jjg2ts$2roo$2 digitalmars.com...

 On 2012-03-10 08:18, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jjengv$agm$1 digitalmars.com...

 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


 Jesus christ what the FUCK is wrong with Dr Dobbs? The article shows up
 *just fine* - *at first*, and then once all the excess junk around the 
 edges
 finishes loading, the stupid fucking thing redirects me (WITH NO BACK
 BUTTON!) to this useless shit: http://m.drdobbs.com/

 What the fuck is wrong with web developers? You'd think at a
 ***PROGRAMMING*** MAGAZINE they could fucking get basic shit straight
 without scrwing up things that a NOVICE wouldn't even KNOW how to fuck 
 up!
 Goddamn.

 It sounds like a great article, judging by the first paragraph, but I 
 have
 to read it a couple sentences at a time. How the hell do "professions" 
 botch
 things up *that* badly?


 Happens to me as well. Mac OS X, Firefox 10.0.2, JavaScript turned off by 
 default.


You know what I think it is (without actually looking at the code): I think 
they tried to do some highly misguided and even more poorly implemented hack 
(which they no-doubt thought was clever) for dealing with *cough* "old" 
*cough* browsers by inserting a meta redirect to a hardcoded URL, and then 
used JS to disable the meta redirect. If that's the case, I don't know how 
the fuck they managed to convince themselves that make one drop of sense.

When I used one of my web developer plugins to disable meta redirects, the 
screwy behavior stopped. And like you, I have JS off by default (WTF do you 
need JS for on a goddamn *ARTICLE*?). So that's probably what the numbnuts 
over at Dr Dobbs did.



 Mar 10 2012



 next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday, March 10, 2012 14:41:53 Nick Sabalausky wrote:

 You know what I think it is (without actually looking at the code): I think
 they tried to do some highly misguided and even more poorly implemented hack
 (which they no-doubt thought was clever) for dealing with *cough* "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and then
 used JS to disable the meta redirect. If that's the case, I don't know how
 the fuck they managed to convince themselves that make one drop of sense.
 
 When I used one of my web developer plugins to disable meta redirects, the
 screwy behavior stopped. And like you, I have JS off by default (WTF do you
 need JS for on a goddamn *ARTICLE*?). So that's probably what the numbnuts
 over at Dr Dobbs did.


Well, much as _you_ hate JS, many people don't turn it off, because regardless 
of how good or bad it is, enough relies on it that many would consider it too 
unpleasant to try and use the web with it off. And if everyone's using it, then 
there's no reason _not_ to use JS if you think that it best solves what you're 
trying to do.

Now, normally I wouldn't think that you'd need JS for article, and their 
particular solution may have been a bad one, but it's not like it's uncommon 
for web developers to just assume that you're going to have JS enabled. I 
would think that you'd be running into problems like that all the time with 
the esoteric web browsing setup that you have.

- Jonathan M Davis



 Mar 10 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.433.1331409882.4860.digitalmars-d puremagic.com...

 On Saturday, March 10, 2012 14:41:53 Nick Sabalausky wrote:

 You know what I think it is (without actually looking at the code): I 
 think
 they tried to do some highly misguided and even more poorly implemented 
 hack
 (which they no-doubt thought was clever) for dealing with *cough* "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and 
 then
 used JS to disable the meta redirect. If that's the case, I don't know 
 how
 the fuck they managed to convince themselves that make one drop of sense.

 When I used one of my web developer plugins to disable meta redirects, 
 the
 screwy behavior stopped. And like you, I have JS off by default (WTF do 
 you
 need JS for on a goddamn *ARTICLE*?). So that's probably what the 
 numbnuts
 over at Dr Dobbs did.


 Well, much as _you_ hate JS, many people don't turn it off, because 
 regardless
 of how good or bad it is, enough relies on it that many would consider it 
 too
 unpleasant to try and use the web with it off. And if everyone's using it, 
 then
 there's no reason _not_ to use JS if you think that it best solves what 
 you're
 trying to do.


"Everyone" *isn't* using it (even for a non-literal usage of "everyone").
And I have it turned off because the web is not *not only* "unpleasant" with 
it *on*, but, for me, borderline unusable.


 Now, normally I wouldn't think that you'd need JS for article, and their
 particular solution may have been a bad one, but it's not like it's 
 uncommon
 for web developers


"Common" and "not stupid" are *very* different things. You're making a 
patently false assumption that the former implies the latter.


 I would think that you'd be running into problems like that all the time 
 with
 the esoteric web browsing setup that you have.


It may seem that way, but it's *much* less trouble then what I had before I 
blocked flash (with NoScript), installed AdBlock Plus, and disabled JS (also 
with NoScript). Seriously. No exaggeration. I literally *cannot* read a page 
when there's shit animating around it. You can? Other people can? Most 
people can? I don't give a fuck. Good for you.

Seriosuly, don't even think of using a "*most* people aren't like that" 
argument. Every goddamn thing about me is outside of the holy, sacred 
motherfucking "bell curve of relevence" (Ie: "If you're outside the bell 
cure, you're not relevent"), and has been for my whole goddamn life.

No more. These days, *anyone* who pulls any sort "common case vs exceptional 
case" bullshit excuse around me, for anything, can go fuck themselves.

"Join us! Be just like us! Submit! Conform!" <-- fuck the goddamn idiot 
sheep



 Mar 10 2012



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sat, Mar 10, 2012 at 05:45:33PM -0500, Nick Sabalausky wrote:

  "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
 news:mailman.433.1331409882.4860.digitalmars-d puremagic.com...


[...]

 Well, much as _you_ hate JS, many people don't turn it off, because
 regardless of how good or bad it is, enough relies on it that many
 would consider it too unpleasant to try and use the web with it off.
 And if everyone's using it, then there's no reason _not_ to use JS
 if you think that it best solves what you're trying to do.




The problem is not what JS solves, per se, but the fact that many web
developers use it for no good reason at all besides the fact that it's
the "cool new thing".


[...]

 "Everyone" *isn't* using it (even for a non-literal usage of
 "everyone").  And I have it turned off because the web is not *not
 only* "unpleasant" with it *on*, but, for me, borderline unusable.


I used to do that. :-)

These days, I just can't be bothered what someone does or doesn't do
with JS on their site.  Opera lets me configure scripting on a per-site
basis. As soon as I run into a site that uses annoying scripting, it's
bye-bye scripting for that site forever.

In the past, I've even used UserJS to *edit* the site's JS on the fly to
rewrite stupid JS code (like replace sniffBrowser() with a function that
returns true, bwahahaha) while leaving the rest of the site functional.
I do not merely hate Javascript, I fight it, kill it, and twist it to my
own sinister ends.  >:-)


[...]

 I would think that you'd be running into problems like that all the
 time with the esoteric web browsing setup that you have.




Esoteric?! Really? Whatever happened to those days of graceful
degradation?  Or are we sliding back into the bad ole days of gratuitous
incompatibilities? And here I was, thinking that the W3C was attempting
to make things interoperate...



 It may seem that way, but it's *much* less trouble then what I had
 before I blocked flash (with NoScript), installed AdBlock Plus, and
 disabled JS (also with NoScript). Seriously. No exaggeration. I
 literally *cannot* read a page when there's shit animating around it.


[...]

Opera has content blocking. :-) It's configurable per-site, even. I
actively use it on sites where things flash around for no good reason.
OTOH, when >50% of a site is just random animated junk, I just leave and
never return, 'cos whoever runs the site obviously doesn't have anything
useful to offer me anyway. It's a pretty reliable indicator of site
quality, actually. And of whether I want to bother giving it another
second of my time.


T

-- 
"640K ought to be enough" -- Bill G., 1984. "The Internet is not a
primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on
Microsoft's strategy" -- Bill G., 1999.



 Mar 10 2012



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Sunday, 11 March 2012 at 00:43:15 UTC, H. S. Teoh wrote:

 The problem is not what JS solves, per se, but the fact that 
 many web developers use it for no good reason at all besides
 the fact that it's the "cool new thing".


hey did you guys hear that you can convert a lot of
D code to Javascript?

It's cool. It's new. And it's a thing.

Use it!



 Mar 10 2012



  parent  "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:uzpluzrtlvsspppwwakl forum.dlang.org...

 On Sunday, 11 March 2012 at 00:43:15 UTC, H. S. Teoh wrote:

 The problem is not what JS solves, per se, but the fact that many web 
 developers use it for no good reason at all besides
 the fact that it's the "cool new thing".


 hey did you guys hear that you can convert a lot of
 D code to Javascript?

 It's cool. It's new. And it's a thing.

 Use it!


It's a thing? I gotta have it!

:)



 Mar 10 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.447.1331426602.4860.digitalmars-d puremagic.com...

 On Sat, Mar 10, 2012 at 05:45:33PM -0500, Nick Sabalausky wrote:

 "Everyone" *isn't* using it (even for a non-literal usage of
 "everyone").  And I have it turned off because the web is not *not
 only* "unpleasant" with it *on*, but, for me, borderline unusable.


 I used to do that. :-)

 These days, I just can't be bothered what someone does or doesn't do
 with JS on their site.  Opera lets me configure scripting on a per-site
 basis. As soon as I run into a site that uses annoying scripting, it's
 bye-bye scripting for that site forever.


I use the NoScript addon for FireFox, which does the same thing. But I have 
my default set to "off" because I find that's usually the prefereable 
option. Even on sites that break without JS, viewing them with JS on is 
usually not much better - at least with JS off, they break *quickly* without 
wasting my time spinning their AJAX and jQuery wheels just so they can *sort 
of* work very, very slowly.


 In the past, I've even used UserJS to *edit* the site's JS on the fly to
 rewrite stupid JS code (like replace sniffBrowser() with a function that
 returns true, bwahahaha) while leaving the rest of the site functional.
 I do not merely hate Javascript, I fight it, kill it, and twist it to my
 own sinister ends.  >:-)


I admire that :) Personally, I don't have the patience. I just bitch and 
moan :)


 [...]

 I would think that you'd be running into problems like that all the
 time with the esoteric web browsing setup that you have.




 Esoteric?! Really? Whatever happened to those days of graceful
 degradation?


Why would you want graceful degredation? That would defeat the whole point: 
The whole point of our crusade is to *force* what we *know* to be newer and 
better unto all the unwashed masses.

Along the same lines: How long do you think it'll be before a cellular 
connection starts being required for using the internet? Or just certain 
sites?

Some people may think that's silly, but it's already happened for IM: 
Remember when IM was free ans accessible through *any* internet connection? 
Why was anyone ever willing to use that? Didn't they know get could *pay* to 
get the exact same service thanks to SMS? The IM networks still techincally 
exist, but you can't use them because everyone you'd talk to prefers to pay 
a cell company for SMS. Why use something free and open when you can pay for 
restricted access?


 Or are we sliding back into the bad ole days of gratuitous
 incompatibilities?


When has the web *ever* had that?  (Well, in 1996 maybe.)

But yea, I often feel like we've moved back into the old DOS days when 
software packages didn't interoperate, and data was almost inseperable from 
its software.

In 1994, games had to come with their own sound/video drivers. In 1995, MS 
fixed that and there was much rejoicing.

But in 2012:

- Every piece of content is packaged with a pre-chosen viewer.

- Every web site feels it has to include it's own social networking links.

- If you want to use GitHub/BitBucket-style DVCS features you have to use 
whichever interface is *provided* by whoever's hosting the repo. BitBucket 
can't access GitHub-hosted repos/projects. GitHub can't acces 
BitBucket-histed repos/projects. Neither can access local or self-hosted 
repos/projects. WTF is this, 1990 all over again?

And any mention of "maybe these aren't the best ways" is met with cries of 
"Heresy! Conform, you dinosaur!".


 And here I was, thinking that the W3C was attempting
 to make things interoperate...


Hah! I think the only thing the W3C is attempting to do is see how long they 
can do nothing before people start to call them on it.

Well, that's not fair. It's probably not "nothing". I'm sure there's also a 
bunch of "Google trying to throw their weight around" and "Everyone, ignore 
all the suggestions from MS - they're wrong by default, especially their box 
model, JS mouse-button API, and other such things that make our standards 
appear to be designed by retarded monkeys - it's just their way to trick 
us!".


 It may seem that way, but it's *much* less trouble then what I had
 before I blocked flash (with NoScript), installed AdBlock Plus, and
 disabled JS (also with NoScript). Seriously. No exaggeration. I
 literally *cannot* read a page when there's shit animating around it.


 [...]

 Opera has content blocking. :-) It's configurable per-site, even. I
 actively use it on sites where things flash around for no good reason.


Yup, same with NoScript. It replaces Flash and Java applets with placeholder 
boxes. In the rare cases where I want to view it, I just click it. Per-site 
configurable, too.


 OTOH, when >50% of a site is just random animated junk, I just leave and
 never return, 'cos whoever runs the site obviously doesn't have anything
 useful to offer me anyway. It's a pretty reliable indicator of site
 quality, actually. And of whether I want to bother giving it another
 second of my time.


Yea.


 -- 
 "640K ought to be enough" -- Bill G., 1984. "The Internet is not a
 primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on
 Microsoft's strategy" -- Bill G., 1999.


I've heard that Gates never actually said that "640k" quote. (Don't know 
whether that's true or not, though :/ )



 Mar 10 2012



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.447.1331426602.4860.digitalmars-d puremagic.com...


[...]

 In the past, I've even used UserJS to *edit* the site's JS on the
 fly to rewrite stupid JS code (like replace sniffBrowser() with a
 function that returns true, bwahahaha) while leaving the rest of the
 site functional.  I do not merely hate Javascript, I fight it, kill
 it, and twist it to my own sinister ends.  >:-)


 
 I admire that :) Personally, I don't have the patience. I just bitch
 and moan :)


Well, that was in the past. Nowadays they've smartened up (or is it
dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly
because anything that the client end can run will eventually be cracked,
so it actually doesn't offer *real* protection in the first place, and
OTOH annoying 'cos I really can't be bothered to waste the time and
effort to crack some encrypted code coming from some shady site that
already smells of lousy design and poor implementation anyway.

So I just leave and never come back to the site.


[...]

 In 1994, games had to come with their own sound/video drivers. In
 1995, MS fixed that and there was much rejoicing.
 
 But in 2012:
 
 - Every piece of content is packaged with a pre-chosen viewer.


Blame flash. And JS.


[...]

 - If you want to use GitHub/BitBucket-style DVCS features you have to
 use whichever interface is *provided* by whoever's hosting the repo.
 BitBucket can't access GitHub-hosted repos/projects. GitHub can't
 acces BitBucket-histed repos/projects. Neither can access local or
 self-hosted repos/projects. WTF is this, 1990 all over again?


Yeah seriously. So much for "semantic web". Smells like a pipe dream to
me.


[...]

 "640K ought to be enough" -- Bill G., 1984. "The Internet is not a
 primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on
 Microsoft's strategy" -- Bill G., 1999.


 
 I've heard that Gates never actually said that "640k" quote. (Don't
 know whether that's true or not, though :/ )


[...]

Ahh, the stuff that urban legends are made of...


T

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



 Mar 10 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.454.1331448329.4860.digitalmars-d puremagic.com...

 On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.447.1331426602.4860.digitalmars-d puremagic.com...


 [...]

 In the past, I've even used UserJS to *edit* the site's JS on the
 fly to rewrite stupid JS code (like replace sniffBrowser() with a
 function that returns true, bwahahaha) while leaving the rest of the
 site functional.  I do not merely hate Javascript, I fight it, kill
 it, and twist it to my own sinister ends.  >:-)


 I admire that :) Personally, I don't have the patience. I just bitch
 and moan :)


 Well, that was in the past. Nowadays they've smartened up (or is it
 dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly
 because anything that the client end can run will eventually be cracked,
 so it actually doesn't offer *real* protection in the first place, and
 OTOH annoying 'cos I really can't be bothered to waste the time and
 effort to crack some encrypted code coming from some shady site that
 already smells of lousy design and poor implementation anyway.

 So I just leave and never come back to the site.


I'd prefer to do that (leave and never come back), but unfortunately, the 
modern regression of tying data/content to the interface often makes that 
impossible:

For example, I can't see what materials my library has available, or manage 
my own library account, without using *their* crappy choice of software. 
It's all just fucking data! Crap, DBs are an age-old thing.

Or, I'd love to be able leave GitHub and never come back. But DMD is on 
GitHub, so I can't create/browse/review pull requests, check what public 
forks are available, etc., without using GitHub's piece of shit site.

I'd love to leave Google Code, Google Docs and YouTube and never come back, 
but people keep posting their content on those shitty sites which, 
naturally, prevent me from accessing said content in any other way.

Etc...

And most of that is all just because some idiots decided to start treating a 
document-transmission medium as an applications platform.

I swear to god, interoperability was better in the 80's.

(And jesus christ, *Google Docs*?!? How the fuck did we ever get a document 
platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people actually 
*TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out 
the free crazy-pills?)


 [...]

 In 1994, games had to come with their own sound/video drivers. In
 1995, MS fixed that and there was much rejoicing.

 But in 2012:

 - Every piece of content is packaged with a pre-chosen viewer.


 Blame flash. And JS.


It's more than that. Even without one line of JS or Flash, a purely 
(X)HTML/CSS web app is *still* likely tying content to interface. The only 
exceptions are things like forum.dlang.org which merely present data from an 
already-publically-accessible external source. Of course, even *then* the 
URLs are still tied to the (inevitably web-based) NG client (What's needed 
is a universal NNTP URL system that's 100% independent of NG client - Just 
like we already have for HTTP, and FTP, and SSH and five billion other damn 
things. Image that!)


 [...]

 - If you want to use GitHub/BitBucket-style DVCS features you have to
 use whichever interface is *provided* by whoever's hosting the repo.
 BitBucket can't access GitHub-hosted repos/projects. GitHub can't
 acces BitBucket-histed repos/projects. Neither can access local or
 self-hosted repos/projects. WTF is this, 1990 all over again?


 Yeah seriously. So much for "semantic web". Smells like a pipe dream to
 me.


Yup. Fortunately, HTTP APIs are becoming more and more common though, so at 
least there's that ray of hope that some of those can consolodate into some 
standards.

Speaking of all of this though, I have to *rave* about Linode: I just 
switched to them from my old (and recently bought-out) shared web host a few 
days ago, and already I *LOVE* it. Not only is it a fantastic service all 
around, and they *actually* seem to know what they're doing (unlike *every* 
shared web host I've *ever* encountered), but *everything* about their site 
and control panel is *PERFECT*. Absolutely flawless, from the functionality 
and content, to the security, the speed, the compatibility and graceful 
degredation, all the way down to just simply the *style*: Flawless every 
step of the way. And they offer an HTTP API for the control panel. I can't 
remember the last time I saw a site this *professional* and well built. It's 
one of those exceedingly rare things that's created by grown-ups, for 
grown-ups. I'm genuinely stunned by it.



 Mar 11 2012



  parent reply Ary Manzana <ary esperanto.org.ar>  writes:


On 03/11/2012 05:47 AM, Nick Sabalausky wrote:

 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote in message
 news:mailman.454.1331448329.4860.digitalmars-d puremagic.com...

 On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote in message
 news:mailman.447.1331426602.4860.digitalmars-d puremagic.com...


 [...]

 In the past, I've even used UserJS to *edit* the site's JS on the
 fly to rewrite stupid JS code (like replace sniffBrowser() with a
 function that returns true, bwahahaha) while leaving the rest of the
 site functional.  I do not merely hate Javascript, I fight it, kill
 it, and twist it to my own sinister ends.>:-)


 I admire that :) Personally, I don't have the patience. I just bitch
 and moan :)


 Well, that was in the past. Nowadays they've smartened up (or is it
 dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly
 because anything that the client end can run will eventually be cracked,
 so it actually doesn't offer *real* protection in the first place, and
 OTOH annoying 'cos I really can't be bothered to waste the time and
 effort to crack some encrypted code coming from some shady site that
 already smells of lousy design and poor implementation anyway.

 So I just leave and never come back to the site.


 I'd prefer to do that (leave and never come back), but unfortunately, the
 modern regression of tying data/content to the interface often makes that
 impossible:

 For example, I can't see what materials my library has available, or manage
 my own library account, without using *their* crappy choice of software.
 It's all just fucking data! Crap, DBs are an age-old thing.

 Or, I'd love to be able leave GitHub and never come back. But DMD is on
 GitHub, so I can't create/browse/review pull requests, check what public
 forks are available, etc., without using GitHub's piece of shit site.

 I'd love to leave Google Code, Google Docs and YouTube and never come back,
 but people keep posting their content on those shitty sites which,
 naturally, prevent me from accessing said content in any other way.

 Etc...

 And most of that is all just because some idiots decided to start treating a
 document-transmission medium as an applications platform.

 I swear to god, interoperability was better in the 80's.

 (And jesus christ, *Google Docs*?!? How the fuck did we ever get a document
 platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people actually
 *TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out
 the free crazy-pills?)


Nick, how would you implement (protocols, architecture, whatever) an 
online document editor?



 Mar 11 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jjis50$23se$1 digitalmars.com...

 On 03/11/2012 05:47 AM, Nick Sabalausky wrote:

 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote in message
 news:mailman.454.1331448329.4860.digitalmars-d puremagic.com...

 On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote in message
 news:mailman.447.1331426602.4860.digitalmars-d puremagic.com...


 [...]

 In the past, I've even used UserJS to *edit* the site's JS on the
 fly to rewrite stupid JS code (like replace sniffBrowser() with a
 function that returns true, bwahahaha) while leaving the rest of the
 site functional.  I do not merely hate Javascript, I fight it, kill
 it, and twist it to my own sinister ends.>:-)


 I admire that :) Personally, I don't have the patience. I just bitch
 and moan :)


 Well, that was in the past. Nowadays they've smartened up (or is it
 dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly
 because anything that the client end can run will eventually be cracked,
 so it actually doesn't offer *real* protection in the first place, and
 OTOH annoying 'cos I really can't be bothered to waste the time and
 effort to crack some encrypted code coming from some shady site that
 already smells of lousy design and poor implementation anyway.

 So I just leave and never come back to the site.


 I'd prefer to do that (leave and never come back), but unfortunately, the
 modern regression of tying data/content to the interface often makes that
 impossible:

 For example, I can't see what materials my library has available, or 
 manage
 my own library account, without using *their* crappy choice of software.
 It's all just fucking data! Crap, DBs are an age-old thing.

 Or, I'd love to be able leave GitHub and never come back. But DMD is on
 GitHub, so I can't create/browse/review pull requests, check what public
 forks are available, etc., without using GitHub's piece of shit site.

 I'd love to leave Google Code, Google Docs and YouTube and never come 
 back,
 but people keep posting their content on those shitty sites which,
 naturally, prevent me from accessing said content in any other way.

 Etc...

 And most of that is all just because some idiots decided to start 
 treating a
 document-transmission medium as an applications platform.

 I swear to god, interoperability was better in the 80's.

 (And jesus christ, *Google Docs*?!? How the fuck did we ever get a 
 document
 platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people 
 actually
 *TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out
 the free crazy-pills?)


 Nick, how would you implement (protocols, architecture, whatever) an 
 online document editor?


I wouldn't make it an online editor. Just let a normal editor access remote 
files. Done. As for specifically html documents on the web, doesn't http 
already have provisions for updating anyway? Hell, the *original* web 
browser was *both* an editor and a viewer. But then Mosaic came along, 
scrapped the editor part, and everything since has followed suit.



 Mar 11 2012



  parent reply Stewart Gordon <smjg_1998 yahoo.com>  writes:


On 11/03/2012 19:44, Nick Sabalausky wrote:
<snip>

 I wouldn't make it an online editor.  Just let a normal editor
 access remote files.  Done.  As for specifically html documents on
 the web, doesn't http already have provisions for updating anyway?


HTTP has a PUT method, but I'm not sure it's widely supported.  Nowadays,
practically 
everyone uses FTP to upload web pages.  Either that or a web-based file manager
such as 
free hosts tend to provide instead of FTP access.


 Hell, the *original* web browser was *both* an editor and a viewer.


What kind of editor - raw HTML, WYSIWYM, WYSINWYG or something else entirely?


 But then Mosaic came along, scrapped the editor part, and
 everything since has followed suit.


I guess the authors of Mosaic were bothered about enabling people to browse the
web, 
rather than to create web pages.

But there were a few other combined browsers and editors to come, like Netscape
Navigator 
Gold (the editor part of which later broke away into Netscape Composer, or so I
was told)....

Stewart.



 Mar 11 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:jjj6lo$2ojb$1 digitalmars.com...

 On 11/03/2012 19:44, Nick Sabalausky wrote:
 <snip>

 I wouldn't make it an online editor.  Just let a normal editor
 access remote files.  Done.  As for specifically html documents on
 the web, doesn't http already have provisions for updating anyway?


 HTTP has a PUT method, but I'm not sure it's widely supported.  Nowadays, 
 practically everyone uses FTP to upload web pages.  Either that or a 
 web-based file manager such as free hosts tend to provide instead of FTP 
 access.


Yea, but it doesn't have to be that way. Browsers have moved away from HTTP 
for such things and don't even support it, so most people don't even know 
that it's always been (supposed to be) possible.


 Hell, the *original* web browser was *both* an editor and a viewer.


 What kind of editor - raw HTML, WYSIWYM, WYSINWYG or something else 
 entirely?


I'm not sure. Probably raw HTML I would guess, but obviously it could have 
been implemented to do it in any mannar. You can probably look it up on 
Wikipedia. IIRC, it was actually *named* either "WWW" or "World Wide Web".


 But then Mosaic came along, scrapped the editor part, and
 everything since has followed suit.


 I guess the authors of Mosaic were bothered about enabling people to 
 browse the web, rather than to create web pages.

 But there were a few other combined browsers and editors to come, like 
 Netscape Navigator Gold (the editor part of which later broke away into 
 Netscape Composer, or so I was told)....


Interesting, I'd never even heard of that. I think I've heard the name 
"Netscape Composer" but just assumed it was an email client.



 Mar 11 2012



  parent  Stewart Gordon <smjg_1998 yahoo.com>  writes:


On 11/03/2012 22:36, Nick Sabalausky wrote:
<snip>

 Hell, the *original* web browser was *both* an editor and a viewer.


 What kind of editor - raw HTML, WYSIWYM, WYSINWYG or something else
 entirely?


 I'm not sure. Probably raw HTML I would guess, but obviously it could have
 been implemented to do it in any mannar. You can probably look it up on
 Wikipedia. IIRC, it was actually *named* either "WWW" or "World Wide Web".


<snip>

It was WorldWideWeb actually.  Later renamed to Nexus as the original name was
deemed 
confusing.

Stewart.



 Mar 11 2012



prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sat, Mar 10, 2012 at 02:41:53PM -0500, Nick Sabalausky wrote:
[...]

 You know what I think it is (without actually looking at the code): I
 think they tried to do some highly misguided and even more poorly
 implemented hack (which they no-doubt thought was clever) for dealing
 with *cough* "old" *cough* browsers by inserting a meta redirect to a
 hardcoded URL, and then used JS to disable the meta redirect. If
 that's the case, I don't know how the fuck they managed to convince
 themselves that make one drop of sense.
 
 When I used one of my web developer plugins to disable meta redirects,
 the screwy behavior stopped. And like you, I have JS off by default
 (WTF do you need JS for on a goddamn *ARTICLE*?). So that's probably
 what the numbnuts over at Dr Dobbs did.


[...]

I've always believed that Javascript is the hellspawn of evil incarnate.

Last year when at my day job a large-scale Javascript project was dumped
on my lap, I spent 1/2 a week's time to update myself on the language
(as well as understand that morass of lasagna code I had to work with),
and I discovered that Javascript has some really neat features, like
closures (that's why I find D's delegates so immensely useful), and that
overall, it's a not-bad language for doing neat stuff in. Especially if
you use jQuery, which almost feels like it belongs in the Javascript
spec.

I still believe that Javascript is the hellspawn of evil incarnate.

The web was originally a pull medium: you want to lookup a resource, you
send a request, the server returns a document. Nowhere in this picture
is interactivity. Oh, did they tried to make it more interactive.
Cookies, sessions, and what not, it's all an effort to make a stateless
HTTP protocol "feel" like it's interactive. The marketroids loved push
media.  They wanted more 'push' on the web. Then somebody came up with
the idea of running script snippets on the browser instead of the
server. So Javascript was born.

I've always believed that Javascript is the hellspawn of evil incarnate.

Having arbitrary Turing-complete code run on your browser just because
you asked the server "please send me resource X" is, shall we say, a
security concern? So they came up with the whole XSS thing to try to
contain the beast, along with various other kludges to try to patch
various problems that came up, and then patch the problems that the
patches introduced, ad nauseum.

But Javascript is still the hellspawn of evil incarnate.

Git-pull a couple o' years, and here we are today with a web that's
increasingly interactive, and Javascript is an essential part of it.
Whether or not that's a good thing, public opinion is generally
positive. Heck, I myself wrote an application in Javascript, actually
*two*, just because tools have developed to make it so *easy*.

I still believe that Javascript is the hellspawn of evil incarnate.

In fact, it's so easy that everybody and his neighbor's dog writes
Javascript on their website. Even if the website is essentially nothing
but a bunch of articles. Resources that you look up by sending a request
to a server and getting a document in return. Like the good ole days
when the web was a pull medium. Except now almost everything comes with
Javascript, even when it's not needed. And because it's so pervasive,
it's only a matter of time before somebody gets this bright idea that
whoever browses the web *without* Javascript must be certainly be using
an ancient dilapidated browser from before the dinosaurs walked the
earth.

So you see, Javascript is the hellspawn of evil incarnate. :-)


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.



 Mar 10 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-03-10 21:27, H. S. Teoh wrote:

 On Sat, Mar 10, 2012 at 02:41:53PM -0500, Nick Sabalausky wrote:
 [...]

 You know what I think it is (without actually looking at the code): I
 think they tried to do some highly misguided and even more poorly
 implemented hack (which they no-doubt thought was clever) for dealing
 with *cough* "old" *cough* browsers by inserting a meta redirect to a
 hardcoded URL, and then used JS to disable the meta redirect. If
 that's the case, I don't know how the fuck they managed to convince
 themselves that make one drop of sense.

 When I used one of my web developer plugins to disable meta redirects,
 the screwy behavior stopped. And like you, I have JS off by default
 (WTF do you need JS for on a goddamn *ARTICLE*?). So that's probably
 what the numbnuts over at Dr Dobbs did.


 [...]

 I've always believed that Javascript is the hellspawn of evil incarnate.


I usually agree, but there are useful and cool things you can do with 
JavaScript. Two of the tools I'm using when I'm doing web development 
uses JavaScript:

* LiveReload - A browser plugin that  will automatically reload the a 
web page when a file has changed in a specified folder.

http://livereload.com/

* TextMate Rails stack trace - A greasemonkey script that will make your 
stack trace lines open in TextMate

https://github.com/ryankshaw/rails-stacktrace-textmate-linker-greasemonkey-script


-- 
/Jacob Carlborg



 Mar 11 2012



  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sun, Mar 11, 2012 at 01:45:19PM +0100, Jacob Carlborg wrote:

 On 2012-03-10 21:27, H. S. Teoh wrote:


[...]

I've always believed that Javascript is the hellspawn of evil
incarnate.


 
 I usually agree, but there are useful and cool things you can do
 with JavaScript. Two of the tools I'm using when I'm doing web
 development uses JavaScript:


[...]

Oh, I know how useful it is. I've written some cool stuff with it too.
That's what makes it so evil. :-) It's so cool and so easy to write,
that everybody and his neighbour's dog writes it and sticks it
everywhere it doesn't belong.


T

-- 
Change is inevitable, except from a vending machine.



 Mar 11 2012



prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 3/10/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 I've always believed that Javascript is the hellspawn of evil incarnate.


You and Nick just became best friends! :P



 Mar 10 2012



  parent  "Nick Sabalausky" <a a.a>  writes:


"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.441.1331421065.4860.digitalmars-d puremagic.com...

 On 3/10/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 I've always believed that Javascript is the hellspawn of evil incarnate.


 You and Nick just became best friends! :P


No no, he's speaking heresy. Javascript *is* evil incarnate. It's also evil 
carnitas and semi-evil carnies. What whacko would think it's the hellspawn 
*of* evil incarnate? That's just silly!



 Mar 10 2012



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-03-10 20:41, Nick Sabalausky wrote:


 You know what I think it is (without actually looking at the code): I think
 they tried to do some highly misguided and even more poorly implemented hack
 (which they no-doubt thought was clever) for dealing with *cough* "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and then
 used JS to disable the meta redirect. If that's the case, I don't know how
 the fuck they managed to convince themselves that make one drop of sense.


But they're redirecting to http://m.drdobbs.com/, which seems to be 
adapted for mobile devices.


 When I used one of my web developer plugins to disable meta redirects, the
 screwy behavior stopped. And like you, I have JS off by default (WTF do you
 need JS for on a goddamn *ARTICLE*?). So that's probably what the numbnuts
 over at Dr Dobbs did.


Yeah, probably.

-- 
/Jacob Carlborg



 Mar 11 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jacob Carlborg" <doob me.com> wrote in message 
news:jji5fa$qma$1 digitalmars.com...

 On 2012-03-10 20:41, Nick Sabalausky wrote:


 You know what I think it is (without actually looking at the code): I 
 think
 they tried to do some highly misguided and even more poorly implemented 
 hack
 (which they no-doubt thought was clever) for dealing with *cough* "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and 
 then
 used JS to disable the meta redirect. If that's the case, I don't know 
 how
 the fuck they managed to convince themselves that make one drop of sense.


 But they're redirecting to http://m.drdobbs.com/, which seems to be 
 adapted for mobile devices.


Mobile sites have traditionally required less-fancy implementations, so it's 
not unreasonable to think that some sites would use their mobile version 
*as* their low-tech fallback version. That's becoming less and less true 
these days, of course. But looking at http://m.drdobbs.com/ I have a strong 
feeling that was originally created for things like AvantGo (ie, on PalmOS) 
which really were very limited: no JS, no nested tables, very low 
resolution, often not even any color, very low memory, etc. Not that 
anything about what they're doing really makes a whole lot of sense anyway, 
though.



 Mar 11 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-03-11 20:55, Nick Sabalausky wrote:

 Mobile sites have traditionally required less-fancy implementations, so it's
 not unreasonable to think that some sites would use their mobile version
 *as* their low-tech fallback version. That's becoming less and less true
 these days, of course. But looking at http://m.drdobbs.com/ I have a strong
 feeling that was originally created for things like AvantGo (ie, on PalmOS)
 which really were very limited: no JS, no nested tables, very low
 resolution, often not even any color, very low memory, etc. Not that
 anything about what they're doing really makes a whole lot of sense anyway,
 though.


Actually, on some sites I use the mobile version, on the desktop. Just 
because it's so much more clean and not as verbose.

-- 
/Jacob Carlborg



 Mar 12 2012



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky <a a.a> wrote:


 You know what I think it is (without actually looking at the code): I  
 think
 they tried to do some highly misguided and even more poorly implemented  
 hack
 (which they no-doubt thought was clever) for dealing with *cough* "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and  
 then
 used JS to disable the meta redirect. If that's the case, I don't know  
 how
 the fuck they managed to convince themselves that make one drop of sense.


It could be that they don't care to cater to people who hate JS.  There  
aren't that many of you.

You may want to consider -- if you on principle don't view pages with  
information because the pages contain JS, you are the one missing out on  
the information.

If you worked for my company, and you didn't like JS, you'd have a tough  
(actually impossible) time using the web application we have for tracking  
things.

-Steve



 Mar 12 2012



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.wa1432xjeav7ka localhost.localdomain...

 On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky <a a.a> wrote:


 You know what I think it is (without actually looking at the code): I 
 think
 they tried to do some highly misguided and even more poorly implemented 
 hack
 (which they no-doubt thought was clever) for dealing with *cough* "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and 
 then
 used JS to disable the meta redirect. If that's the case, I don't know 
 how
 the fuck they managed to convince themselves that make one drop of sense.


 It could be that they don't care to cater to people who hate JS.  There 
 aren't that many of you.


There are enough. And it's beside the point anyway. Things that don't need 
JS sholdn't be using JS anyway, regardless of whether you hate it or have 
enough brain damage to think it's the greatest thing since the transistor.



 Mar 12 2012



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 12 Mar 2012 15:27:30 -0400, Nick Sabalausky <a a.a> wrote:


 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.wa1432xjeav7ka localhost.localdomain...

 On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky <a a.a> wrote:


 You know what I think it is (without actually looking at the code): I
 think
 they tried to do some highly misguided and even more poorly implemented
 hack
 (which they no-doubt thought was clever) for dealing with *cough* "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and
 then
 used JS to disable the meta redirect. If that's the case, I don't know
 how
 the fuck they managed to convince themselves that make one drop of  
 sense.


 It could be that they don't care to cater to people who hate JS.  There
 aren't that many of you.


 There are enough.


Apparently not.  
http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/

I'm perfectly willing to give up on 1-2% of Internet users who have JS  
disabled.


 And it's beside the point anyway. Things that don't need
 JS sholdn't be using JS anyway, regardless of whether you hate it or have
 enough brain damage to think it's the greatest thing since the  
 transistor.


No, it *is* the point.  As a web developer, javascript is used by the vast  
majority of users, so I assume it can be used.  If you don't like that, I  
guess that's too bad for you, you may go find content elsewhere.  It's not  
worth my time to cater to you.

It's like saying you think cell phones are evil, and refuse to get one.   
But then complain that there are no pay phones for you to use, and demand  
businesses install pay phones in case people like you want to use them.

That being said, I found it quite funny that wikipedia last year "blacked  
out" itself using javascript.  I just so happened to want to quote  
something from wikipedia, and noticed the site came up, then had a black  
page put over it.  I just disabled javascript, and could happily use the  
site, posting the link (of course, I had to mention it would only work  
tomorrow when the blackout ended).

-Steve



 Mar 12 2012



 next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


 It could be that they don't care to cater to people who hate 
 JS.  There
 aren't that many of you.


 There are enough.


 Apparently not. 
 http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/

 I'm perfectly willing to give up on 1-2% of Internet users who 
 have JS disabled.


  I use NoScript, so by default my JS is disabled for 99% of the 
sites I go to. That means you'll give up on me? Hmm :(


 And it's beside the point anyway. Things that don't need
 JS sholdn't be using JS anyway, regardless of whether you hate 
 it or have
 enough brain damage to think it's the greatest thing since the 
 transistor.


 No, it *is* the point.  As a web developer, javascript is used 
 by the vast majority of users, so I assume it can be used.  If 
 you don't like that, I guess that's too bad for you, you may go 
 find content elsewhere.  It's not worth my time to cater to you.


  Unfortunately I need to disagree with you there. JS although is 
nice sometimes, I find more often a pain in the butt rather than 
a help. NoScript shows on quite a few sites that they have some 
10 or 20 sites they reference JS scripts from, which doesn't make 
sense. half of those sites tend to be statistic gathering sites, 
which I don't particularly trust. Actually I don't trust a lot of 
sites.

  Plus I'm a little more anal about what does and does not run on 
my computer; Last think I need when I open a Page is it loads ten 
or twenty extra things I don't care about, takes up resources I 
don't want to give up, uses more memory, and for a tiny 
convenience, or trying to make it more an 'application' 
experience rather than a web Page. In my mind, JS should be used 
to help you where HTML and CSS cannot go. Checking inputs for a 
form post, some menus, etc.

  I have refused to go to some sites that require you to disable 
NoScript or Adblocker Plus; I'm willing to allow access past 
those features it for my one or two visits but I refuse to 
disable/remove it. I just feel safer that way. I wonder if I 
didn't have it, how many gigs I would be waiting and using for 
ads and other useless crap.


 It's like saying you think cell phones are evil, and refuse to 
 get one.  But then complain that there are no pay phones for 
 you to use, and demand businesses install pay phones in case 
 people like you want to use them.


  Maybe... I consider myself simple and practical; I use features 
and items that serve their purpose (Usually specific). I enjoy a 
simple cell phone, no bells, no whistles. Give me access to 
dialing a number, hold a small list of names and numbers I dial 
recently or enter in, time and date. That's all I ever want. 
Instead they are pushing cell phones that are actually 
mini-computers (Android and smart phones); Nothing wrong with 
that I guess, but I just want a phone, nothing special.

  In the same regard you can compare that people could refuse to 
use a phone booth unless it has a computer hooked up, internet 
access, use it to check email and browse while you talk, or 
doesn't allow you to send text messages and enter a quarter to 
send it, and doesn't have a camera you can snap a picture of 
yourself to show how good or drunk you are to your friends.



 Mar 12 2012



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 12 Mar 2012 17:19:49 -0400, Era Scarecrow <rtcvb32 yahoo.com>  
wrote:


 Apparently not.  
 http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/

 I'm perfectly willing to give up on 1-2% of Internet users who have JS  
 disabled.


   I use NoScript, so by default my JS is disabled for 99% of the sites I  
 go to. That means you'll give up on me? Hmm :(


Yep.  Sorry to be harsh about it, but if you really don't want to use my  
application the way it's intended, I have no way of helping you.


 No, it *is* the point.  As a web developer, javascript is used by the  
 vast majority of users, so I assume it can be used.  If you don't like  
 that, I guess that's too bad for you, you may go find content  
 elsewhere.  It's not worth my time to cater to you.


   Unfortunately I need to disagree with you there. JS although is nice  
 sometimes, I find more often a pain in the butt rather than a help.  
 NoScript shows on quite a few sites that they have some 10 or 20 sites  
 they reference JS scripts from, which doesn't make sense. half of those  
 sites tend to be statistic gathering sites, which I don't particularly  
 trust. Actually I don't trust a lot of sites.


In the case of my web apps, they do *not* pull JS from other sites.  I  
understand and sympathize with your rationale.  It's just not enough,  
however, to make web developers who want their site to appear a certain  
way care about the market share that your opinion represents.  I'm  
perfectly willing to lose 1-2% of users in order to *not* test browsers in  
all kinds of weird configurations.  It's the same reason most web sites  
test only with the major browsers.


 It's like saying you think cell phones are evil, and refuse to get  
 one.  But then complain that there are no pay phones for you to use,  
 and demand businesses install pay phones in case people like you want  
 to use them.


   Maybe... I consider myself simple and practical; I use features and  
 items that serve their purpose (Usually specific). I enjoy a simple cell  
 phone, no bells, no whistles. Give me access to dialing a number, hold a  
 small list of names and numbers I dial recently or enter in, time and  
 date. That's all I ever want. Instead they are pushing cell phones that  
 are actually mini-computers (Android and smart phones); Nothing wrong  
 with that I guess, but I just want a phone, nothing special.

   In the same regard you can compare that people could refuse to use a  
 phone booth unless it has a computer hooked up, internet access, use it  
 to check email and browse while you talk, or doesn't allow you to send  
 text messages and enter a quarter to send it, and doesn't have a camera  
 you can snap a picture of yourself to show how good or drunk you are to  
 your friends.


This situation (where payphones were obsolete) existed long before the  
smartphone craze.

-Steve



 Mar 12 2012



  parent reply "Era Scarecrow" <rtcvb32 yahoo.com>  writes:


 In the case of my web apps, they do *not* pull JS from other 
 sites.  I understand and sympathize with your rationale.  It's 
 just not enough, however, to make web developers who want their 
 site to appear a certain way care about the market share that 
 your opinion represents.  I'm perfectly willing to lose 1-2% of 
 users in order to *not* test browsers in all kinds of weird 
 configurations.  It's the same reason most web sites test only 
 with the major browsers.


  I'm reminded of a mathematical answer involving large numbers 
and theory. No I never took college level math, but I've heard 
this from somewhere: 'If you take infinity, Divide it by 
Infinity, you will still have a remainder of infinity'.

  1-2% seems small, yet large at the same time. It's not 'the 
majority' but then again 'the majority' are idiots (Example: IE 
with it's VBScript, and outlook express bypassing almost all 
security measures at the time).

  Let's assume you make a site for power users, those who want to 
buy computer parts and books and related stuff like that. Now if 
you require JS to have it run, and all the power users refuse to 
use JS, you've just killed all your customers. a 6 Million 
customers with orders which could get hundreds of millions of 
dollars, lost because a non-JS wasn't offered. Don't know about 
you, but 6 millions people could make or break your business 
(Just my opinion).

  Although unlikely, what if a number of those millions don't have 
a high speed internet connection, perhaps borrowing a connection 
from a neighbor or allotted a slow amount. Do you really want to 
wait 2-3 minutes for a Page to load when 10-15 seconds in that 
case would do for raw text (and optional pictures)?

  Personally, I've used Lynx in the past. Yes it's outdated, yes 
it is non-graphical, yes on many things. But it's fast, small, 
has a tiny footprint, and is great for quite a bit of stuff. As 
memory serves me, it was one of the best browsers I ever used.


 This situation (where payphones were obsolete) existed long 
 before the smartphone craze.


  Perhaps... I may be giving up my cell phone and having no phone 
connection. I'd buy a phone card soon, guess what I'd be using if 
I do need to make a phone call? :P Cell phones and TV are being 
pushed too hard, for less benefit unless you need to use them a 
lot.



 Mar 12 2012



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Era Scarecrow" <rtcvb32 yahoo.com> wrote in message 
news:kbvwixcrdcgakjigjezu forum.dlang.org...

 This situation (where payphones were obsolete) existed long before the 
 smartphone craze.


  Perhaps... I may be giving up my cell phone and having no phone 
 connection. I'd buy a phone card soon, guess what I'd be using if I do 
 need to make a phone call? :P Cell phones and TV are being pushed too 
 hard, for less benefit unless you need to use them a lot.


I'm reminded of one of my favorite Futurama scenes where Hermes sees what he 
thinks is an ordinary run-of-the-mill suicide booth, realizes it's actually 
a phone, and exclaims something like "Wow! They put phones in booths now? 
That's great! Now I don't have to lug this thing around everywhere!" and 
tosses his cell in the trash.

I do actually miss pay phones. But at the same time, maintaining phone 
booths has *FAR* more overhead than not requiring JS, so I don't really 
complain about it. Plus I only have reason to use them maybe 1-4 times per 
*year*, wheras the web I need to use all the time.

I'd really like to get a WiFi phone actually, and use some free or cheap 
VoIP service. Yea, WiFi connections are a lot less prevailent (at least in 
the US) than cell reception, but it'd be good enough for me. You may not 
think it from the way I drone on and on in this NG, but I really don't talk 
on phones much.



 Mar 12 2012



prev sibling  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 12 Mar 2012 20:50:38 -0400, Era Scarecrow <rtcvb32 yahoo.com>  
wrote:


   Let's assume you make a site for power users, those who want to buy  
 computer parts and books and related stuff like that. Now if you require  
 JS to have it run, and all the power users refuse to use JS, you've just  
 killed all your customers. a 6 Million customers with orders which could  
 get hundreds of millions of dollars, lost because a non-JS wasn't  
 offered. Don't know about you, but 6 millions people could make or break  
 your business (Just my opinion).


All the arguments that say you shouldn't require javascript seem to center  
around some estimated (and frankly, wildly exaggerated) number of people  
who have disabled javascript *and* won't turn it on to use a specific  
site.  It seems you all have ignored or discredited the data I quoted  
which is *actual measured data*.

If we can't agree on facts, it seems we can't really have a rational  
argument, so I'll respectfully step away from this.

-Steve



 Mar 14 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.wa2pimkxeav7ka localhost.localdomain...

 On Mon, 12 Mar 2012 15:27:30 -0400, Nick Sabalausky <a a.a> wrote:


 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.wa1432xjeav7ka localhost.localdomain...

 On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky <a a.a> wrote:


 You know what I think it is (without actually looking at the code): I
 think
 they tried to do some highly misguided and even more poorly implemented
 hack
 (which they no-doubt thought was clever) for dealing with *cough* "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and
 then
 used JS to disable the meta redirect. If that's the case, I don't know
 how
 the fuck they managed to convince themselves that make one drop of 
 sense.


 It could be that they don't care to cater to people who hate JS.  There
 aren't that many of you.


 There are enough.


 Apparently not. 
 http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/

 I'm perfectly willing to give up on 1-2% of Internet users who have JS 
 disabled.


Does nobody understand basic statistics?

First of all, 1-2% is a *hell* of a *LOT* of people. Don't be fooled by the 
seemingly small number: It's a percentage and it's out of a *very* large 
population. So 1-2% is still *huge*.

Secondly, I don't believe for a minute that such figures accurately 
represent *all* non-JS users:

A. Most non-JS users *do* occasionally switch JS on when they need to via 
NoScript, etc. So that right there is *guaranteed* to leave the results 
biased towards the "use JS" side.

B. Look at audience: That's *Yahoo*. How many of the technical people you 
know use Yahoo? Yahoo is primarily an "Average Joe" site, but disabling 
JavaScript is a power-user thing. It's not a representative sample, and it 
*certainly* can't be assumed to be applicable to something like Dr. Dobbs.

C. Things such as Google Analytics are based on JS. So right there I have 
questions about whether or not such things accurately record all non-JS 
users in the first place.



 And it's beside the point anyway. Things that don't need
 JS sholdn't be using JS anyway, regardless of whether you hate it or have
 enough brain damage to think it's the greatest thing since the 
 transistor.


 No, it *is* the point.  As a web developer, javascript is used by the vast 
 majority of users, so I assume it can be used.  If you don't like that, I 
 guess that's too bad for you, you may go find content elsewhere.  It's not 
 worth my time to cater to you.


And it's not worth my time to use your piece of shit excuse for a site.



 Mar 12 2012



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 3/12/12 6:02 PM, Nick Sabalausky wrote:

 Does nobody understand basic statistics?


I don't see evidence they don't.


 First of all, 1-2% is a *hell* of a *LOT* of people. Don't be fooled by the
 seemingly small number: It's a percentage and it's out of a *very* large
 population. So 1-2% is still *huge*.


This is a truism. Yeah, 1% is huge but the rest is 99 times huger. It's 
a reasonable business decision to forgo 1-2% reach (and therefore 
potential profit) if the cost of that reach is larger than the projected 
increase in the profit.


Andrei



 Mar 12 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jjm057$1val$1 digitalmars.com...

 On 3/12/12 6:02 PM, Nick Sabalausky wrote:

 Does nobody understand basic statistics?


 I don't see evidence they don't.


 First of all, 1-2% is a *hell* of a *LOT* of people. Don't be fooled by 
 the
 seemingly small number: It's a percentage and it's out of a *very* large
 population. So 1-2% is still *huge*.


 This is a truism. Yeah, 1% is huge but the rest is 99 times huger. It's a 
 reasonable business decision to forgo 1-2% reach (and therefore potential 
 profit) if the cost of that reach is larger than the projected increase in 
 the profit.


You can rationalize it by hiding behind the "it's business!" veil all you 
want, but at the end of the day, you're still saying "fuck you" to millions 
of people.



 Mar 12 2012



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 12 March 2012 at 23:23:13 UTC, Nick Sabalausky wrote:

 at the end of the day, you're still saying "fuck you" to 
 millions of people.


...for little to no reason. It's not like making 99% of
sites work without javascript takes *any* effort.

Indeed, going without javascript is often desirable
anyway, since no JS sites are /much/ faster than script
heavy sites.



 Mar 12 2012



 next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:npkazdoslxiuqxiingao forum.dlang.org...

 On Monday, 12 March 2012 at 23:23:13 UTC, Nick Sabalausky wrote:

 at the end of the day, you're still saying "fuck you" to millions of 
 people.


 ...for little to no reason. It's not like making 99% of
 sites work without javascript takes *any* effort.


*Exactly*. And nobody can tell me otherwise because *I DO* exactly that sort 
of web development. Plus, it often makes for a *worse* user experience even 
when JS is on - look at Vladimir's D forums vs reddit. Vladimir put reddit 
to shame *on reddit*, for god's sake! And how many man-hours of effort do 
you think went into those D forums vs reddit?


 Indeed, going without javascript is often desirable
 anyway, since no JS sites are /much/ faster than script
 heavy sites.


Yup. Guess I already responded to this in the paragraph above :)



 Mar 12 2012



  parent reply Ary Manzana <ary esperanto.org.ar>  writes:


On 03/12/2012 08:32 PM, Nick Sabalausky wrote:

 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:npkazdoslxiuqxiingao forum.dlang.org...

 On Monday, 12 March 2012 at 23:23:13 UTC, Nick Sabalausky wrote:

 at the end of the day, you're still saying "fuck you" to millions of
 people.


 ...for little to no reason. It's not like making 99% of
 sites work without javascript takes *any* effort.


 *Exactly*. And nobody can tell me otherwise because *I DO* exactly that sort
 of web development. Plus, it often makes for a *worse* user experience even
 when JS is on - look at Vladimir's D forums vs reddit. Vladimir put reddit
 to shame *on reddit*, for god's sake! And how many man-hours of effort do
 you think went into those D forums vs reddit?


 Indeed, going without javascript is often desirable
 anyway, since no JS sites are /much/ faster than script
 heavy sites.


 Yup. Guess I already responded to this in the paragraph above :)


It's not about the speed. It's about behaviour.

Imagine I do I blog site and want people to leave comments. I decide the 
best thing for the user is to just enter the comment in a text area, 
press a button, and have the comment turn into a text block, and say 
something like "Comment saved!". From a UI perspective, it's the most 
reasonable thing to do: you leave a comment, it becomes a definitive 
comment on the blog, that's it.

The implementation is straightforward (much more if I use something like 
knockoutjs): I post the comment to the server via javascript and on the 
callback, turn that "editing comment" into a definitive comment. Note 
that only the comment contents were transfered between the client and 
the server.

Now, I have to support people who don't like javascript (and that people 
ONLY includes developers, as most people don't even know the difference 
between google and a web browser).

To implement that I have to check for disabled javascript, and post the 
comment to a different url that will save the comment and redirect to 
the same page. First, it's a strange experience for the user: navigating 
to another page while it's really going to the same page, just with one 
more comment (and how can I make it scroll without javascript to let the 
user see the comment just created? Or should I implement an intermediate 
page saying "here's your newly created comment, now go back to the 
post"). Second, the whole page is transferred again! I can't see how in 
the world that is faster than not transferring anything at all.

I know, I had to transfer some javascript. But just once, since it'll be 
cached by the server. In fact, if the page has a static html which 
invokes javascript that makes callbacks, that's the most efficient thing 
to do. Because even if your comments change, the whole page remains the 
same: elements will be rendered after *just* the comment's content (in 
JSON) are transferred.

Again, I don't understand how that is slower than transferring whole 
pages the whole time.



 Mar 12 2012



 next sibling parent reply James Miller <james aatch.net>  writes:


On 13 March 2012 17:07, Ary Manzana <ary esperanto.org.ar> wrote:

 On 03/12/2012 08:32 PM, Nick Sabalausky wrote:

 "Adam D. Ruppe"<destructionator gmail.com> =C2=A0wrote in message
 news:npkazdoslxiuqxiingao forum.dlang.org...

 On Monday, 12 March 2012 at 23:23:13 UTC, Nick Sabalausky wrote:

 at the end of the day, you're still saying "fuck you" to millions of
 people.



 ...for little to no reason. It's not like making 99% of
 sites work without javascript takes *any* effort.


 *Exactly*. And nobody can tell me otherwise because *I DO* exactly that
 sort
 of web development. Plus, it often makes for a *worse* user experience
 even
 when JS is on - look at Vladimir's D forums vs reddit. Vladimir put redd=




it

 to shame *on reddit*, for god's sake! And how many man-hours of effort d=




o

 you think went into those D forums vs reddit?


 Indeed, going without javascript is often desirable
 anyway, since no JS sites are /much/ faster than script
 heavy sites.



 Yup. Guess I already responded to this in the paragraph above :)



 It's not about the speed. It's about behaviour.

 Imagine I do I blog site and want people to leave comments. I decide the
 best thing for the user is to just enter the comment in a text area, pres=


s a

 button, and have the comment turn into a text block, and say something li=


ke

 "Comment saved!". From a UI perspective, it's the most reasonable thing t=


o

 do: you leave a comment, it becomes a definitive comment on the blog, tha=


t's

 it.

 The implementation is straightforward (much more if I use something like
 knockoutjs): I post the comment to the server via javascript and on the
 callback, turn that "editing comment" into a definitive comment. Note tha=


t

 only the comment contents were transfered between the client and the serv=


er.

 Now, I have to support people who don't like javascript (and that people
 ONLY includes developers, as most people don't even know the difference
 between google and a web browser).

 To implement that I have to check for disabled javascript, and post the
 comment to a different url that will save the comment and redirect to the
 same page. First, it's a strange experience for the user: navigating to
 another page while it's really going to the same page, just with one more
 comment (and how can I make it scroll without javascript to let the user =


see

 the comment just created? Or should I implement an intermediate page sayi=


ng

 "here's your newly created comment, now go back to the post"). Second, th=


e

 whole page is transferred again! I can't see how in the world that is fas=


ter

 than not transferring anything at all.

 I know, I had to transfer some javascript. But just once, since it'll be
 cached by the server. In fact, if the page has a static html which invoke=


s

 javascript that makes callbacks, that's the most efficient thing to do.
 Because even if your comments change, the whole page remains the same:
 elements will be rendered after *just* the comment's content (in JSON) ar=


e

 transferred.

 Again, I don't understand how that is slower than transferring whole page=


s

 the whole time.


Ary, the idea is to start with the static HTML version, then
progressively add javascript to improve the functionality. If you have
javascript at your disposal, you can change the behavior of the
existing page.

Your example would be:

1. Start with normal POST-request comment form, make sure it works.
(HTTP redirect back to original page)
2. Add javascript that listens to the submit on the comment form.
2a. Stop the default submit, submit the form to the same endpoint as 1
3. On success, do your in-page comment action.

And thats about it. I'm sure you could break it down more. There's
also more you can do, most of it server-side (check for ajax post,
return JSON, etc.), but the idea is that the extra effort to support
HTML-only isn't really extra effort. Since you have to submit the form
anyway, then why not allow it to submit by regular HTTP first.

Ideally, you don't have to detect for javascript, you just have to
*shock horror* code to web standards.

--
James Miller



 Mar 12 2012



  parent reply Ary Manzana <ary esperanto.org.ar>  writes:


On 03/13/2012 01:29 AM, James Miller wrote:

 On 13 March 2012 17:07, Ary Manzana<ary esperanto.org.ar>  wrote:

 On 03/12/2012 08:32 PM, Nick Sabalausky wrote:

 "Adam D. Ruppe"<destructionator gmail.com>    wrote in message
 news:npkazdoslxiuqxiingao forum.dlang.org...

 On Monday, 12 March 2012 at 23:23:13 UTC, Nick Sabalausky wrote:

 at the end of the day, you're still saying "fuck you" to millions of
 people.



 ...for little to no reason. It's not like making 99% of
 sites work without javascript takes *any* effort.


 *Exactly*. And nobody can tell me otherwise because *I DO* exactly that
 sort
 of web development. Plus, it often makes for a *worse* user experience
 even
 when JS is on - look at Vladimir's D forums vs reddit. Vladimir put reddit
 to shame *on reddit*, for god's sake! And how many man-hours of effort do
 you think went into those D forums vs reddit?


 Indeed, going without javascript is often desirable
 anyway, since no JS sites are /much/ faster than script
 heavy sites.



 Yup. Guess I already responded to this in the paragraph above :)



 It's not about the speed. It's about behaviour.

 Imagine I do I blog site and want people to leave comments. I decide the
 best thing for the user is to just enter the comment in a text area, press a
 button, and have the comment turn into a text block, and say something like
 "Comment saved!". From a UI perspective, it's the most reasonable thing to
 do: you leave a comment, it becomes a definitive comment on the blog, that's
 it.

 The implementation is straightforward (much more if I use something like
 knockoutjs): I post the comment to the server via javascript and on the
 callback, turn that "editing comment" into a definitive comment. Note that
 only the comment contents were transfered between the client and the server.

 Now, I have to support people who don't like javascript (and that people
 ONLY includes developers, as most people don't even know the difference
 between google and a web browser).

 To implement that I have to check for disabled javascript, and post the
 comment to a different url that will save the comment and redirect to the
 same page. First, it's a strange experience for the user: navigating to
 another page while it's really going to the same page, just with one more
 comment (and how can I make it scroll without javascript to let the user see
 the comment just created? Or should I implement an intermediate page saying
 "here's your newly created comment, now go back to the post"). Second, the
 whole page is transferred again! I can't see how in the world that is faster
 than not transferring anything at all.

 I know, I had to transfer some javascript. But just once, since it'll be
 cached by the server. In fact, if the page has a static html which invokes
 javascript that makes callbacks, that's the most efficient thing to do.
 Because even if your comments change, the whole page remains the same:
 elements will be rendered after *just* the comment's content (in JSON) are
 transferred.

 Again, I don't understand how that is slower than transferring whole pages
 the whole time.


 Ary, the idea is to start with the static HTML version, then
 progressively add javascript to improve the functionality. If you have
 javascript at your disposal, you can change the behavior of the
 existing page.

 Your example would be:

 1. Start with normal POST-request comment form, make sure it works.
 (HTTP redirect back to original page)
 2. Add javascript that listens to the submit on the comment form.
 2a. Stop the default submit, submit the form to the same endpoint as 1
 3. On success, do your in-page comment action.

 And thats about it. I'm sure you could break it down more. There's
 also more you can do, most of it server-side (check for ajax post,
 return JSON, etc.), but the idea is that the extra effort to support
 HTML-only isn't really extra effort. Since you have to submit the form
 anyway, then why not allow it to submit by regular HTTP first.

 Ideally, you don't have to detect for javascript, you just have to
 *shock horror* code to web standards.

 --
 James Miller


But the non-javascript version is a worse user experience, and it's less 
efficient. Why not make it well from scratch?



 Mar 12 2012



 next sibling parent  James Miller <james aatch.net>  writes:


On 13 March 2012 17:31, Ary Manzana <ary esperanto.org.ar> wrote:

 Ideally, you don't have to detect for javascript, you just have to
 *shock horror* code to web standards.

 --
 James Miller



 But the non-javascript version is a worse user experience, and it's less
 efficient. Why not make it well from scratch?


Because my way works for everybody, and well for people with
javascript. Your way eliminates everybody without javascript. It is
barely any extra work to set it up this way (all the logic you had to
do anyway, just have to think about it better), and 99% of people get
the exact same experience, and 1% still get to use your site.
Everybody wins.

This isn't some JS vs NoJS debate, this is JS-only vs Progressive
Enhancement. And for the record, GMail has a HTML-only version, and
most of the other products work, if with reduced functionality,
without javascript. I just tested search, it worked fine.

--
James Miller



 Mar 12 2012



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jjmiip$2c2$1 digitalmars.com...

 But the non-javascript version is a worse user experience, and it's less 
 efficient. Why not make it well from scratch?


Because it's trivially easy to do, and it *is* a better experience than: a 
user goes to your page, tries to add a comment, finds that "This fucking 
thing doesn't even work, WTF? It's just a goddamn form submission! How do 
you screw that up?" and then if they still care, enable JS and then reload 
the page, possibly much more slowly this time, reenter the captcha and try 
again. You can argue that "everyone should just conform and keep JS on!", 
but that's never going to happen (and for legitimate reasons). Besides, as 
developers, it's *our* responsibility, not the user's, to make things "just 
work".



 Mar 12 2012



prev sibling  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Tue, Mar 13, 2012 at 06:13:53PM +1300, James Miller wrote:
[...]

 This isn't some JS vs NoJS debate, this is JS-only vs Progressive
 Enhancement. And for the record, GMail has a HTML-only version, and
 most of the other products work, if with reduced functionality,
 without javascript. I just tested search, it worked fine.


[...]

Data point. After google started adding JS enhancements to their search
results page and the JS keyboard shortcuts conflicted with my browser
custom key bindings, I turned off JS for www.google.com (shock!
horror!).

And guess what? It went back to the same behaviour it used to have
before the JS enhancements. ON THE SAME HTML PAGE. No loss in
functionality at all. See, now that's an example of web coding done
right. The HTML provides the baseline functionality, and if the user has
JS, then she gets the enhanced functions. Everybody wins. This is how
web standards were designed to work, in the first place.

And this takes no extra effort at all. The HTML is supposed to express
the logical structure of the page anyway, so using <form> and form
elements *should* be done anyways. You get baseline functionality for
free. Then layer JS on top of that to do whatever fancy effects you
want -- which you wanted to do anyway. So it's the same amount of work
for *much* better graceful degradation.

As opposed to writing the site with JS from the get-go, which has no
graceful degradation, *and* often turns out to be much uglier (you end
up with lots of JS just outputting HTML into the DOM, which should've
just been put into the HTML file in the first place).


T

-- 
Государство делает вид, что платит нам
зарплату, а мы делаем вид, что
работаем.



 Mar 12 2012



prev sibling  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Tuesday, 13 March 2012 at 04:07:08 UTC, Ary Manzana wrote:

 The implementation is straightforward (much more if I use 
 something like knockoutjs): I post the comment to the server 
 via javascript and on the callback, turn that "editing comment" 
 into a definitive comment.


It is *equally* straightforward to do this without
javascript, though it will have a page refresh.


 Note that only the comment contents were transfered between the 
 client and the server.


That's not relevant. Profile a web app's speed, and
you'll see there is no significant difference between
some json and a page on most internet connections.

The majority of the time is spent in javascript, then
latency between server and client. Data transfer time
is often not important.


 To implement that I have to check for disabled javascript, and 
 post the comment to a different url that will save the comment 
 and redirect to the same page.


You're doing this wrong. Your comment form is a form, yes?
Just set the action to the same thing you'd call in
javascript.

Zero extra work.

Now, add your javascript code to the onsubmit handler.

Using my web.d:

Element addComment(int contentId, Text commentText) {
    ensureGoodPost(); // xsrf check
    auto obj = new DataObject(db, "comments");
    obj.id = std.random.uniform(1, int.max);
    obj.content_id = contentId;
    obj.message = commentText.content;
    obj.commitChanges();
    // redirect redirects users, not api calls so this just works
    redirect("view-content?contentId=" ~ to!string(contentId) ~ 
"#c" ~ obj.id;
    return renderComment(obj); // you need to be able to render 
comments on the server for full page load anyway... so just reuse 
that
}


And you can render that in javascript or html without
hassle. You can simply let the automatically created
form

To render the form in javascript:

YourSite.getAutomaticForm("addComment").appendTo(this);

to call it:

YourSite.addComment(cid, "comment").appendTo(this);



Or, you can link to it:

site/add-comment?contentId=xxx

that gives the form, and POST to it will save the comment.
No JS needed, it uses standard form encoding.

Submit the form, and the redirect() sends the user
to the right place. Do the javascript submit, and the
redirect is not needed - the return value there
gets sent down.

(don't even have to write html btw!)




 I make it scroll without javascript to let the user see the 
 comment just created?


use an anchor in a http redirect. I don't recall if
that is quite right in IE8... but worst case, it just
ignores the anchor so the user scrolls manually. That's
graceful degredation.



 In fact, if the page has a static html which invokes javascript 
 that makes callbacks, that's the most efficient thing to do.


No. The more processing you do on the server, the
faster the page will be.

Paying an extra couple milliseconds on the server
is much smaller than paying for double latency
in more server round trips.


It is just like how people combine their css, js,
and images into big single files to cut down on
http requests. Do the same thing with ajax.

Now, you could cache the ajax requests too,
and save that... but there's no need when
you can just do it on the server. (and perhaps
cache the finished product)



 Mar 12 2012



prev sibling  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Tuesday, March 13, 2012 00:27:26 Adam D. Ruppe wrote:

 On Monday, 12 March 2012 at 23:23:13 UTC, Nick Sabalausky wrote:

 at the end of the day, you're still saying "fuck you" to
 millions of people.


 
 ...for little to no reason. It's not like making 99% of
 sites work without javascript takes *any* effort.
 
 Indeed, going without javascript is often desirable
 anyway, since no JS sites are /much/ faster than script
 heavy sites.


But that's a decision based on your needs as a website developer. If JS best 
suits whatever the needs of a particular website developer are, then they are 
completely justified in using it, because 99% of the people out there have it 
enabled in their browsers.

The question of whether it's the best tool for the job and whether it's 
reasonable to use it based on your customer base are two separate issues 
(except insomuch as what would be the best tool for the job _isn't_, because 
it doesn't work with the majority of your customer base - which isn't 
javascript's issue at all).

- Jonathan M Davis



 Mar 12 2012



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Tuesday, 13 March 2012 at 00:25:15 UTC, Jonathan M Davis wrote:

 But that's a decision based on your needs as a website 
 developer. If JS best suits whatever the needs of a particular 
 website developer are, then they are completely justified in 
 using it,
 because 99% of the people out there have it enabled in their 
 browsers.


If it takes ten seconds to support 100% of the people out there,
why not?

Though, in the majority of cases I've done, it actually
takes no extra time at all: use things like event delegation
and standard attributes.

For example, I was making a site and the client wanted a side
navigation added. Easy:

<div id="left-navigation">
   <a href="location">Name</a>
   <a href="location">Name</a>
</div>

That's the easiest way to do navigation... and it also happens
to work for everyone!

Then, he asked for a partial ajax load thing. Turns out that's
trivially easy too. On the client:

document.getElementById("left-navigation").addEventListener(
    "click", function(ev) {
         var element = getParent(ev.target, "a");
         if(!element) return;
         MySite.getPageContent(element.href).
             useToReplaceElement("page-content");
         ev.preventDefault();
    }, false);


And on the server:

Element getPageContent(string link) {
    auto document = run(link, "document");
    return document.requireElementById("page-content");
}



Boom. Now, I have the javascript he asked for, the standard
links for people who don't like that crap... and it takes no
extra work to add new links. It is just another standard link
tag.



So, then I have a comment thing kinda like reddit. I have
a "Comment" link that is supposed to show the form right
under.

<a class="comment-link">Comment</a>


On the server, I do most the work:

foreach(element; document.querySelectorAll(".comment"))
       element.href = "comment-form?parentId=" ~ 
encodeComponent(parentId);

Element commentForm(string parentId) {
    auto document = getDocument!"comment-form";
    auto form = document.requireElementById!Form("comment-form");
    form.setValue("parentId", parentId);
    return form;
}


And, on the client:

function commentSubmitHandler() {
     var placement = this.parentNode;
     backgroundSubmit(this, function(response) {
         placement.innerHTML += response;
     });
     return false;
}

var ch = document.getElementById("comments-holder");
ch.addEventListener("click", function(ev) {
     if(!hasClass(ev, "comment-link"))
          return;

     MySite.getPageContent(ev.href).get(function(html) {
         ev.parentNode.innerHTML += html;
         var forms = ev.parentNode.getElementsByTagName("form");
         for(var a = 0; a < forms; a++) {
              forms[a].onsubmit = commentSubmitHandler;
         }
     });
}, false);



Boom, a standard link for people without JS, and the inline
comment function for people who want that.

The standard link form won't look /great/, but hey it
cost nothing extra (you have to implement a form and
form handler anyway) to implement and it works.




Now, there *are* cases where you can't do this so easily.
If you're stuck on poor PHP I'm sure this is harder than
in D too... but really, do you have one of those cases?



 Mar 12 2012



 next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Tuesday, March 13, 2012 01:50:29 Adam D. Ruppe wrote:

 On Tuesday, 13 March 2012 at 00:25:15 UTC, Jonathan M Davis wrote:

 But that's a decision based on your needs as a website
 developer. If JS best suits whatever the needs of a particular
 website developer are, then they are completely justified in
 using it,
 because 99% of the people out there have it enabled in their
 browsers.


 
 If it takes ten seconds to support 100% of the people out there,
 why not?


[snip]


 Now, there *are* cases where you can't do this so easily.
 If you're stuck on poor PHP I'm sure this is harder than
 in D too... but really, do you have one of those cases?


All I'm saying is that if it makes sense for the web developer to use 
javascript given what they're trying to do, it's completely reasonable to 
expect that their users will have javascript enabled (since virtually everyone 
does). If there's a better tool for the job which is reasonably supported, 
then all the better. And if it's easy to provide a workaround for the lack of 
JS at minimal effort, then great. But given the fact that only a very small 
percentage of your user base is going to have JS disabled, it's not 
unreasonable to require it and not worry about the people who disable it if 
that's what you want to do.

- Jonathan M Davis



 Mar 12 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.572.1331601463.4860.digitalmars-d puremagic.com...

 On Tuesday, March 13, 2012 01:50:29 Adam D. Ruppe wrote:

 On Tuesday, 13 March 2012 at 00:25:15 UTC, Jonathan M Davis wrote:

 But that's a decision based on your needs as a website
 developer. If JS best suits whatever the needs of a particular
 website developer are, then they are completely justified in
 using it,
 because 99% of the people out there have it enabled in their
 browsers.


 If it takes ten seconds to support 100% of the people out there,
 why not?


 [snip]


 Now, there *are* cases where you can't do this so easily.
 If you're stuck on poor PHP I'm sure this is harder than
 in D too... but really, do you have one of those cases?


 All I'm saying is that if it makes sense for the web developer to use
 javascript given what they're trying to do, it's completely reasonable to
 expect that their users will have javascript enabled (since virtually 
 everyone
 does). If there's a better tool for the job which is reasonably supported,
 then all the better. And if it's easy to provide a workaround for the lack 
 of
 JS at minimal effort, then great. But given the fact that only a very 
 small
 percentage of your user base is going to have JS disabled, it's not
 unreasonable to require it and not worry about the people who disable it 
 if
 that's what you want to do.


Personally, I disagree with the notion that non-JS versions are a 
"workaround".



 Mar 12 2012



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
 news:mailman.572.1331601463.4860.digitalmars-d puremagic.com...


[...]

 All I'm saying is that if it makes sense for the web developer to
 use javascript given what they're trying to do, it's completely
 reasonable to expect that their users will have javascript enabled
 (since virtually everyone does). If there's a better tool for the
 job which is reasonably supported, then all the better. And if it's
 easy to provide a workaround for the lack of JS at minimal effort,
 then great. But given the fact that only a very small percentage of
 your user base is going to have JS disabled, it's not unreasonable
 to require it and not worry about the people who disable it if
 that's what you want to do.


 
 Personally, I disagree with the notion that non-JS versions are a
 "workaround".


[...]

Me too. To me, non-JS versions are the *baseline*, and JS versions are
enchancements. To treat JS versions as baseline and non-JS versions as
"workaround" is just so completely backwards.


T

-- 
There are three kinds of people in the world: those who can count, and those
who can't.



 Mar 12 2012



  parent reply Ary Manzana <ary esperanto.org.ar>  writes:


On 03/13/2012 02:14 AM, H. S. Teoh wrote:

 On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:

 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.572.1331601463.4860.digitalmars-d puremagic.com...


 [...]

 All I'm saying is that if it makes sense for the web developer to
 use javascript given what they're trying to do, it's completely
 reasonable to expect that their users will have javascript enabled
 (since virtually everyone does). If there's a better tool for the
 job which is reasonably supported, then all the better. And if it's
 easy to provide a workaround for the lack of JS at minimal effort,
 then great. But given the fact that only a very small percentage of
 your user base is going to have JS disabled, it's not unreasonable
 to require it and not worry about the people who disable it if
 that's what you want to do.


 Personally, I disagree with the notion that non-JS versions are a
 "workaround".


 [...]

 Me too. To me, non-JS versions are the *baseline*, and JS versions are
 enchancements. To treat JS versions as baseline and non-JS versions as
 "workaround" is just so completely backwards.


While I don't agree that non-JS is the baseline (because most if not all 
browsers come with JS enabled by default, so why would you want to 
disable javascript for?), I'm starting to understand that providing both 
non-JS and JS versions is useful.

At least so that:
  - Some users don't go mad when they can't use it, and then realise 
it's because JS is disabled
  - And for the above reason, not to loose reputation to those people :-P

But if people didn't have an option to disable JS, we wouldn't have this 
discussion. I think it as having an option to disable CSS.

(I was going to put as an argument that my cellphone didn't have an 
option to disable JS, but it does... hmmmmmmmmmmmmmmmm... :-P)



 Mar 13 2012



 next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Tuesday, 13 March 2012 at 12:22:00 UTC, Ary Manzana wrote:

 But if people didn't have an option to disable JS, we wouldn't 
 have this discussion. I think it as having an option to disable 
 CSS.


You can disable css :P

Keeping your site working without css is a lot harder IMO
than doing the same without javascript. I often assume
display: none; will work to hide unnecessary things.

Sometimes, doing simple things with css is a bit hard too.

For example, one easy way to make a site still work without
css is to put your content at the top of the HTML page,
with  as few as possible distractions in the process.

Oh yeah, and of course, always use the proper semantic
tags, which you should do anyway. Descriptive tags
help css too!

Anyway, so, you put the navigation menus, etc., at the
bottom of the html file.


Here's the problem though: you want those menus to show
up at the top for people with css. And that is incredibly
hard to get right currently. (I think css3 will make it
easier, but IE10 is the only browser to properly support
the needed features last I checked, and IE10 has 0% market.)


But with css2, you can't float to the top.... you can't
display: table to the top.

The best you can do is position: absolute, which can get
you trapped in the document tree and is just generally
a pain in the butt - you have to break the natural flow.


I often just say gah to it and either minimize those
things so it isn't too big of a hassle anyway, or put
a display: none #content link at the top.

(The only people who go without css in my experience are
lynx users anyway, so making it easier to scroll past the
crap is the important thing.)




Now, here's one case I never think about: what about if
JS is enabled, and CSS is not? Now that would be weird.

Probably usable but just really weird.



 Mar 13 2012



prev sibling next sibling parent reply "Nick Sabalausky" <a a.a>  writes:


"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jjne58$1ouf$1 digitalmars.com...

 On 03/13/2012 02:14 AM, H. S. Teoh wrote:

 On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:

 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.572.1331601463.4860.digitalmars-d puremagic.com...


 [...]

 All I'm saying is that if it makes sense for the web developer to
 use javascript given what they're trying to do, it's completely
 reasonable to expect that their users will have javascript enabled
 (since virtually everyone does). If there's a better tool for the
 job which is reasonably supported, then all the better. And if it's
 easy to provide a workaround for the lack of JS at minimal effort,
 then great. But given the fact that only a very small percentage of
 your user base is going to have JS disabled, it's not unreasonable
 to require it and not worry about the people who disable it if
 that's what you want to do.


 Personally, I disagree with the notion that non-JS versions are a
 "workaround".


 [...]

 Me too. To me, non-JS versions are the *baseline*, and JS versions are
 enchancements. To treat JS versions as baseline and non-JS versions as
 "workaround" is just so completely backwards.


 While I don't agree that non-JS is the baseline (because most if not all 
 browsers come with JS enabled by default, so why would you want to disable 
 javascript for?), I'm starting to understand that providing both non-JS 
 and JS versions is useful.

 At least so that:
  - Some users don't go mad when they can't use it, and then realise it's 
 because JS is disabled
  - And for the above reason, not to loose reputation to those people :-P

 But if people didn't have an option to disable JS, we wouldn't have this 
 discussion.[...]


Bullcrap. If people didn't have an option to disable JS, there'd be a lot 
more people using *very* *VERY* old browsers, and that would piss of 
*cough*modern*cough* webdevs even more.

The problem isn't that JS *can* be disabled. Some people *just don't want 
it*:

When they disable JS, yea, ok, on *some* sites they get a *slighty worse* 
user experience with, say, posting a comment. But it *also* gives them a 
*far BETTER* user experience on all those sites that misuse and overuse JS. 
It also increases security. The idea that JS-enabled pages are "just simply 
better" is patently false: Yes, *some* are *slightly* better, but many are 
*much* worse (no matter how good their respective developers believe 
themselves to be. *Everyone* believes "Oh, well, when *I* use it, it works 
very well." I'm sure the Reddit developers have fooled themselves into 
thinking their site is reasonably fast).



 Mar 13 2012



  parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:jjo65v$305$1 digitalmars.com...

 "Ary Manzana" <ary esperanto.org.ar> wrote in message 
 news:jjne58$1ouf$1 digitalmars.com...

 On 03/13/2012 02:14 AM, H. S. Teoh wrote:

 On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:

 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.572.1331601463.4860.digitalmars-d puremagic.com...


 [...]

 All I'm saying is that if it makes sense for the web developer to
 use javascript given what they're trying to do, it's completely
 reasonable to expect that their users will have javascript enabled
 (since virtually everyone does). If there's a better tool for the
 job which is reasonably supported, then all the better. And if it's
 easy to provide a workaround for the lack of JS at minimal effort,
 then great. But given the fact that only a very small percentage of
 your user base is going to have JS disabled, it's not unreasonable
 to require it and not worry about the people who disable it if
 that's what you want to do.


 Personally, I disagree with the notion that non-JS versions are a
 "workaround".


 [...]

 Me too. To me, non-JS versions are the *baseline*, and JS versions are
 enchancements. To treat JS versions as baseline and non-JS versions as
 "workaround" is just so completely backwards.


 While I don't agree that non-JS is the baseline (because most if not all 
 browsers come with JS enabled by default, so why would you want to 
 disable javascript for?), I'm starting to understand that providing both 
 non-JS and JS versions is useful.

 At least so that:
  - Some users don't go mad when they can't use it, and then realise it's 
 because JS is disabled
  - And for the above reason, not to loose reputation to those people :-P

 But if people didn't have an option to disable JS, we wouldn't have this 
 discussion.[...]


 Bullcrap. If people didn't have an option to disable JS, there'd be a lot 
 more people using *very* *VERY* old browsers, and that would piss of 
 *cough*modern*cough* webdevs even more.

 The problem isn't that JS *can* be disabled. Some people *just don't want 
 it*:

 When they disable JS, yea, ok, on *some* sites they get a *slighty worse* 
 user experience with, say, posting a comment. But it *also* gives them a 
 *far BETTER* user experience on all those sites that misuse and overuse 
 JS. It also increases security.


Oh, and with JS disabled, it's impossible for sites *cough*GitHub*cough* to 
break the back button.


The idea that JS-enabled pages are "just simply better" is patently false: 
Yes, *some* are *slightly* better, but many are *much* worse (no matter how 
good their respective developers believe themselves to be. *Everyone* 
believes "Oh, well, when *I* use it, it works very well." I'm sure the 
Reddit developers have fooled themselves into thinking their site is 
reasonably fast).

 





 Mar 13 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jjne58$1ouf$1 digitalmars.com...

 But if people didn't have an option to disable JS, we wouldn't have this 
 discussion. I think it as having an option to disable CSS.


That's not even an accurate comparison anyway. Disabling CSS never does much 
to improve things, and usually it'll just make things *far* worse. People 
don't fuck up CSS nearly to the extent that they fuck up JS. Hell, CSS 
*can't* be fucked up as badly as JS can be. The "no JS == no CSS" comparison 
is like saying "Disabling JS is like disabling vowels". No, no it isn't like 
that. Not remotely.



 Mar 13 2012



  parent  Jeff Nowakowski <jeff dilacero.org>  writes:


On 03/13/2012 03:15 PM, Nick Sabalausky wrote:

 That's not even an accurate comparison anyway. Disabling CSS never does much
 to improve things, and usually it'll just make things *far* worse.


I disable CSS frequently in Mozilla: View -> Page Style -> No Style. 
This fixes a lot of annoying styles that don't respect my font settings 
or don't display well based on the width of my browser screen.



 Mar 14 2012



prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Mon, Mar 12, 2012 at 09:17:22PM -0400, Jonathan M Davis wrote:

 On Tuesday, March 13, 2012 01:50:29 Adam D. Ruppe wrote:

 On Tuesday, 13 March 2012 at 00:25:15 UTC, Jonathan M Davis wrote:

 But that's a decision based on your needs as a website developer.
 If JS best suits whatever the needs of a particular website
 developer are, then they are completely justified in using it,
 because 99% of the people out there have it enabled in their
 browsers.


 
 If it takes ten seconds to support 100% of the people out there, why
 not?


 
 [snip]
 

 Now, there *are* cases where you can't do this so easily.
 If you're stuck on poor PHP I'm sure this is harder than
 in D too... but really, do you have one of those cases?


 
 All I'm saying is that if it makes sense for the web developer to use
 javascript given what they're trying to do, it's completely reasonable
 to expect that their users will have javascript enabled (since
 virtually everyone does). If there's a better tool for the job which
 is reasonably supported, then all the better. And if it's easy to
 provide a workaround for the lack of JS at minimal effort, then great.
 But given the fact that only a very small percentage of your user base
 is going to have JS disabled, it's not unreasonable to require it and
 not worry about the people who disable it if that's what you want to
 do.


[...]

The complaint is not with using JS when it's *necessary*. It's with
using JS *by default*. It's with using JS just because you can, even
when it's *not needed* at all.

It's like requiring you to have a TV just to make a simple phone call.
Sure, you can do cool stuff like hooking up the remote end's webcam to
the TV and other such fluff like that. But *requiring* all of that for a
*phone call*?  Totally unnecessary, and a totally unreasonable
requirement, even if 95% (or is that 99.9%?) of all households own a TV.
(And for the record, I don't own one, and do not plan to. I know I'm in
the minority.  That doesn't negate the fact that such a requirement is
unreasonable.)

OTOH if you want to *watch a movie*, well, then requiring a TV is
completely reasonable.

The problem today is that JS is the "next cool thing", so everyone is
jumping on the bandwagon, and everything from a single-page personal
website to a list of links to the latest toaster oven requires JS to
work, even when it's not necessary at all. That's the silliness of it
all.


T

-- 
Computers shouldn't beep through the keyhole.



 Mar 12 2012



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.575.1331603803.4860.digitalmars-d puremagic.com...

 (And for the record, I don't own [a TV], and do not plan to. I know I'm in
 the minority.


I can somewhat relate: I have a TV, but I rarely watch broadcast programming 
anymore, just library videos.

Although even if I didn't watch videos either, I'd still want a TV just for 
gaming. I spend so much time at a computer desk, that when I unwind I want 
to do away from a desk or computer, like a living room couch. YMMV, of 
course. 



 Mar 12 2012



prev sibling  parent reply Ary Manzana <ary esperanto.org.ar>  writes:


On 03/12/2012 10:58 PM, H. S. Teoh wrote:

 On Mon, Mar 12, 2012 at 09:17:22PM -0400, Jonathan M Davis wrote:

 On Tuesday, March 13, 2012 01:50:29 Adam D. Ruppe wrote:

 On Tuesday, 13 March 2012 at 00:25:15 UTC, Jonathan M Davis wrote:

 But that's a decision based on your needs as a website developer.
 If JS best suits whatever the needs of a particular website
 developer are, then they are completely justified in using it,
 because 99% of the people out there have it enabled in their
 browsers.


 If it takes ten seconds to support 100% of the people out there, why
 not?


 [snip]


 Now, there *are* cases where you can't do this so easily.
 If you're stuck on poor PHP I'm sure this is harder than
 in D too... but really, do you have one of those cases?


 All I'm saying is that if it makes sense for the web developer to use
 javascript given what they're trying to do, it's completely reasonable
 to expect that their users will have javascript enabled (since
 virtually everyone does). If there's a better tool for the job which
 is reasonably supported, then all the better. And if it's easy to
 provide a workaround for the lack of JS at minimal effort, then great.
 But given the fact that only a very small percentage of your user base
 is going to have JS disabled, it's not unreasonable to require it and
 not worry about the people who disable it if that's what you want to
 do.


 [...]

 The complaint is not with using JS when it's *necessary*. It's with
 using JS *by default*. It's with using JS just because you can, even
 when it's *not needed* at all.

 It's like requiring you to have a TV just to make a simple phone call.
 Sure, you can do cool stuff like hooking up the remote end's webcam to
 the TV and other such fluff like that. But *requiring* all of that for a
 *phone call*?  Totally unnecessary, and a totally unreasonable
 requirement, even if 95% (or is that 99.9%?) of all households own a TV.
 (And for the record, I don't own one, and do not plan to. I know I'm in
 the minority.  That doesn't negate the fact that such a requirement is
 unreasonable.)

 OTOH if you want to *watch a movie*, well, then requiring a TV is
 completely reasonable.

 The problem today is that JS is the "next cool thing", so everyone is
 jumping on the bandwagon, and everything from a single-page personal
 website to a list of links to the latest toaster oven requires JS to
 work, even when it's not necessary at all. That's the silliness of it
 all.


 T


It's not the next cool thing. It makes thing more understandable for the 
user. And it makes the web transfer less content, and leverages server 
processing time. It's the next step. It's not a backwards step. :-P

I figure then Google people are just all a bunch of idiots who just like 
JS a lot...



 Mar 12 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:jjmhja$3a$2 digitalmars.com...

 On 03/12/2012 10:58 PM, H. S. Teoh wrote:

 The problem today is that JS is the "next cool thing", so everyone is
 jumping on the bandwagon, and everything from a single-page personal
 website to a list of links to the latest toaster oven requires JS to
 work, even when it's not necessary at all. That's the silliness of it
 all.


 T


 It's not the next cool thing. It makes thing more understandable for the 
 user. And it makes the web transfer less content,


That gets constantly echoed throughout the web, but it's a red herring: Even 
if you handle it intelligently like Adam does (ie, lightweight), the amount 
of data transfer saved is trivial. We're talking *part* of *one* measly HTML 
file here. And even that can be gzipped: HTML compresses *very* well. Yes, 
techincally it can be less transfer, but only negligably so. And bandwith is 
the *only* possible realistic improvement here, not speed, because the speed 
of even a few extra K during a transfer that was already going to happen 
anyway is easily outweighed by the overhead of things like actually making a 
round-trip to the server at all, plus likely querying a server-side DB, plus 
interpreting JS, etc.

If, OTOH you handle it like most people do, and not like Adam does, then for 
brief visits you can actually be tranferring *more* data just because of all 
that excess JS boilerplate people like to use. (And then there's the 
start-up cost of actually parsing all that boilerplate and then executing 
their initialization portions. And in many cases there's even external JS 
getting loaded in, etc.)

The problem with optimization is that it's not a clear-cut thing: If you're 
not looking at it holistically, optimizing one thing can either be an 
effective no-op or even cause a larger de-optimization somewhere else. So 
just because you've achived the popular goal of "less data transer" upon 
your user clicking a certain link, doesn't necessarily mean you've won a net 
gain, or even broken even.


 and leverages server processing time. It's the next step. It's not a 
 backwards step. :-P


It's the *newer* step. It may be "the future", but that's irrelevent: The 
question here is whether it's *good*, not whether it's popular or 
ubiquitous. Most real-world uses of it *are*, objectively, backwards steps.


 I figure then Google people are just all a bunch of idiots who just like 
 JS a lot...


Probably not all of them, but for the most part I frequently get that 
impression. Plus, keep in mind too, they have a *clear vested interest* in 
treating the web as a platform. Their whole business model relies on the web 
being treating as a platform. That, in turn, creates a (self-serving) need 
for them to push JS *regardless* of JS's merit. Without ubiquitus JS, the 
web has an even harder time competing with real platforms, and that pulls 
the rug out from under Google. They *are* a major corporation, never forget 
that.



 Mar 12 2012



  parent  Ary Manzana <ary esperanto.org.ar>  writes:


On 03/13/2012 01:52 AM, Nick Sabalausky wrote:

 "Ary Manzana"<ary esperanto.org.ar>  wrote in message
 news:jjmhja$3a$2 digitalmars.com...

 On 03/12/2012 10:58 PM, H. S. Teoh wrote:

 The problem today is that JS is the "next cool thing", so everyone is
 jumping on the bandwagon, and everything from a single-page personal
 website to a list of links to the latest toaster oven requires JS to
 work, even when it's not necessary at all. That's the silliness of it
 all.


 T


 It's not the next cool thing. It makes thing more understandable for the
 user. And it makes the web transfer less content,


 That gets constantly echoed throughout the web, but it's a red herring: Even
 if you handle it intelligently like Adam does (ie, lightweight), the amount
 of data transfer saved is trivial. We're talking *part* of *one* measly HTML
 file here. And even that can be gzipped: HTML compresses *very* well. Yes,
 techincally it can be less transfer, but only negligably so. And bandwith is
 the *only* possible realistic improvement here, not speed, because the speed
 of even a few extra K during a transfer that was already going to happen
 anyway is easily outweighed by the overhead of things like actually making a
 round-trip to the server at all, plus likely querying a server-side DB, plus
 interpreting JS, etc.

 If, OTOH you handle it like most people do, and not like Adam does, then for
 brief visits you can actually be tranferring *more* data just because of all
 that excess JS boilerplate people like to use. (And then there's the
 start-up cost of actually parsing all that boilerplate and then executing
 their initialization portions. And in many cases there's even external JS
 getting loaded in, etc.)

 The problem with optimization is that it's not a clear-cut thing: If you're
 not looking at it holistically, optimizing one thing can either be an
 effective no-op or even cause a larger de-optimization somewhere else. So
 just because you've achived the popular goal of "less data transer" upon
 your user clicking a certain link, doesn't necessarily mean you've won a net
 gain, or even broken even.


True.

I always have to remember this interesting talk about saying "This is 
faster than this" without a scientific proof:

http://vimeo.com/9270320



 Mar 13 2012



prev sibling next sibling parent reply James Miller <james aatch.net>  writes:


On 13 March 2012 14:58, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Mon, Mar 12, 2012 at 09:17:22PM -0400, Jonathan M Davis wrote:

 On Tuesday, March 13, 2012 01:50:29 Adam D. Ruppe wrote:

 On Tuesday, 13 March 2012 at 00:25:15 UTC, Jonathan M Davis wrote:

 But that's a decision based on your needs as a website developer.
 If JS best suits whatever the needs of a particular website
 developer are, then they are completely justified in using it,
 because 99% of the people out there have it enabled in their
 browsers.


 If it takes ten seconds to support 100% of the people out there, why
 not?


 [snip]


 Now, there *are* cases where you can't do this so easily.
 If you're stuck on poor PHP I'm sure this is harder than
 in D too... but really, do you have one of those cases?


 All I'm saying is that if it makes sense for the web developer to use
 javascript given what they're trying to do, it's completely reasonable
 to expect that their users will have javascript enabled (since
 virtually everyone does). If there's a better tool for the job which
 is reasonably supported, then all the better. And if it's easy to
 provide a workaround for the lack of JS at minimal effort, then great.
 But given the fact that only a very small percentage of your user base
 is going to have JS disabled, it's not unreasonable to require it and
 not worry about the people who disable it if that's what you want to
 do.


 [...]

 The complaint is not with using JS when it's *necessary*. It's with
 using JS *by default*. It's with using JS just because you can, even
 when it's *not needed* at all.

 It's like requiring you to have a TV just to make a simple phone call.
 Sure, you can do cool stuff like hooking up the remote end's webcam to
 the TV and other such fluff like that. But *requiring* all of that for a
 *phone call*? =C2=A0Totally unnecessary, and a totally unreasonable
 requirement, even if 95% (or is that 99.9%?) of all households own a TV.
 (And for the record, I don't own one, and do not plan to. I know I'm in
 the minority. =C2=A0That doesn't negate the fact that such a requirement =


is

 unreasonable.)

 OTOH if you want to *watch a movie*, well, then requiring a TV is
 completely reasonable.

 The problem today is that JS is the "next cool thing", so everyone is
 jumping on the bandwagon, and everything from a single-page personal
 website to a list of links to the latest toaster oven requires JS to
 work, even when it's not necessary at all. That's the silliness of it
 all.


 T

 --
 Computers shouldn't beep through the keyhole.


The phrase in web development is "Progressive enhancement" that used
to be all the rage at one point. I miss those days...

--
James Miller



 Mar 12 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"James Miller" <james aatch.net> wrote in message 
news:mailman.576.1331604546.4860.digitalmars-d puremagic.com...

The phrase in web development is "Progressive enhancement" that used
to be all the rage at one point. I miss those days...


Heh. :) So true...

I miss the days when having animations on a page was actually considered 
*bad* style. And when the big thing in web dev was minimizing "page load 
(and render) time". Then flash and advanced JS came around and that 
conventional wisdom silently flipped around (like a boiled frog), and has 
stayed that way ever since.



 Mar 12 2012



  parent reply James Miller <james aatch.net>  writes:


On 13 March 2012 15:48, Nick Sabalausky <a a.a> wrote:

 "James Miller" <james aatch.net> wrote in message
 news:mailman.576.1331604546.4860.digitalmars-d puremagic.com...

The phrase in web development is "Progressive enhancement" that used
to be all the rage at one point. I miss those days...


 Heh. :) So true...

 I miss the days when having animations on a page was actually considered
 *bad* style. And when the big thing in web dev was minimizing "page load
 (and render) time". Then flash and advanced JS came around and that
 conventional wisdom silently flipped around (like a boiled frog), and has
 stayed that way ever since.


If its any consolation, I still think in terms of page load times and
UX in terms of loading. I don't think animations in and of themselves
are a bad thing, I think the problem was GIF's and tacky animations
for the sake of it. Slide-up and slide-down animations for removal of
items and the similar are more subtle, but make things look much nicer
that sudden popping. Popping is bad UX in general, even high-graphics
games know that now, going more for mosaic fade-ins on the textures
instead.

--
James Miller



 Mar 12 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"James Miller" <james aatch.net> wrote in message 
news:mailman.581.1331607750.4860.digitalmars-d puremagic.com...

 On 13 March 2012 15:48, Nick Sabalausky <a a.a> wrote:

 "James Miller" <james aatch.net> wrote in message
 news:mailman.576.1331604546.4860.digitalmars-d puremagic.com...

The phrase in web development is "Progressive enhancement" that used
to be all the rage at one point. I miss those days...


 Heh. :) So true...

 I miss the days when having animations on a page was actually considered
 *bad* style. And when the big thing in web dev was minimizing "page load
 (and render) time". Then flash and advanced JS came around and that
 conventional wisdom silently flipped around (like a boiled frog), and has
 stayed that way ever since.


 If its any consolation, I still think in terms of page load times and
 UX in terms of loading. I don't think animations in and of themselves
 are a bad thing, I think the problem was GIF's and tacky animations
 for the sake of it. Slide-up and slide-down animations for removal of
 items and the similar are more subtle, but make things look much nicer
 that sudden popping. Popping is bad UX in general, even high-graphics
 games know that now, going more for mosaic fade-ins on the textures
 instead.


Yea, I do mostly agree, actually. But there is still a lot of needless 
animation (often in the form of Flash), although that does seem to be on a 
[long slow] decline. Adverts are a *big* probelm with animation (and even 
sound), though. I never actually used to mind the old banner ads, but when 
they started animating I had to install an adblocker literally just so I 
could be *capable* of reading the main content. Maybe that's just me, but 
still, accessiblity is important. Or at least *should* be considered 
important - and not just the subset of accessibility mandated by government.

As far as the typical UI animations, I think that's a much more complicated 
issue: First of all, I do agree that it *can* be good design. However, 
there's a few problems:

1. Such animations need to be *FAST*. We're talking roughly 250ms max 
(probably even less, but I'd have to play around with it to refresh my 
memory). Most UI animations are slower than this (particularly on the web - 
although many DVDs are *FAR* worse), and while it's good for first-time 
users, for everyone else it just gets in the way of getting work done and 
makes the experience feel sluggish.

2. On the web, animation means JS. But not everyone is using a browser with 
that V8 engine or whatever it's called (the one that Chrome uses). And not 
everyone is using a quad-core system with 64-bit software and 16GB or 
whatever RAM, etc. like the well-supplied web developers are likely using. 
So frequently this means very choppy, sluggish animations. And that's a much 
worse UX than popping. This also gets in the way of being able to properly 


3. People have also reported that such UI animations can convey a subtle (or 
even not-so-subtle) sense of being patronized. Especially if it's a slower 
animation. I can definitely relate to this.

(Of course, if people just make real applications instead of web apps, then 
those problems would be trivially solvable.)



 Mar 12 2012



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Tuesday, 13 March 2012 at 04:24:45 UTC, Nick Sabalausky wrote:

 2. On the web, animation means JS.


css3 does animations that are pretty easy to use,
degrade well, and tend to be fast. Moreover css
is where it belongs anyway - it is pure presentation.

Far, far superior to the JS crap.



 Mar 12 2012



 next sibling parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Tue, Mar 13, 2012 at 05:27:27AM +0100, Adam D. Ruppe wrote:

 On Tuesday, 13 March 2012 at 04:24:45 UTC, Nick Sabalausky wrote:

2. On the web, animation means JS.


 
 css3 does animations that are pretty easy to use,
 degrade well, and tend to be fast. Moreover css
 is where it belongs anyway - it is pure presentation.
 
 Far, far superior to the JS crap.


+1.


T

-- 
Real men don't take backups. They put their source on a public
FTP-server and let the world mirror it. -- Linus Torvalds



 Mar 12 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:oxkxtvkuybdommyerrke forum.dlang.org...

 On Tuesday, 13 March 2012 at 04:24:45 UTC, Nick Sabalausky wrote:

 2. On the web, animation means JS.


 css3 does animations that are pretty easy to use,
 degrade well, and tend to be fast. Moreover css
 is where it belongs anyway - it is pure presentation.


Interesting, I had no idea! Thanks for the tip :)


 Far, far superior to the JS crap.


Yea, there's a lot of things that are much better done in CSS that a lot of 
people don't even know about. For example, most rollovers are easily doable 
in pure CSS. But there's a lot stuff out there (paricularly things created 
in Adobe's "software") that use JS for rollovers, which doesn't even work as 
well (even with JS on).

OTOH, I don't like CSS drop-down menus. Maybe it's different in CSS3, but in 
CSS2 the only way to make CSS menus work is for them to open upon rollover, 
not click. And dropdown menus opening upon rollover is just a usability 
mess, IMO, *and* inconsistent with pretty much any GUI OS I've ever used.



 Mar 12 2012



 next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Tue, Mar 13, 2012 at 01:37:24AM -0400, Nick Sabalausky wrote:
[...]

 Yea, there's a lot of things that are much better done in CSS that a
 lot of people don't even know about. For example, most rollovers are
 easily doable in pure CSS. But there's a lot stuff out there
 (paricularly things created in Adobe's "software") that use JS for
 rollovers, which doesn't even work as well (even with JS on).


Ugh. Don't get me started on Adobe. I don't know what they do to their
programmers, but obviously UI design is not part of their staff
training. Have you seen acrobat reader's UI? It's utterly atrocious.
Completely counterintuitive, and an embarrassment to modern UI design.
And that's their product line. Don't even mention their website.



 OTOH, I don't like CSS drop-down menus. Maybe it's different in CSS3,
 but in CSS2 the only way to make CSS menus work is for them to open
 upon rollover, not click. And dropdown menus opening upon rollover is
 just a usability mess, IMO, *and* inconsistent with pretty much any
 GUI OS I've ever used.


[...]

Hmm. I rather *like* CSS drop-down menus, actually. At least, it's *way*
better than those annoying badly-written bloated JS menus. Though if
it's not done properly, it can be an utter annoyance. E.g., if the menu
is separated from the element that triggers it by a gap of several
pixels... then it's almost impossible to actually use it. (This happens
to me a lot 'cos I fiddle with default font size settings. Which lets me
see the pervasiveness of broken pixel-dependent CSS in all its glory.
OK, I better stop now, 'cos static vs. fluid layouts are another of my
pet peeves... this thread will never end if I keep going.)


T

-- 
Amateurs built the Ark; professionals built the Titanic.



 Mar 12 2012



  parent  "Nick Sabalausky" <a a.a>  writes:


"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.601.1331619011.4860.digitalmars-d puremagic.com...

 On Tue, Mar 13, 2012 at 01:37:24AM -0400, Nick Sabalausky wrote:
 [...]

 Yea, there's a lot of things that are much better done in CSS that a
 lot of people don't even know about. For example, most rollovers are
 easily doable in pure CSS. But there's a lot stuff out there
 (paricularly things created in Adobe's "software") that use JS for
 rollovers, which doesn't even work as well (even with JS on).


 Ugh. Don't get me started on Adobe. I don't know what they do to their
 programmers, but obviously UI design is not part of their staff
 training. Have you seen acrobat reader's UI? It's utterly atrocious.
 Completely counterintuitive, and an embarrassment to modern UI design.
 And that's their product line. Don't even mention their website.


Yea, I have a *very* low opinion of Adobe's products in general. They can 
barely get anything right, and that's on top of their sky-high prices. Each 
CS is more absurdly bloated than the last, and uses weirder and weirder 
skins, and Adobe clearly has zero understanding of security. I don't "hate" 
Adobe like I hate some other companies, but I consider their output to 
mostly be garbage and I hate dealing with their products (and 
documentation).

It's a shame they no longer have *really good* competition, like Paint Shop 
Pro which used to compete toe-to-toe with Photoshop and at a much lower 
price (until Corel bought it and drive it straight into the ground along 
with the rest of Corel's products). I use GIMP, but it's uhh...kind of a 
"gimpy" program (aptly-named).

Have you heared of the Corona SDK? It's not technically made by Adobe 
but...I'll put it this way: Corona does intially come across as fairly 
slick. But then you compare it to one of their competitors, Marmalade SDK, 
and despite Marmalade's lack of "slickness", you quickly realize that 
Marmalade was made by and for grownups, while Corona...is basically just an 
overpriced toy in grown-ups clothing. *After* I came to that conclusion, I 
discovered the company which makes Corona, surprise surprise, was founded by 
former higher-ups from Adobe's Flash dept. Go figure. Flash, which can 
*also* be accurately described as "an overpriced toy in grown-ups clothing".



 Mar 12 2012



prev sibling next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Tuesday, 13 March 2012 at 05:38:44 UTC, Nick Sabalausky wrote:

 OTOH, I don't like CSS drop-down menus. Maybe it's different in 
 CSS3, but in CSS2 the only way to make CSS menus work is for 
 them
 to open  upon rollover, not click.


Yeah, the way I do it is with a hybrid approach:

menu.onclick = function() { toggleClass(this, "opened"); };

.with-js menu > ul {
    display: none;
    /* or if you want it to roll, use the transition */
}

.with-js menu.open > ul {
    display: block;
}


and there you go. If you ask me, most your javascripts
should be changing classes, not actually doing the
work itself. That way, you keep the clean separation -
the class just represents the current state.

(indeed, with-js is another toggled class; put a little
script in the head that adds it to the html element.)



One downside of the css3 animations though is that
doing it without fixed height kinda sucks.

I wanted a quick foldout of something for the work
site. The simple height: 0px then open means
height: auto didn't work - you can't animate
to height: auto. Which sucks and they should
fix that, but apparently Apple's developers are
too incompetent to implement it in Safari, so
it gets left out of the standard. Or something
like that. I hate the standard, the process is
biased bullshit.


Anyway, to make it work, I ended up doing this:

/* overflow: hidden rox btw, use it a lot, you'll
thank me later */
max-height: 0px; overflow: hidden; transition: max-height 0.2s;

.open { max-height: 20em; }



Which gives the effect.. but the animation is from the
numbers given, not the actual height.

So, if you say max-height: 200em for instance, and
your content is only 20em tall, the visible animation
will complete in 0.02 seconds instead of 0.2!


Thus, I decided to pick an approximately right,
and call the animation time good enough.

The problem is now though: what if you add an item
to the drop down? If you don't remember to adjust
max-height too.... the new thing is just hidden.


Gah, the css is now dependent on the specific
content!



But, you don't always have to do this stuff
(BTW if anyone knows a better technique, let
me know!), and even so, it beats the crap
out of javascript animations.



 Mar 13 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:jjmmh3$9jb$1 digitalmars.com...

 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:oxkxtvkuybdommyerrke forum.dlang.org...

 On Tuesday, 13 March 2012 at 04:24:45 UTC, Nick Sabalausky wrote:

 2. On the web, animation means JS.


 css3 does animations that are pretty easy to use,
 degrade well, and tend to be fast. Moreover css
 is where it belongs anyway - it is pure presentation.


 Interesting, I had no idea! Thanks for the tip :)


 Far, far superior to the JS crap.


 Yea, there's a lot of things that are much better done in CSS that a lot 
 of people don't even know about. For example, most rollovers are easily 
 doable in pure CSS. But there's a lot stuff out there (paricularly things 
 created in Adobe's "software") that use JS for rollovers, which doesn't 
 even work as well (even with JS on).


Another thing is Flash. Almost *everyone* uses JS to embed flash. But *it's 
not needed*! I embed Flash with pure HTML and it works perfectly fine. Don't 
even need any server-side code! (You probably need JS to tell the user when 
they don't have Flash or, in some cases, when they don't have a new enough 
version, and suggest a download link. But including those features with JS 
still does *nothing* to prevent you from making the applet run without JS. 
And...It's not even a fallback! It's just embedding with method A instead of 
method B. And method A is, frankly, dead-simple.)



 Mar 13 2012



  parent reply David Gileadi <gileadis NSPMgmail.com>  writes:


On 3/13/12 12:28 PM, Nick Sabalausky wrote:

 Another thing is Flash. Almost *everyone* uses JS to embed flash. But *it's
 not needed*! I embed Flash with pure HTML and it works perfectly fine. Don't
 even need any server-side code!


I thought that using JS to load Flash was to avoid Eolas lawsuits. 
http://en.wikipedia.org/wiki/Eolas, Workarounds section.



 Mar 13 2012



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"David Gileadi" <gileadis NSPMgmail.com> wrote in message 
news:jjo7vn$648$1 digitalmars.com...

 On 3/13/12 12:28 PM, Nick Sabalausky wrote:

 Another thing is Flash. Almost *everyone* uses JS to embed flash. But 
 *it's
 not needed*! I embed Flash with pure HTML and it works perfectly fine. 
 Don't
 even need any server-side code!


 I thought that using JS to load Flash was to avoid Eolas lawsuits. 
 http://en.wikipedia.org/wiki/Eolas, Workarounds section.


Ugh, working for the USPTO should be a capital offense. So should submitting 
an application for a software patent.



 Mar 13 2012



prev sibling  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Tue, Mar 13, 2012 at 12:42:47PM -0700, David Gileadi wrote:

 On 3/13/12 12:28 PM, Nick Sabalausky wrote:

Another thing is Flash. Almost *everyone* uses JS to embed flash. But
*it's not needed*! I embed Flash with pure HTML and it works
perfectly fine. Don't even need any server-side code!


 
 I thought that using JS to load Flash was to avoid Eolas lawsuits.
 http://en.wikipedia.org/wiki/Eolas, Workarounds section.


Ugh. Yet another reason to hate Flash.

How I long for the day when Flash will die a long overdue horrible
death. I would soooo celebrate!!


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord.
Use it often, use it unsparingly, to subdue your listeners into
submission!



 Mar 13 2012



prev sibling  parent  James Miller <james aatch.net>  writes:


On 13 March 2012 17:23, Nick Sabalausky <a a.a> wrote:

 1. Such animations need to be *FAST*. We're talking roughly 250ms max
 (probably even less, but I'd have to play around with it to refresh my
 memory). Most UI animations are slower than this (particularly on the web -
 although many DVDs are *FAR* worse), and while it's good for first-time
 users, for everyone else it just gets in the way of getting work done and
 makes the experience feel sluggish.

 2. On the web, animation means JS. But not everyone is using a browser with
 that V8 engine or whatever it's called (the one that Chrome uses). And not
 everyone is using a quad-core system with 64-bit software and 16GB or
 whatever RAM, etc. like the well-supplied web developers are likely using.
 So frequently this means very choppy, sluggish animations. And that's a much
 worse UX than popping. This also gets in the way of being able to properly


 3. People have also reported that such UI animations can convey a subtle (or
 even not-so-subtle) sense of being patronized. Especially if it's a slower
 animation. I can definitely relate to this.

 (Of course, if people just make real applications instead of web apps, then
 those problems would be trivially solvable.)


Slow animations are a problem, but CSS transition are helping make
this less of an issue. And as long as you aren't trying to be too
over-the-top then your normally fine. Sliding tends to be ok for most
things, and fades are fast everywhere. I agree that slow animations
are annoying though, I only do it for things that are loading anyway,
so the slow animation doesn't actually slow down interaction. (I'm
talking 1-2 second-long credit card transaction situations).

--
James Miller



 Mar 12 2012



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:pfaikhejyfjpbpwwqrit forum.dlang.org...

 Then, he asked for a partial ajax load thing. Turns out that's
 trivially easy too. On the client:


That reminds me: "Trendy" web people seem to be a bit schizophrenic (I can't 
believe I spelled that right!) when it comes to "thin vs thick clients". 
They're into "cloud" this and "cloud" that, and always web-based naturally, 
so obviously they're into thin clients. But then they cram it so full of JS 
that they're literally turning their beloved thin "cloud" client into an 
ad-hoc thick client.

Makes me want yell at them: Just cut the crap, admit you want a think 
client, and make a *real* thick client. If you want trivial installation, 
start backing and pushing for something like 0-install. If you want 
cross-platform, use a cross-platform toolkit. You want network connectivity? 
Use curl, or any other networking lib. Ultimately, you'll get the *same* 
effect, but with better system integration, much less incompatibility 
bullshit, never have to deal with IE, don't need to wait for HTML5/canvas 
penetrarion, use whatever language you damn well please, and you get all 
these without all that "middleman" bloat. (And you can do more to make 
reverse engineering harder if you're into closed-source.)


 Now, there *are* cases where you can't do this so easily.
 If you're stuck on poor PHP I'm sure this is harder than
 in D too... but really, do you have one of those cases?


And even if you are stuck with PHP, you really should just be using 
something like Haxe instead. (IMO)



 Mar 12 2012



prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at>  writes:


On Monday, 12 March 2012 at 23:04:17 UTC, Nick Sabalausky wrote:

 Does nobody understand basic statistics?

 First of all, 1-2% is a *hell* of a *LOT* of people. Don't be 
 fooled by the
 seemingly small number: It's a percentage and it's out of a 
 *very* large
 population. So 1-2% is still *huge*.


And 1-2% is still 1/100 to 1/50 of all users, no matter how large 
the total number is. Arguing in absolute numbers makes no sense 
if you don't even know in advance how large your target audience 
is. What point are you trying to make here?


 B. Look at audience: That's *Yahoo*. How many of the technical 
 people you
 know use Yahoo? Yahoo is primarily an "Average Joe" site, but 
 disabling
 JavaScript is a power-user thing. It's not a representative 
 sample, and it
 *certainly* can't be assumed to be applicable to something like 
 Dr. Dobbs.

 C. Things such as Google Analytics are based on JS. So right 
 there I have
 questions about whether or not such things accurately record 
 all non-JS
 users in the first place.


Stats are pretty much the same (98.5% among ~10000 »unique« 
visitors over the last months) for my programming-centric blog, 
where I added a non-JS tracking pixel precisely because I was 
interested in whether the figures would different for tech-y 
sites.

Besides, I am totally in favor of not needlessly required JS, but 
it does have its legitimate uses.

David



 Mar 12 2012



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"David Nadlinger" <see klickverbot.at> wrote in message 
news:zlzlrudlbyiwwmgqqftp forum.dlang.org...

 Besides, I am totally in favor of not needlessly required JS, but it does 
 have its legitimate uses.


*Using* it is fine as long as you don't go overboard. The issue is 
*requiring* it when it obviously isn't needed.



 Mar 12 2012



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"David Nadlinger" <see klickverbot.at> wrote in message 
news:zlzlrudlbyiwwmgqqftp forum.dlang.org...

 Stats are pretty much the same (98.5% among ~10000 unique visitors over 
 the last months) for my programming-centric blog, where I added a non-JS 
 tracking pixel precisely because I was interested in whether the figures 
 would different for tech-y sites.


Maybe a stupid question, but is there anything on those pages that requires 
JS? Because if so, then naturally you'll get fewer non-JS-visiters.



 Mar 12 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:jjlvdh$1to3$1 digitalmars.com...

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
 news:op.wa2pimkxeav7ka localhost.localdomain...

 On Mon, 12 Mar 2012 15:27:30 -0400, Nick Sabalausky <a a.a> wrote:


 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.wa1432xjeav7ka localhost.localdomain...

 On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky <a a.a> wrote:


 You know what I think it is (without actually looking at the code): I
 think
 they tried to do some highly misguided and even more poorly 
 implemented
 hack
 (which they no-doubt thought was clever) for dealing with *cough* 
 "old"
 *cough* browsers by inserting a meta redirect to a hardcoded URL, and
 then
 used JS to disable the meta redirect. If that's the case, I don't know
 how
 the fuck they managed to convince themselves that make one drop of 
 sense.


 It could be that they don't care to cater to people who hate JS.  There
 aren't that many of you.


 There are enough.


 Apparently not. 
 http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/

 I'm perfectly willing to give up on 1-2% of Internet users who have JS 
 disabled.


 Does nobody understand basic statistics?

 First of all, 1-2% is a *hell* of a *LOT* of people. Don't be fooled by 
 the seemingly small number: It's a percentage and it's out of a *very* 
 large population. So 1-2% is still *huge*.

 Secondly, I don't believe for a minute that such figures accurately 
 represent *all* non-JS users:

 A. Most non-JS users *do* occasionally switch JS on when they need to via 
 NoScript, etc. So that right there is *guaranteed* to leave the results 
 biased towards the "use JS" side.

 B. Look at audience: That's *Yahoo*. How many of the technical people you 
 know use Yahoo? Yahoo is primarily an "Average Joe" site, but disabling 
 JavaScript is a power-user thing. It's not a representative sample, and it 
 *certainly* can't be assumed to be applicable to something like Dr. Dobbs.

 C. Things such as Google Analytics are based on JS. So right there I have 
 questions about whether or not such things accurately record all non-JS 
 users in the first place.



 And it's beside the point anyway. Things that don't need
 JS sholdn't be using JS anyway, regardless of whether you hate it or 
 have
 enough brain damage to think it's the greatest thing since the 
 transistor.


 No, it *is* the point.  As a web developer, javascript is used by the 
 vast majority of users, so I assume it can be used.  If you don't like 
 that, I guess that's too bad for you, you may go find content elsewhere. 
 It's not worth my time to cater to you.


 And it's not worth my time to use your piece of shit excuse for a site.


And besides, you're still conventiently ignoring the fact that sites which 
require JS typically provide a *worse* user experience then sites that don't 
use it, *even when JS is enabled*.

So you want to say "fuck off" to the millions of people in that "measly" 
1-2% just for the sake of making your site *worse* for the other 98%? Fine, 
be a self-defeating idiot, if you insist.

And before you say "No! They like it better with the JS-ness!", I'll point 
out that most people only *think* they know what they like. Don't forget 
what happened when Vladimir's D forums were posted on Reddit: All those 
JS-using redditers (reddit requires JS for most features, so it's safe to 
assume most reddit users are JS users - non-JS users are likely to avoid 
reddit) who *thought* reddit had a reasonable user-experience were absoutely 
*floored* by how "fast" the D forums were. (Personally, I find the D forms 
to be normal speed and reddit to be absurdly slow.) JS-users *prefer* non-JS 
sites - they're just too brainwashed to realize it.

Notice too how those forums load entire pages faster than AJAXy sites like 
GitHub do their beloved partial reloads.



 Mar 12 2012



  parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:jjm0c8$1vk8$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:jjlvdh$1to3$1 digitalmars.com...

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
 news:op.wa2pimkxeav7ka localhost.localdomain...

 No, it *is* the point.  As a web developer, javascript is used by the 
 vast majority of users, so I assume it can be used.  If you don't like 
 that, I guess that's too bad for you, you may go find content elsewhere. 
 It's not worth my time to cater to you.


 And it's not worth my time to use your piece of shit excuse for a site.


 And besides, you're still conventiently ignoring the fact that sites which 
 require JS typically provide a *worse* user experience then sites that 
 don't use it, *even when JS is enabled*.

 So you want to say "fuck off" to the millions of people in that "measly" 
 1-2% just for the sake of making your site *worse* for the other 98%? 
 Fine, be a self-defeating idiot, if you insist.


I don't mean to call you personally an idiot, I apologize if it came across 
that way (as it probably did the way I worded it). I just meant it in terms 
of "you" as in "hypothetical person, for the sake of argument". Sometimes I 
word things really badly.



 Mar 12 2012



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.wa1432xjeav7ka localhost.localdomain...

 You may want to consider -- if you on principle don't view pages with 
 information because the pages contain JS, you are the one missing out on 
 the information.


And it's not on principle, I just find it not usually worth bothering. I'd 
rather just move on to something else that's actually well designed. Problem 
though is when content gets *tied* to such moronic things. Even if 99% of 
people don't hate JS, these uses of it *are* still moronic bullshit.



 Mar 12 2012



prev sibling next sibling parent reply "so" <so so.so>  writes:


On Saturday, 10 March 2012 at 05:06:40 UTC, Andrei Alexandrescu 
wrote:


 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


While i tend to code that way it is not as pretty in C++ as it 
looks on paper when you use namespaces.

namespace ns {
   struct S {
     void b();
   }

   void b(S s);
}

auto s = ns::S;
s.b() // fine
ns::b(s) // uh..

It gets much worse when S is somewhere deep in many namespaces.
ADL helps but it is also unreliable. I think D doesn't have this 
issue.



 Mar 10 2012



  parent  "so" <so so.so>  writes:


On Saturday, 10 March 2012 at 09:25:28 UTC, so wrote:


 While i tend to code that way it is not as pretty in C++ as it 
 looks on paper when you use namespaces.

 namespace ns {
   struct S {
     void b();
   }

   void b(S s);
 }

 auto s = ns::S;
 s.b() // fine
 ns::b(s) // uh..

 It gets much worse when S is somewhere deep in many namespaces.
 ADL helps but it is also unreliable. I think D doesn't have 
 this issue.


And... at the end of the article he also mentions this.



 Mar 10 2012



prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Mar 09, 2012 at 09:06:40PM -0800, Andrei Alexandrescu wrote:
[...]

 Insert obligatory link: http://drdobbs.com/184401197
 
 Very insightful article.


[...]

Wow. That's quite an interesting read, especially since it goes against
conventional wisdom that non-member non-friend functions are "bad".

But I see why this totally makes sense. Recently I looked up David
Parnas' revolutionary paper about information hiding (the paper that
started it all), from which it's very clear that the basic motivation
behind encapsulation is resilience in the face of inevitable change. So
the article linked above totally makes sense. Breaking changes tend to
happen inside a class, so if something doesn't *need* access to private
members, then it doesn't, and shouldn't, need to be a class member.

In retrospect, I do find myself frequently factorizing code *within* a
class such that most member functions don't actually need direct access
to private members, or if they do, they use as few private members as
possible to do what they need to do. So by Dr. Dobbs' standard, most of
these member functions ought to be external to the class proper.

This is where UFCS really shines... now I *can* actually move these
members out of the class, and it doesn't even change the class API!
Plus, *users* can add new pseudo-members and it extensibly enhances the
class API while retaining that resilience to change.

D is getting more awesome by the day. Now I truly can't convince myself
to go back to C++!


T

-- 
There are two ways to write error-free programs; only the third one works.



 Mar 10 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.412.1331398464.4860.digitalmars-d puremagic.com...

 Breaking changes tend to
 happen inside a class, so if something doesn't *need* access to private
 members, then it doesn't, and shouldn't, need to be a class member.


Unless they need polymorphism :(


 In retrospect, I do find myself frequently factorizing code *within* a
 class such that most member functions don't actually need direct access
 to private members, or if they do, they use as few private members as
 possible to do what they need to do. So by Dr. Dobbs' standard, most of
 these member functions ought to be external to the class proper.

 This is where UFCS really shines... now I *can* actually move these
 members out of the class, and it doesn't even change the class API!
 Plus, *users* can add new pseudo-members and it extensibly enhances the
 class API while retaining that resilience to change.


It also has the benefit of shrinking the vtables of each instance. (Although 
I think 'final' might have the same effect if used the same way?)


 D is getting more awesome by the day. Now I truly can't convince myself
 to go back to C++!


Totally. But I had given up on C++ ten years ago. Unfortunately, as I may be 
getting into some iOS/Android game dev soon (likely with Marmalade, since 
Corona looks to be little more than a shiny overpriced toy - just like its 
older brother Flash), I may need to start using C++ again. Ugh. I love game 
dev, but I'm not looking forward to that aspect of it. Mature Arm support 
for D can't come soon enough! If there were a date, I'd be counting the 
days.


 There are two ways to write error-free programs; only the third one works.


Heh, once again, a gem. I also laughed out loud at the "That phone number is 
imaginary, rotate your phone 90 degrees and try again".



 Mar 10 2012



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sat, Mar 10, 2012 at 02:56:00PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.412.1331398464.4860.digitalmars-d puremagic.com...

 Breaking changes tend to happen inside a class, so if something
 doesn't *need* access to private members, then it doesn't, and
 shouldn't, need to be a class member.


 
 Unless they need polymorphism :(


True.

Every now and then I still mull over how to reconcile class hierarchies
with generic programming. I mean, inheritance and polymorphism are
definitely very powerful concepts, but once you throw templates into the
mix, the two don't quite get along very well (they try to, but every now
and then they get into a fight). I mean, conceptually speaking,
templated members should be polymorphic too, but then it's impossible to
implement in code.

Really makes me wonder if there's something out there, some brand new
unifying concept, that can marry the two and retain their best
characteristics. Or perhaps a revolutionary new concept that replaces
inheritance and templates with something even more powerful.



 In retrospect, I do find myself frequently factorizing code *within*
 a class such that most member functions don't actually need direct
 access to private members, or if they do, they use as few private
 members as possible to do what they need to do. So by Dr. Dobbs'
 standard, most of these member functions ought to be external to the
 class proper.

 This is where UFCS really shines... now I *can* actually move these
 members out of the class, and it doesn't even change the class API!
 Plus, *users* can add new pseudo-members and it extensibly enhances
 the class API while retaining that resilience to change.


 
 It also has the benefit of shrinking the vtables of each instance.
 (Although I think 'final' might have the same effect if used the same
 way?)


I don't know about that, what if it's a final override? (Or is that
illegal in D?)



 D is getting more awesome by the day. Now I truly can't convince
 myself to go back to C++!


 
 Totally. But I had given up on C++ ten years ago. Unfortunately, as I
 may be getting into some iOS/Android game dev soon (likely with
 Marmalade, since Corona looks to be little more than a shiny
 overpriced toy - just like its older brother Flash), I may need to
 start using C++ again. Ugh. I love game dev, but I'm not looking
 forward to that aspect of it. Mature Arm support for D can't come soon
 enough! If there were a date, I'd be counting the days.


When I picked up D, one of my hopes was to use it for game dev. I had
just started an SDL project in C++, but later decided to abort it in
favor of D. Sadly, the current implementation of D still has some
wrinkles to be straightened out before it's usable for real game dev.
:-(



 There are two ways to write error-free programs; only the third one
 works.


 
 Heh, once again, a gem. I also laughed out loud at the "That phone
 number is imaginary, rotate your phone 90 degrees and try again".


[...]

One of the ones that made me LOL when I first heard it was:

	I am Ohm of Borg. Resistance is voltage over current.

:-)


T

-- 
Famous last words: I wonder what will happen if I do *this*...



 Mar 10 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.436.1331412193.4860.digitalmars-d puremagic.com...

 On Sat, Mar 10, 2012 at 02:56:00PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.412.1331398464.4860.digitalmars-d puremagic.com...

 Breaking changes tend to happen inside a class, so if something
 doesn't *need* access to private members, then it doesn't, and
 shouldn't, need to be a class member.


 Unless they need polymorphism :(


 True.

 Every now and then I still mull over how to reconcile class hierarchies
 with generic programming. I mean, inheritance and polymorphism are
 definitely very powerful concepts, but once you throw templates into the
 mix, the two don't quite get along very well (they try to, but every now
 and then they get into a fight). I mean, conceptually speaking,
 templated members should be polymorphic too, but then it's impossible to
 implement in code.

 Really makes me wonder if there's something out there, some brand new
 unifying concept, that can marry the two and retain their best
 characteristics. Or perhaps a revolutionary new concept that replaces
 inheritance and templates with something even more powerful.


My understanding is that the *only* thing preventing vitrual template 
functions is the possibility of pre-compiled closed-source static libs. 
Which is why I've long been in favor of allowing vitrual template functions 
*as long as* there's no closed-source static libs preventing it. Why should 
OSS have to pay costs that only apply to closed source?


 It also has the benefit of shrinking the vtables of each instance.
 (Although I think 'final' might have the same effect if used the same
 way?)


 I don't know about that, what if it's a final override? (Or is that
 illegal in D?)


That's what I was alluding to with "if used the same way". Ie, if it's 
statically know to not override or be overridden (I guess I wasn't clear). 
I'm pretty sure D allows final override, and yea, naturally that would 
require a vtable entry. But if it's a non-override final, a vtable entry 
isn't necessary.

Now, as for whether or not D actually *does* omit the vtable entry for 
non-override finals, I wouldn't know. Although I seem to vaguely remember 
doing optimizations once that seemed to imply it did. If that's so, I don't 
know whether its guaranteed per D spec or just implementation-defined. A 
UFCS approach would definitely be guaranteed not to affect the vtable, of 
course.



 There are two ways to write error-free programs; only the third one
 works.


 Heh, once again, a gem. I also laughed out loud at the "That phone
 number is imaginary, rotate your phone 90 degrees and try again".


 [...]

 One of the ones that made me LOL when I first heard it was:

 I am Ohm of Borg. Resistance is voltage over current.

 :-)


Heh :)


 -- 
 Famous last words: I wonder what will happen if I do *this*...


Another great one, which is very similar to one I've enjoyed repeating:

What are a redneck's last words? "Hey y'all, watch this!"

Not sure where that's from, but Jeff Foxworthy would probably be a safe 
guess.



 Mar 10 2012



 next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:jjh9uh$1vto$1 digitalmars.com...

 My understanding is that the *only* thing preventing vitrual template 
 functions is the possibility of pre-compiled closed-source static libs. 
 Which is why I've long been in favor of allowing vitrual template 
 functions *as long as* there's no closed-source static libs preventing it. 
 Why should OSS have to pay costs that only apply to closed source?


That's not really it...

The problem is that vtables contain every virtual function of a class - and 
if you instantiate a template function with a new type, it would require a 
new vtable entry.  Therefore you need to know how every template function in 
every derived class is instantiated before you can build the base class 
vtable.  This doesn't work with D's compilation model.


 Now, as for whether or not D actually *does* omit the vtable entry for 
 non-override finals, I wouldn't know. Although I seem to vaguely remember 
 doing optimizations once that seemed to imply it did. If that's so, I 
 don't know whether its guaranteed per D spec or just 
 implementation-defined. A UFCS approach would definitely be guaranteed not 
 to affect the vtable, of course.


D (dmd) does not create a vtable entry for final functions that don't 
override anything.  It's in the frontend, so it should be the same for all 
the d compilers. 



 Mar 10 2012



 next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Daniel Murphy" <yebblies nospamgmail.com> wrote in message 
news:jjhcj8$25sv$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:jjh9uh$1vto$1 digitalmars.com...

 My understanding is that the *only* thing preventing vitrual template 
 functions is the possibility of pre-compiled closed-source static libs. 
 Which is why I've long been in favor of allowing vitrual template 
 functions *as long as* there's no closed-source static libs preventing 
 it. Why should OSS have to pay costs that only apply to closed source?


 That's not really it...

 The problem is that vtables contain every virtual function of a class - 
 and if you instantiate a template function with a new type, it would 
 require a new vtable entry.  Therefore you need to know how every template 
 function in every derived class is instantiated before you can build the 
 base class vtable.  This doesn't work with D's compilation model.


Right, but when I tell something like rdmd to pass all my files into DMD, 
then DMD *does* have all the information needed. I understand that it can't 
be done in *all* build setups, but it would seem to be possible in many 
build setups, so why should *all* projects suffer when really only *some* 
projects have to have that limitation? That's what I've never understood.


 Now, as for whether or not D actually *does* omit the vtable entry for 
 non-override finals, I wouldn't know. Although I seem to vaguely remember 
 doing optimizations once that seemed to imply it did. If that's so, I 
 don't know whether its guaranteed per D spec or just 
 implementation-defined. A UFCS approach would definitely be guaranteed 
 not to affect the vtable, of course.


 D (dmd) does not create a vtable entry for final functions that don't 
 override anything.  It's in the frontend, so it should be the same for all 
 the d compilers.


I see. Thanks.



 Mar 11 2012



prev sibling  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sun, 11 Mar 2012 00:18:31 -0500, Daniel Murphy  
<yebblies nospamgmail.com> wrote:


 "Nick Sabalausky" <a a.a> wrote in message
 news:jjh9uh$1vto$1 digitalmars.com...

 My understanding is that the *only* thing preventing vitrual template
 functions is the possibility of pre-compiled closed-source static libs.
 Which is why I've long been in favor of allowing vitrual template
 functions *as long as* there's no closed-source static libs preventing  
 it.
 Why should OSS have to pay costs that only apply to closed source?


 That's not really it...

 The problem is that vtables contain every virtual function of a class -  
 and
 if you instantiate a template function with a new type, it would require  
 a
 new vtable entry.  Therefore you need to know how every template  
 function in
 every derived class is instantiated before you can build the base class
 vtable.  This doesn't work with D's compilation model.


You could do it if the vtable was a hash instead of an array (or at least  
the template portion was).  But that's just asking for horrible  
performance, and I don't think it's worth it.

But I think it is possible...

-Steve



 Mar 12 2012



prev sibling  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sat, Mar 10, 2012 at 11:31:47PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.436.1331412193.4860.digitalmars-d puremagic.com...


[...]

 My understanding is that the *only* thing preventing vitrual template
 functions is the possibility of pre-compiled closed-source static
 libs.  Which is why I've long been in favor of allowing vitrual
 template functions *as long as* there's no closed-source static libs
 preventing it. Why should OSS have to pay costs that only apply to
 closed source?


I thought the reason was that every instance of the template will need a
vtable entry, and the compiler may not be able to know beforehand which
instances will actually exist? You *could* in theory have the compiler
scan the entire program for all instances, I suppose, but that will
prevent incremental compilation and loading of dynamic libs, OSS or not.
Plus it may slow down the compiler significantly.


[...]

 Another great one, which is very similar to one I've enjoyed
 repeating:
 
 What are a redneck's last words? "Hey y'all, watch this!"


[...]

And another one in response:

	Famous last words: I *think* this will work...


T

-- 
It won't be covered in the book. The source code has to be useful for
something, after all. -- Larry Wall



 Mar 10 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.453.1331446837.4860.digitalmars-d puremagic.com...

 On Sat, Mar 10, 2012 at 11:31:47PM -0500, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.436.1331412193.4860.digitalmars-d puremagic.com...


 [...]

 My understanding is that the *only* thing preventing vitrual template
 functions is the possibility of pre-compiled closed-source static
 libs.  Which is why I've long been in favor of allowing vitrual
 template functions *as long as* there's no closed-source static libs
 preventing it. Why should OSS have to pay costs that only apply to
 closed source?


 I thought the reason was that every instance of the template will need a
 vtable entry, and the compiler may not be able to know beforehand which
 instances will actually exist? You *could* in theory have the compiler
 scan the entire program for all instances, I suppose, but that will
 prevent incremental compilation and loading of dynamic libs, OSS or not.
 Plus it may slow down the compiler significantly.


What I'm suggesting is flipping that around: Instead of saying "Virtual 
template functions prevent incremental compilation and dynamic libs: And 
that's an unreasonable limitation", we say "Incremental compilation and 
dynamic libs prevent virtual template functions: So *if you need to use 
those*, you can't use virtual template functions."

Keep in mind too, that even incremental compilation and dynamic libs *can* 
still work with virtual template functions *provided that* there's no 
overriding across compilation unit boundaries. I don't think that's a 
totally unreasonable limitation for virtual template functions to be 
worthwhile for _many_ people, even if it doesn't make virtual template 
functions practical for *everyone*.


 [...]

 Another great one, which is very similar to one I've enjoyed
 repeating:

 What are a redneck's last words? "Hey y'all, watch this!"


 [...]

 And another one in response:

 Famous last words: I *think* this will work...


Yet another one, I just recently came across (not actually for real, but it 
would be funny):

Written on someone's tombstone: "I *told* you I was sick!"

Along similar lines (this one's a true story), my Dad's Aunt and Uncle 
bought their own tombstone ahead of time, and had their picture taken 
sitting on each side of it, both of them smoking. (The irony was, of course, 
deliberate. My family's a bit weird ;) )



 Mar 11 2012



  parent  Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 11/03/2012 09:15, Nick Sabalausky wrote:


 Written on someone's tombstone: "I *told* you I was sick!"


Spike Milligan's epitaph reads "Duirt m leat go raibh m breoite", 
Irish for "I told you I was ill."

A...



 Mar 11 2012



prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar>  writes:


On 03/10/2012 02:06 AM, Andrei Alexandrescu wrote:

 On 3/9/12 5:05 PM, Adam D. Ruppe wrote:

 On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:

 At first I didn't like it a lot because it's cheap syntax sugar that
 adds no new power and gives programmers more freedom to write
 different-looking versions of the the same code (and this is often bad).


 What I like about is the encapsulation benefits. You
 don't have to know if the function is a method or an
 external function, it just works.

 External, non-friend (so separate module in D) functions
 are often preferable to methods because they don't have
 access to the class' private members, so they cannot rely
 on those implementation details.

 Extending objects with new functions in this way also
 means you don't break binary compatibility with the
 existing code, since it isn't modified at all!


 Of course, you could always do this with the old
 syntax too, but then the syntax preference means
 you are biased toward one implementation or the
 other - it doesn't mesh as well and you may be
 tempted to make things methods for the syntax,
 despite the cost in compatibility.

 UFCS rox.


 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


 Andrei


How can:

class Wombat {
   void nap() {
     this->sleep();
   }
}

increase encapsulation? It's using public API, so client code can't 
break if you keep the sleep method there.

Now, I do agree that it's nice to not have additional methods defined 
because it speeds up parsing and doesn't bloat the interface. I just 
don't agree with implementing it as UFCS.

Take a look a this:

void nap(Wombat wombat) { }
void somethingElse(Wombat wombat, int x) { }
void anotherThing(Wombat wombat, int x) { }

Compared to this:

class Wombat {
   void nap() {}
   void somethingElse(int x);
   void anotherThing(int x);
}

Shorter, grouped, cleaner (in my opinion). No repetition of Wombat all 
over the place.

In fact, it should be much easier to implement. When extending a class, 
associate those methods to the class, then do a normal lookup. With UFCS 
you'd have to look for a global function whose first parameter is the 
Wombat. So you have two searches: first find members, then public 
functions (I wonder why UFCS is not completely implemented so far).

Explaining an extension method is also easy: "If you extend a class's 
methods, those can only access public member functions". Now you'd have 
to say "Any global function that has this class as a first parameter can 
be invoked as a member function, removing this first parameter".

Well... I'm just looking for consistency.

This is exactly what happens in Ruby:

irb(main):001:0> Time.parse "2012-01-02"
NoMethodError: undefined method `parse' for Time:Class
	from (irb):1
	from :0
irb(main):002:0> require 'time'
=> true
irb(main):003:0> Time.parse "2012-01-02"
=> Mon Jan 02 00:00:00 -0300 2012

Well, in Ruby you can access private members in those extensions... I 
don't want that in D. So I guess one complaint for what I'm saying is 
"Oh, people will think that you can access private members in those 
extensions because they have the same syntax blah blah blah".



 Mar 10 2012



  parent  Ary Manzana <ary esperanto.org.ar>  writes:


On 03/10/2012 10:03 PM, Ary Manzana wrote:

 On 03/10/2012 02:06 AM, Andrei Alexandrescu wrote:

 On 3/9/12 5:05 PM, Adam D. Ruppe wrote:

 On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:

 At first I didn't like it a lot because it's cheap syntax sugar that
 adds no new power and gives programmers more freedom to write
 different-looking versions of the the same code (and this is often
 bad).


 What I like about is the encapsulation benefits. You
 don't have to know if the function is a method or an
 external function, it just works.

 External, non-friend (so separate module in D) functions
 are often preferable to methods because they don't have
 access to the class' private members, so they cannot rely
 on those implementation details.

 Extending objects with new functions in this way also
 means you don't break binary compatibility with the
 existing code, since it isn't modified at all!


 Of course, you could always do this with the old
 syntax too, but then the syntax preference means
 you are biased toward one implementation or the
 other - it doesn't mesh as well and you may be
 tempted to make things methods for the syntax,
 despite the cost in compatibility.

 UFCS rox.


 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


 Andrei


 How can:

 class Wombat {
 void nap() {
 this->sleep();
 }
 }

 increase encapsulation? It's using public API, so client code can't
 break if you keep the sleep method there.

 Now, I do agree that it's nice to not have additional methods defined
 because it speeds up parsing and doesn't bloat the interface. I just
 don't agree with implementing it as UFCS.

 Take a look a this:

 void nap(Wombat wombat) { }
 void somethingElse(Wombat wombat, int x) { }
 void anotherThing(Wombat wombat, int x) { }

 Compared to this:

 class Wombat {
 void nap() {}
 void somethingElse(int x);
 void anotherThing(int x);
 }

 Shorter, grouped, cleaner (in my opinion). No repetition of Wombat all
 over the place.

 In fact, it should be much easier to implement. When extending a class,
 associate those methods to the class, then do a normal lookup. With UFCS
 you'd have to look for a global function whose first parameter is the
 Wombat. So you have two searches: first find members, then public
 functions (I wonder why UFCS is not completely implemented so far).


I forgot to say: if you implement it by associating it to the type, you 
can also use the current method lookup algorithm because it will search 
in super classes. With UFCS you'd have to search for public functions 
whose first parameter are B, then public functions whose first parameter 
are A, etc, assuming A extends B.

So not only it's easier to write and read, but also easier to implement.



 Mar 10 2012



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 10 Mar 2012 00:06:40 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


Interesting point to make about D, however.  It's really *difficult* to  
make related non-member non-friend functions, since all functions inside  
the same module as a type are friends.  In order to follow the  
recommendations, D non-member non-friend functions must go in another  
*module*.

I don't necessarily agree with the argument, because it's a  
fully-objective view of something that is very subjective.

For instance:

class A
{
    private int a;
}

class B
{
    private int b;
}

void nonMemberBFunction(B b)
{
    b.b = 5;
}

Not only is nonMemberBFunction potentially dependent on B's  
implementation, but it's also potentially dependent (by Scott's rules) on  
A's implementation.  Therefore, A has less encapsulation.

But any sane person can see that nonMemberBFunction does not access A.   
Since everything to be examined/updated when updating A's implementation  
is in the same file (and that implementation is readily available), I  
think you should not count non-member functions that don't *access* the  
class in question against the encapsulation factor.  Yes, this makes  
things more reliant on convention (i.e. denote in documentation somehow  
what functions access private data), but since you can't turn friends off  
without extreme practices, I don't think you have any other sane choices.

In D, interestingly, making things member functions is not any different  
than making them non-members, it seems.  In fact, I'd argue it's *more*  
appropriate in D to make things member functions, since it serves as  
implicit documentation that it likely accesses only the class members.  I  
wonder what Scott would say about that?

-Steve



 Mar 12 2012



  parent  "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.wa16bibneav7ka localhost.localdomain...

 On Sat, 10 Mar 2012 00:06:40 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Insert obligatory link: http://drdobbs.com/184401197

 Very insightful article.


 Interesting point to make about D, however.  It's really *difficult* to 
 make related non-member non-friend functions, since all functions inside 
 the same module as a type are friends.


Geez, I *still* keep forgetting about that. And I'm not sure I've ever 
really found it particularly useful. I'd be happy to see that go away in D3. 
Acually, I'd argue in favor of changing "private" to "module" (much like how 
we have the "package" access specifier) and then adding a more traditional 
private. I doubt any of this will ever actually happen. But, oh well, one 
can dream.



 Mar 12 2012



prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Friday, March 09, 2012 16:16:56 Brad Anderson wrote:

 On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:

 I'll say I *don't* agree with the rejection of aliases on principle --
 aliases can be extremely useful/helpful, and they cost literally nothing
 (the "cognitive cost" on the docs is a BS argument IMO). I just don't
 agree with consuming so many common symbols for the sake of sugar.


 
 aliases need to have a really good argument for existing. If UFCS is fully
 implemented, then I think that there is _some_ argument for having stuff
 like
 hours and minutes, because then you can do stuff like 5.seconds() (though
 honestly, I really don't like the idea). The alias enables different
 usages
 rather than simply being another name for the same thing.
 
 Now, in this particular case, it's that much worse for exactly the reason
 that
 you're against it: it uses common names for free functions. It's not as
 big a
 problem as it would be in C or C++, but it's still a problem. There's also
 some risk that it will break code.


 
 Oh, and I'd just like to add some of my experience to this. These names are
 used by Boost's datetime library and they've never been a problem for me
 and at work we make extensive use of Boost datetime. There is risk but I
 think in this specific case they are fairly small (especially in D, over
 C++). We switched to Boost datetime after we had hundreds of thousands of
 lines of code written using a different system and I didn't encounter any
 problems with the duration shortcut functions clashing.
 
 Anyway, it sounds like Walter is probably opposed from what he was saying
 in the other thread so this conversation is probably moot.


I'd say that there's a higher chance of the aliases being added than of dur 
being changed to duration. Changing dur will _definitely_ break code and make 
using it worse for exactly the same reason that it's dur in the first place - 
it's too long when combined with the required units string. The aliases might 
break code, but it's probably only in cases where someone already has free 
functions with those names, and it's more likely that they'll have variables 
with those names, which are less likely to conflict.

So, while I don't really like the idea of adding the aliases, they _might_ be 
added, because they probably won't break anything, and they enable UFCS. But 
there's not a good enough reason to change dur to duration at this point.

- Jonathan M Davis



 Mar 09 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.366.1331335812.4860.digitalmars-d puremagic.com...

 On Friday, March 09, 2012 16:16:56 Brad Anderson wrote:

 On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis 
 <jmdavisProg gmx.com>wrote:

 On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:

 I'll say I *don't* agree with the rejection of aliases on 
 principle --
 aliases can be extremely useful/helpful, and they cost literally 
 nothing
 (the "cognitive cost" on the docs is a BS argument IMO). I just don't
 agree with consuming so many common symbols for the sake of sugar.


 aliases need to have a really good argument for existing. If UFCS is 
 fully
 implemented, then I think that there is _some_ argument for having 
 stuff
 like
 hours and minutes, because then you can do stuff like 5.seconds() 
 (though
 honestly, I really don't like the idea). The alias enables different
 usages
 rather than simply being another name for the same thing.

 Now, in this particular case, it's that much worse for exactly the 
 reason
 that
 you're against it: it uses common names for free functions. It's not as
 big a
 problem as it would be in C or C++, but it's still a problem. There's 
 also
 some risk that it will break code.


 Oh, and I'd just like to add some of my experience to this. These names 
 are
 used by Boost's datetime library and they've never been a problem for me
 and at work we make extensive use of Boost datetime. There is risk but I
 think in this specific case they are fairly small (especially in D, over
 C++). We switched to Boost datetime after we had hundreds of thousands of
 lines of code written using a different system and I didn't encounter any
 problems with the duration shortcut functions clashing.

 Anyway, it sounds like Walter is probably opposed from what he was saying
 in the other thread so this conversation is probably moot.


 I'd say that there's a higher chance of the aliases being added than of 
 dur
 being changed to duration. Changing dur will _definitely_ break code and 
 make
 using it worse for exactly the same reason that it's dur in the first 
 place -
 it's too long when combined with the required units string. The aliases 
 might
 break code, but it's probably only in cases where someone already has free
 functions with those names, and it's more likely that they'll have 
 variables
 with those names, which are less likely to conflict.

 So, while I don't really like the idea of adding the aliases, they _might_ 
 be
 added, because they probably won't break anything, and they enable UFCS. 
 But
 there's not a good enough reason to change dur to duration at this point.


They eliminate the *entire* reason for it ever even being "dur" in the first 
place.

Of course, if this incarnation of std.datetime were a few years old, then 
I'd likely agree with you, but it *is* still relatively new.



 Mar 09 2012



  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday, March 10, 2012 02:21:56 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message

 I'd say that there's a higher chance of the aliases being added than of
 dur
 being changed to duration. Changing dur will _definitely_ break code and
 make
 using it worse for exactly the same reason that it's dur in the first
 place -
 it's too long when combined with the required units string. The aliases
 might
 break code, but it's probably only in cases where someone already has free
 functions with those names, and it's more likely that they'll have
 variables
 with those names, which are less likely to conflict.
 
 So, while I don't really like the idea of adding the aliases, they _might_
 be
 added, because they probably won't break anything, and they enable UFCS.
 But
 there's not a good enough reason to change dur to duration at this point.


 
 They eliminate the *entire* reason for it ever even being "dur" in the first
 place.


No, they don't. You have to keep dur if you want to enable generic code. Yes, 
if the aliases get added, people can choose to use them instead, but that 
doesn't negate the value of dur. It only makes it so that it's not the only 
option.


 Of course, if this incarnation of std.datetime were a few years old, then
 I'd likely agree with you, but it *is* still relatively new.


As far as I'm concerned, changing dur to duration breaks code to no benefit. 
It's a pointless renaming. And regardless of how new core.time and 
std.datetime are, pretty much any D code doing date/time stuff right now will 
be using it unless it hasn't been updated any time recently, because std.date 
has been deprecated, and it's going to be removed in the next release.

So, as far as I'm concerned, there is _no_ way that dur is going to be change 
to duration. And that's exactly the sort of thing that Walter is complaining 
about in his thread of making breaking changes.

We might merge in the aliases, since they'll improve the situation with UFCS, 
but there's no way that dur is getting changed. It's a trivial change for 
trivial benefit, and honestly, I think that it's _worse_ for the very reasons 
that I chose dur in the first place. dur!"hours" is pretty much just as clear 
as duration!"hours", and it's shorter.

- Jonathan M Davis



 Mar 09 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.399.1331365602.4860.digitalmars-d puremagic.com...

 On Saturday, March 10, 2012 02:21:56 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message

 I'd say that there's a higher chance of the aliases being added than of
 dur
 being changed to duration. Changing dur will _definitely_ break code 
 and
 make
 using it worse for exactly the same reason that it's dur in the first
 place -
 it's too long when combined with the required units string. The aliases
 might
 break code, but it's probably only in cases where someone already has 
 free
 functions with those names, and it's more likely that they'll have
 variables
 with those names, which are less likely to conflict.

 So, while I don't really like the idea of adding the aliases, they 
 _might_
 be
 added, because they probably won't break anything, and they enable 
 UFCS.
 But
 there's not a good enough reason to change dur to duration at this 
 point.


 They eliminate the *entire* reason for it ever even being "dur" in the 
 first
 place.


 No, they don't. You have to keep dur if you want to enable generic code.


Sorry, I meant "...the reason for it being named 'dur' instead of 
'duration'."


...and honestly, I think that it's _worse_ for the very reasons
 that I chose dur in the first place. dur!"hours" is pretty much just as 
 clear
 as duration!"hours", and it's shorter.


Well, I gotta say, I'm with Adam on this one: I think "duration" is much 
more clear, much easier to learn, and much easier to remember than "dur". 
Granted, I'm all for abbreviations when they're common enough, such as 
"curr" or "ident", but "dur" is just waaaay out there (And do we really need 
to invite "D: The 'Durrr' Language" heckling?).

That leaves "shorter" the only remaining reason, which becomes insignificant 
with the aliases, since the full "dur/duration" would be only rarely needed 
and the aliases are much shorter than even "dur".



 Mar 10 2012



  parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday, March 10, 2012 05:31:31 Nick Sabalausky wrote:

 Well, I gotta say, I'm with Adam on this one: I think "duration" is much
 more clear, much easier to learn, and much easier to remember than "dur".
 Granted, I'm all for abbreviations when they're common enough, such as
 "curr" or "ident", but "dur" is just waaaay out there (And do we really need
 to invite "D: The 'Durrr' Language" heckling?).
 
 That leaves "shorter" the only remaining reason, which becomes insignificant
 with the aliases, since the full "dur/duration" would be only rarely needed
 and the aliases are much shorter than even "dur".


Regardless of whether dur or duration is better, it's not worth the code 
breakage to change it.

- Jonathan M davis



 Mar 10 2012



prev sibling next sibling parent  Brad Anderson <eco gnuk.net>  writes:


On Fri, Mar 9, 2012 at 4:24 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Friday, March 09, 2012 16:08:34 Brad Anderson wrote:

 On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg gmx.com
wrote:

 On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:

 I'll say I *don't* agree with the rejection of aliases on principle






 --

 aliases can be extremely useful/helpful, and they cost literally






 nothing

 (the "cognitive cost" on the docs is a BS argument IMO). I just don't
 agree with consuming so many common symbols for the sake of sugar.


 aliases need to have a really good argument for existing. If UFCS is




 fully

 implemented, then I think that there is _some_ argument for having




 stuff

 like
 hours and minutes, because then you can do stuff like 5.seconds()




 (though

 honestly, I really don't like the idea). The alias enables different
 usages
 rather than simply being another name for the same thing.


 What remains on UFCS? I've heard someone (Nick?) say he'd like it to


 match

 static member functions too. I haven't tested but it seems like
 5.seconds() should work ever since Kenji's pull request was merged a


 couple

 of days ago (thanks Kenji and Walter, I'm really looking forward to that
 change).


 I don't know what the current state of UFCS is. I know that Kenji has been
 working on it and that at least some portion of it has been checked in, but
 what exactly it enables at this point, I don't know.

 - Jonathan M Davis


Here are the unittests he added if you are curious about what currently
works in dmd HEAD:
https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/ufcs.d

The issue "[tdpl] Implement uniform function call syntax" <
http://d.puremagic.com/issues/show_bug.cgi?id=3382> is marked as RESOLVED
FIXED so, as far as I know, UFCS is done (ignoring the inevitable bugs that
will eventually be uncovered).

Regards,
Brad Anderson



 Mar 09 2012



prev sibling  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Mar 09, 2012 at 04:30:11PM -0700, Brad Anderson wrote:

 On Fri, Mar 9, 2012 at 4:24 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


[...]

 I don't know what the current state of UFCS is. I know that Kenji
 has been working on it and that at least some portion of it has been
 checked in, but what exactly it enables at this point, I don't know.




[...]

 Here are the unittests he added if you are curious about what
 currently works in dmd HEAD:
 https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/ufcs.d


Wow, 2.5.twice==5.0 works now? So does 2.5.sqrt()! And pseudo-members
for structs!  And classes!  Amazing!  Kudos to Kenji!


T

-- 
Question authority. Don't ask why, just do it.



 Mar 09 2012