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
next sibling parent 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
prev 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 next sibling 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
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 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 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 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 next 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 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 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 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 parent "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
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 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
prev sibling 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
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 =?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
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!

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 "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
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 the ones pointed out are *not* done well) are much better than Java/C#-style overlySpelledOutNames.
 But "dur"? "curr"?

The "dur" is probably bad (now that you mention it), but I'm very much in favor of "curr". It's a very common need to have some "currentWhatever" (so it makes sence to make it less verbose), and the abbreviation "curr" is very common (so there's no problem with using that abbreviation). I use "curr" all the time.
Mar 06 2012
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 "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
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 "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 next sibling 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 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 "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 "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 next 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 "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 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.

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

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

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

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
prev sibling next 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.

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

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.

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

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

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

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
prev sibling next 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 "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
prev sibling 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
next sibling 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 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 next sibling parent 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=


 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=

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

 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
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 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
next sibling parent "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
prev sibling parent 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
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 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 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 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 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
prev sibling next sibling parent 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
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 "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
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 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 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 next 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 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 next sibling 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 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 "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 "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
prev sibling next 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 "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:
--bcaec554d59461e85204ba9bd874
Content-Type: text/plain; charset=ISO-8859-1

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). --bcaec554d59461e85204ba9bd874 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 6, 2012 at 4:53 PM, H. S. Teoh <span dir=3D"ltr">&lt;<a href=3D= "mailto:hsteoh quickfur.ath.cx">hsteoh quickfur.ath.cx</a>&gt;</span> wrote= :<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Tue, Mar 06, 2012 at 06:43:39PM -0500, Jonathan M Davi= s wrote:<br> &gt; On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:<br> &gt; &gt; writeln(time.toISOExtendedString()); // bzzt, wrong, but this<br> &gt; &gt; used to work!<br> &gt;<br> &gt; Yes, and it was quickly changed to toISOExtString, because<br> &gt; toISOExtendedString is painfully long. toISOExtString is bad enough,<b= r> &gt; but you can&#39;t really make it any shorter without making the name<b= r> &gt; uninformative.<br> <br> </div>You *could* shorten String to Str, but that would be inconsistent wit= h<br> everything else (e.g. toString), so that&#39;s a no-go.<br> <div class=3D"im"><br> <br> &gt; &gt; Nope, apparently, I meant &quot;dur&quot;. Ridiculous.<br> &gt;<br> &gt; A Duration needs to be constructed with a template, and<br> &gt; duration!&quot;hours&quot;(13), duration!&quot;seconds&quot;(44), etc.= is painfully long<br> &gt; when used in expressions. So, it was shortened to dur. I don&#39;t kno= w of<br> &gt; any other abbreviation which would make sense.<br> </div>[...]<br> <br> I&#39;m on the fence about this one. It&#39;s true that duration!&quot;seco= nds&quot;(44)<br> is uncomfortably long, but &#39;dur&#39; also tends towards the side of<br> meaningless, esp. if it occurs only once or twice in otherwise-unrelated<br=

think of any<br> good abbreviations for it either.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> T<br> <br> --<br> A bend in the road is not the end of the road unless you fail to make<br> the turn. -- Brian White<br> </font></span></blockquote></div><br><div>I wasn&#39;t around for the creat= ion of datetime but I&#39;m curious why a boost datetime-like duration cons= truction shortcut approach to durations wasn&#39;t used. =A0That is, you ca= n write weeks(1), months(6), years(10), hours(17), minutes(12), etc. (altho= ugh there is now days(int) for some reason).</div> --bcaec554d59461e85204ba9bd874--
Mar 06 2012
prev sibling next sibling parent "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
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 "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
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 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.

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

 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 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
prev sibling 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 next sibling parent 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
prev sibling parent 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
 it should take notices of other rising languages like C#.

 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
prev sibling 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 
rising languages like C#.

The problem with making any change to Phobos is backwards 
compatibility. So, what if there was a way to satisfy both 
parties and keep backwards compatibility? Is there any compelling 
reason why simply wrapping Phobos into a different format would 
be such bad thing? Meaning:

     // system.io

     private import std.stdio;

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

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

good idea ! can refer to the java c # naming specification, to work out d own naming specification good luck Bill
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
 rising languages like C#.

 The problem with making any change to Phobos is backwards
 compatibility. So, what if there was a way to satisfy both
 parties and keep backwards compatibility? Is there any compelling
 reason why simply wrapping Phobos into a different format would
 be such bad thing? Meaning:

       // system.io

       private import std.stdio;

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

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

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

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 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling 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 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 next sibling parent "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
prev sibling next 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 "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.

Again, it's a matter of learning the library. Try going from Java to C#, 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 "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
prev sibling next sibling parent "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=



 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=

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
prev sibling 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 next sibling parent "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
prev sibling 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 "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
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 next sibling 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 next sibling parent "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
prev sibling 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
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 next sibling parent "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
prev sibling next sibling 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 The Java/C# naming conventions themselves are wonderfully consistent and easy to remember/type (especially in an IDE like Eclipse that knows to match "MWC" to the "MyWonderfulClass"). I honestly believe that people who use horrible C/Unix like conventions should not be allowed to touch a keyboard. At my previous work I had the "pleasure" to use legacy code in C and Fortran. One time I needed to figure out how to do something and was pointed to an ancient function who's name was an undecipherable 5 letter abbreviation, probably written by someone who retired long ago. luckily it had comments, *but* the comments themselves were also fucking abbreviated! This is truly the most evil way to torture future junior programmers who will be unfortunate enough to inherit your code. So no, abbreviations are *NOT* acceptable. Haven't we suffered enough?
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 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 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 next sibling 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 "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
prev sibling next sibling 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
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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
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!

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
parent 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!

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
prev sibling next sibling parent "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
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 next sibling parent "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
prev sibling next sibling 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.


 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.

https://github.com/D-Programming-Language/dmd/pull/739
Mar 07 2012
prev sibling next sibling parent 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
prev sibling 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 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 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 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
prev sibling next sibling 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 next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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=



 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=

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

 sceptical).

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


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

 "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 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 "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
prev sibling 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 next sibling 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 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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
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 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
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 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

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

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

=> 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 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 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling 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 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 "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
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 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 next sibling parent 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
prev sibling next sibling parent "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=

 Russian. Or Swahili (which is an awesome-sounding language). Designing=

 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 :) =

 be both fun to make and to use.

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 "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
prev sibling next 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 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 "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
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 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
prev sibling next sibling 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 next sibling 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=




 abbreviation for current.

Is it your *first* choice?

In the general case, it frequently is for me. In the specific case =


 Clock.curr(ent)?Time, I'm equally happy either way. Although I agre=


 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 =

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


 more comfortable writing with a high level of abbreviation, which t=


 justify rather well. Still, if D's goal is to gain popularity, I th=


 it should take notices of other rising languages like C#.
=20
 The problem with making any change to Phobos is backwards compatibi=


=20
 We just need a politic for the change. IE: make the old name a warnin=

 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 next sibling parent 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.

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



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

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


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


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


 we might find seems likely to be rejected as well.

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

 ? 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
prev sibling next sibling parent 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=





 step forward.

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




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

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



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



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



 we might find seems likely to be rejected as well.

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


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

Because it creates needless aliases. Now you have to remember _both_ =

 them, because they're both going to be used in code. And people readi=

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

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

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

 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=

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

 the time units argument to the templates that use them is basically t=

 same thing. So, we're not going to add such aliases. It's not like it=

 that hard to learn the library, and none of the names are horribly wr=

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

 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
prev sibling next sibling parent 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=






 step forward.

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





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

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




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




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




 we might find seems likely to be rejected as well.

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



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

Because it creates needless aliases. Now you have to remember _both=


 them, because they're both going to be used in code. And people rea=


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


 the library and reduces its cohesiveness and consistency. It works =


 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=


 thing?
=20
 Walter and Andrei are very much against having aliases in the libra=


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


 the time units argument to the templates that use them is basically=


 same thing. So, we're not going to add such aliases. It's not like =


 all that hard to learn the library, and none of the names are horri=


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


 to learn the names of the symbols of _any_ library that you use. Th=


 no different.
=20
 - Jonathan M Davis

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
prev sibling next sibling 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 "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 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 Brad Anderson <eco gnuk.net> writes:
--485b390f79ea6f178304bad25769
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=



 more comfortable writing with a high level of abbreviation, which the=



 justify rather well. Still, if D's goal is to gain popularity, I thin=



 it should take notices of other rising languages like C#.

 The problem with making any change to Phobos is backwards


 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 --485b390f79ea6f178304bad25769 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 9, 2012 at 1:46 AM, Jonathan M Davis <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;</span> wrote= :<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Friday, March 09, 2012 09:33:20 = deadalnix wrote:<br> &gt; Le 07/03/2012 02:00, F i L a =E9crit :<br> &gt; &gt; I personally find it much easier to remember and use longer, more= <br> &gt; &gt; sentance-like method names. However, Jonathan and others obviousl= y feel<br> &gt; &gt; more comfortable writing with a high level of abbreviation, which= they<br> &gt; &gt; justify rather well. Still, if D&#39;s goal is to gain popularity= , I think<br> &gt; &gt; it should take notices of other rising languages like C#.<br> &gt; &gt;<br> &gt; &gt; The problem with making any change to Phobos is backwards compati= bility.<br> &gt;<br> &gt; We just need a politic for the change. IE: make the old name a warning= ,<br> &gt; then deprecated, then remove it. Spread the process to a year or so.<b= r> <br> </div></div>We&#39;re not changing symbol names without a good reason. Yes,= there&#39;s a<br> deprecation process that allows us to change them if we need to, but it&#39= ;s<br> still disruptive.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> - Jonathan M Davis<br> </font></span></blockquote></div><br><div>The &quot;secs&quot; and &quot;se= conds&quot; inconsistency is something I&#39;ve seen people in IRC hit and = complain about on several occasions. =A0The dur!&quot;seconds&quot;(1) synt= ax I&#39;ve seen complained about or confusion over on both IRC and on redd= it by active and potential users. =A0While I don&#39;t feel particularly st= rong about these issues I feel I should point out that actual users are hit= ting them and the issues bug them enough that they feel the need to complai= n=A0publicly. =A0Changes must be made with care but the former issue on inc= onsistency, I would argue, is a bigger issue than, say, the current symbol = deprecation/replace of=A0toISOExtendedString (though I don&#39;t know the h= istory of the decision to make the change).</div> <div><br></div><div>There shouldn&#39;t be two ways of expressing the exact= same thing so the &quot;secs&quot;/&quot;seconds&quot; should be a substit= ute and deprecate process rather than just a simple alias if it were made. = It looks like it&#39;s been rejected already, though, which is unfortunate.= =A0phobos 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 disrup= tion to current users.<br> </div><div><br></div><div>The dur aliases would be welcome because they inc= rease readability, intuitive design, and brevity. =A0I know I just said the= ir shouldn&#39;t be two ways of doing the same thing but I don&#39;t feel t= his is the case here. =A0It&#39;s a shortcut to doing exactly one thing and= , as I said before, I wouldn&#39;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 f= airly frequently in my line of work).</div> <div><br></div><div>Anyway, I just felt I&#39;d share my opinion and what I= &#39;ve witnessed of other users so it&#39;s at least it&#39;s heard and ta= ken into consideration. The decision is ultimately yours and Walter&#39;s.<= /div> <div><br></div><div>Regards,</div><div>Brad Anderson</div> --485b390f79ea6f178304bad25769--
Mar 09 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
 it should take notices of other rising languages like C#.
 
 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 "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

=> 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
prev sibling next sibling parent "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
prev sibling 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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  


 Seconds, hours, etc *are* durations. What the hell do we even need  


 "dur" or "duration" for anyway?

 I say fuck it: Let's just toss this into core.time (or std.datetime  


 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  


 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

 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
prev sibling next sibling 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 "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
prev sibling 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 "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 next sibling parent Brad Anderson <eco gnuk.net> writes:
--e89a8f22c535cb178a04bad7789e
Content-Type: text/plain; charset=ISO-8859-1

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.

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

--e89a8f22c535cb178a04bad7789e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;</span> wrote= :<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, March 09, 2012 17:41:01 Steven Schveighoffer w= rote:<br> &gt; I&#39;ll say I *don&#39;t* agree with the rejection of aliases on prin= ciple --<br> &gt; aliases can be extremely useful/helpful, and they cost literally nothi= ng<br> &gt; (the &quot;cognitive cost&quot; on the docs is a BS argument IMO). I j= ust don&#39;t<br> &gt; agree with consuming so many common symbols for the sake of sugar.<br> <br> </div>aliases need to have a really good argument for existing. If UFCS is = fully<br> implemented, then I think that there is _some_ argument for having stuff li= ke<br> hours and minutes, because then you can do stuff like 5.seconds() (though<b= r> honestly, I really don&#39;t like the idea). The alias enables different us= ages<br> rather than simply being another name for the same thing.<br> <br></blockquote><div><br></div><div>What remains on UFCS? I&#39;ve heard s= omeone (Nick?) say he&#39;d like it to match static member functions too. = =A0I haven&#39;t tested but it seems like 5.seconds() should work ever sinc= e Kenji&#39;s pull request was merged a couple of days ago (thanks Kenji an= d Walter, I&#39;m really looking forward to that change).=A0</div> <div><br></div><div>Regards,</div><div>Brad Anderson</div><div>=A0</div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"> Now, in this particular case, it&#39;s that much worse for exactly the reas= on that<br> you&#39;re against it: it uses common names for free functions. It&#39;s no= t as big a<br> problem as it would be in C or C++, but it&#39;s still a problem. There&#39= ;s also<br> some risk that it will break code.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> - Jonathan M Davis<br> </font></span></blockquote></div><div><br></div> --e89a8f22c535cb178a04bad7789e--
Mar 09 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--e89a8f22c535be379604bad79632
Content-Type: text/plain; charset=ISO-8859-1

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.

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

--e89a8f22c535be379604bad79632 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;</span> wrote= :<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, March 09, 2012 17:41:01 Steven Schveighoffer w= rote:<br> &gt; I&#39;ll say I *don&#39;t* agree with the rejection of aliases on prin= ciple --<br> &gt; aliases can be extremely useful/helpful, and they cost literally nothi= ng<br> &gt; (the &quot;cognitive cost&quot; on the docs is a BS argument IMO). I j= ust don&#39;t<br> &gt; agree with consuming so many common symbols for the sake of sugar.<br> <br> </div>aliases need to have a really good argument for existing. If UFCS is = fully<br> implemented, then I think that there is _some_ argument for having stuff li= ke<br> hours and minutes, because then you can do stuff like 5.seconds() (though<b= r> honestly, I really don&#39;t like the idea). The alias enables different us= ages<br> rather than simply being another name for the same thing.<br> <br> Now, in this particular case, it&#39;s that much worse for exactly the reas= on that<br> you&#39;re against it: it uses common names for free functions. It&#39;s no= t as big a<br> problem as it would be in C or C++, but it&#39;s still a problem. There&#39= ;s also<br> some risk that it will break code.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo= te><div><br></div><div>Oh, and I&#39;d just like to add some of my experien= ce to this. These names are used by Boost&#39;s datetime library and they&#= 39;ve never been a problem for me and at work we make extensive use of Boos= t datetime. =A0There is risk but I think in this specific case they are fai= rly small (especially in D, over C++). =A0We switched to Boost datetime aft= er we had hundreds of thousands of lines of code written using a different = system and I didn&#39;t encounter any problems with the duration shortcut f= unctions clashing.</div> <div><br></div><div>Anyway, it sounds like Walter is probably opposed from = what he was saying in the other thread so this conversation is probably moo= t.</div><div><br></div><div>Regards,</div><div>Brad Anderson=A0</div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEnZb"><font color= =3D"#888888"> - Jonathan M Davis<br> </font></span></blockquote></div><br> --e89a8f22c535be379604bad79632--
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 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
prev sibling next 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 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 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 "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 "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 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 next sibling parent 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
prev sibling 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
next 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
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
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
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 "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 "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 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 "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 "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 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 "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 "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
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--485b390f7b4a24fe9c04bad7c605
Content-Type: text/plain; charset=ISO-8859-1

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



 (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


 implemented, then I think that there is _some_ argument for having


 like
 hours and minutes, because then you can do stuff like 5.seconds()


 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

 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

 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 --485b390f7b4a24fe9c04bad7c605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 9, 2012 at 4:24 PM, Jonathan M Davis <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;</span> wrote= :<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, March 09, 2012 16:08:34 Brad Anderson wrote:<b= r> &gt; On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis &lt;<a href=3D"mailto= :jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;wrote:<br> &gt; &gt; On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:<br=

es on principle --<br> &gt; &gt; &gt; aliases can be extremely useful/helpful, and they cost liter= ally nothing<br> &gt; &gt; &gt; (the &quot;cognitive cost&quot; on the docs is a BS argument= IMO). I just don&#39;t<br> &gt; &gt; &gt; agree with consuming so many common symbols for the sake of = sugar.<br> &gt; &gt;<br> &gt; &gt; aliases need to have a really good argument for existing. If UFCS= is fully<br> &gt; &gt; implemented, then I think that there is _some_ argument for havin= g stuff<br> &gt; &gt; like<br> &gt; &gt; hours and minutes, because then you can do stuff like 5.seconds()= (though<br> &gt; &gt; honestly, I really don&#39;t like the idea). The alias enables di= fferent<br> &gt; &gt; usages<br> &gt; &gt; rather than simply being another name for the same thing.<br> &gt;<br> &gt; What remains on UFCS? I&#39;ve heard someone (Nick?) say he&#39;d like= it to match<br> &gt; static member functions too. I haven&#39;t tested but it seems like<br=

a couple<br> &gt; of days ago (thanks Kenji and Walter, I&#39;m really looking forward t= o that<br> &gt; change).<br> <br> </div>I don&#39;t know what the current state of UFCS is. I know that Kenji= has been<br> working on it and that at least some portion of it has been checked in, but= <br> what exactly it enables at this point, I don&#39;t know.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> - Jonathan M Davis<br> </font></span></blockquote></div><br><div>Here are the unittests he added i= f you are curious about what currently works in dmd HEAD:=A0<a href=3D"http= s://github.com/D-Programming-Language/dmd/blob/master/test/runnable/ufcs.d"=
https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/uf=

<div><br></div><div>The issue &quot;[tdpl] Implement uniform function call = syntax&quot; &lt;<a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id= =3D3382">http://d.puremagic.com/issues/show_bug.cgi?id=3D3382</a>&gt; is ma= rked as RESOLVED FIXED so, as far as I know, UFCS is done (ignoring the ine= vitable bugs that will eventually be uncovered).</div> <div><br></div><div>Regards,</div><div>Brad Anderson</div> --485b390f7b4a24fe9c04bad7c605--
Mar 09 2012
prev sibling next sibling parent "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  

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

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
prev sibling 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:
--485b390f7b4ad73a9d04bad8080b
Content-Type: text/plain; charset=ISO-8859-1

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

 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.

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

--485b390f7b4ad73a9d04bad8080b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 9, 2012 at 4:45 PM, Jonathan M Davis <span dir=3D"ltr">&lt;<a h= ref=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt;</span> wrote= :<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, March 09, 2012 18:39:25 Steven Schveighoffer w= rote:<br> &gt; I want to stress again the difference between C++&#39;s namespaces, an= d D&#39;s<br> &gt; module import mechanism. In C++, you *deliberately* pull a namespace i= nto<br> &gt; your scope (and usually only in the implementation file, which doesn&#= 39;t<br> &gt; affect any other implementation files), whereas in D, a standard &quot= ;import<br> &gt; std.datetime&quot; *automatically* pulls its namespace into your scope= , and any<br> &gt; public imports it has made.<br> <br> </div>Yeah. D has great tools for getting around conflicts, but things tend= to<br> conflict by default, which means that it&#39;s very easy to break code by<b= r> introducing conflicts when adding functions.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo= te><div><br></div><div>Hmm, fair enough. =A0In our case they were essential= ly pulled into the global namespace due to some questionable decisions with= regard to namespaces made in our project. =A0The difference between D and = C++ is important to point out though so thanks for clarifying.</div> <div><br></div><div>Regards,</div><div>Brad Anderson</div><div>=A0</div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"><span class=3D"HOEnZb"><font color=3D"#888888"> - Jonathan M Davis<br> </font></span></blockquote></div><br> --485b390f7b4ad73a9d04bad8080b--
Mar 09 2012
prev sibling next 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
prev sibling next sibling parent "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
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
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.

This is why C# requires that you declare a function to be UFCS in order to 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling 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 "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=


 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=


 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=

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

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

 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=

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

 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
prev sibling next sibling parent "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
prev sibling 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 next sibling 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 "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
prev sibling 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 "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
prev sibling next sibling 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 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 "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 "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 "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling 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
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
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 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 "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
parent "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
prev sibling next sibling parent "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
prev sibling next 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 "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".

It was WorldWideWeb actually. Later renamed to Nexus as the original name was deemed confusing. Stewart.
Mar 11 2012
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next 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 next sibling 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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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
next 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 "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
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
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 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 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 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 "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
prev sibling next sibling parent "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
prev sibling 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 "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
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
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 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 =

 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 "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
prev sibling next sibling 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 "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 handle #1 above, *fast* animations. 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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=


 to shame *on reddit*, for god's sake! And how many man-hours of effort d=


 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=

 button, and have the comment turn into a text block, and say something li=

 "Comment saved!". From a UI perspective, it's the most reasonable thing t=

 do: you leave a comment, it becomes a definitive comment on the blog, tha=

 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=

 only the comment contents were transfered between the client and the serv=

 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 =

 the comment just created? Or should I implement an intermediate page sayi=

 "here's your newly created comment, now go back to the post"). Second, th=

 whole page is transferred again! I can't see how in the world that is fas=

 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=

 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=

 transferred.

 Again, I don't understand how that is slower than transferring whole page=

 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
prev sibling next 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
 handle #1 above, *fast* animations.

 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 next 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 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 next sibling parent "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
prev sibling 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 "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 "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 "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