"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:jjbbrn$2o1n$1@digitalmars.com...
> On 08/03/2012 19:29, H. S. Teoh wrote:
> <snip>
>> Another thing is, I can't roll my R's. My tongue as stiff as a stick and just refuses to roll anything, no matter how hard I try.
> <snip>
>
> I can't roll my tongue either.  I'm told it's genetic. :)
>

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

Anyway, I just always thought that was weird.

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

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

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.270.1331248862.4860.digitalmars-d@puremagic.com...
> On Thu, Mar 08, 2012 at 10:29:05PM +0000, Stewart Gordon wrote:
>> On 08/03/2012 19:29, H. S. Teoh wrote:
>> <snip>
>> >Another thing is, I can't roll my R's. My tongue as stiff as a stick and just refuses to roll anything, no matter how hard I try.
>> <snip>
>>
>> I can't roll my tongue either.  I'm told it's genetic. :)
>>
>> But anyway, to me, rolling Rs seems pretentious....
> [...]
>
> Well, it's pretentious in English, but quite mellifluous in Russian. :-) Though I'm told that even for native Russian speakers, it's one of the last sounds acquired, so it must be pretty difficult. (And to make things worse, they have *two* rolled R's, one palatized, one not. As if one R isn't hard enough already.)
>

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

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

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

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

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

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.

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

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

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