March 08, 2012
"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


March 08, 2012
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
March 08, 2012
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

-- 
Любишь кататься - люби и саночки возить.
March 08, 2012
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
March 08, 2012
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.
March 08, 2012
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
March 08, 2012
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
March 08, 2012
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
March 08, 2012
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.
March 08, 2012
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