[#5218] Ruby Book Eng tl, ch1 question — Jon Babcock <jon@...>

13 messages 2000/10/02

[#5404] Object.foo, setters and so on — "Hal E. Fulton" <hal9000@...>

OK, here is what I think I know.

14 messages 2000/10/11

[#5425] Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...>

18 messages 2000/10/11
[#5427] RE: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — OZAWA -Crouton- Sakuro <crouton@...> 2000/10/11

At Thu, 12 Oct 2000 03:49:46 +0900,

[#5429] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...> 2000/10/11

Thanks for the input.

[#5432] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Yasushi Shoji <yashi@...> 2000/10/11

At Thu, 12 Oct 2000 04:53:41 +0900,

[#5516] Re: Some newbye question — ts <decoux@...>

>>>>> "D" == Davide Marchignoli <marchign@di.unipi.it> writes:

80 messages 2000/10/13
[#5531] Re: Some newbye question — matz@... (Yukihiro Matsumoto) 2000/10/14

Hi,

[#5544] Re: Some newbye question — Davide Marchignoli <marchign@...> 2000/10/15

On Sat, 14 Oct 2000, Yukihiro Matsumoto wrote:

[#5576] Re: local variables (nested, in-block, parameters, etc.) — Dave Thomas <Dave@...> 2000/10/16

matz@zetabits.com (Yukihiro Matsumoto) writes:

[#5617] Re: local variables (nested, in-block, parameters, etc.) — "Brian F. Feldman" <green@...> 2000/10/16

Dave Thomas <Dave@thomases.com> wrote:

[#5705] Dynamic languages, SWOT ? — Hugh Sasse Staff Elec Eng <hgs@...>

There has been discussion on this list/group from time to time about

16 messages 2000/10/20
[#5712] Re: Dynamic languages, SWOT ? — Charles Hixson <charleshixsn@...> 2000/10/20

Hugh Sasse Staff Elec Eng wrote:

[#5882] [RFC] Towards a new synchronisation primitive — hipster <hipster@...4all.nl>

Hello fellow rubyists,

21 messages 2000/10/26

[ruby-talk:5571] Re: Regexp#matches

From: "Conrad Schneiker/Austin/Contr/IBM" <schneik@...>
Date: 2000-10-16 07:01:53 UTC
List: ruby-talk #5571
Dave Thomas wrote:

# "Everett L.(Rett) Williams" <rett@gvtc.com> writes:
# 
# > matz,
# > 
# > > > Well, I personally use plain form of nouns for method names, for
# > > >example `exist?' not 'exists?'.  The standard names reflect this
# > > >policy.  Reason?  a) my tongue Japanese does not have this syntax
# > > >(third person, singular); b) Ruby is not English.  You are free to
# > > >define this by yourself, and I think it's possible that the
# > > >standard library 'English' may provide these aliases.
# > 
# > I occasionally read this list, but this is the first time that I
# > have felt compelled to answer.
# 
# Flame bait, folks, ignore it.

Now, now. This could just be an innocent case of someone being both 
tragically mistaken and unusually tactless. (But to anticipate your next 
question, I concede in advance that I am not willing to place any bets 
about this.)

However, I can't resist pointing out some important factors in defense of 
Matz's policy. 

Although English is the most widely spoken language in the world, (1) it 
is not the most widely spoken first language, (2) nor is it gramatically 
all that well understood by a great many of those who do speak it. (In 
effect, there are many quasi-dialects of English.) (3) Until someone knows 
a programming language thoroughly, it is not clear which things are 
synonymous versus which are actually different but similarly named. (4) As 
Ruby spreads, we may anticipate that many people who know neither English 
or Japanese will take up Ruby, where the proliferation of synonymous terms 
constitutes a needless additional learning difficulty. (5) The average 
programmer is, well, average, and it is both inconsiderate and 
uneconomical to needlessly raise the cognitive bandwidth needed to 
effectively use great power tools. (6) Supporting too many ways of 
expressing the same thing tends to hamper mutual understanding and the 
maintainability of handed-off programs if everyone does not assiduously 
and consistently chose and use the most English-like grammar options. This 
is sort of like people becoming adapted to a given C brace convention 
(except much worse), where reading and fixing programs written in a 
different convention gives the very annoying general impression that they 
are pervasively incorrect--i.e. this produces lots of intuitive false 
alarms--and even drives some people to Python.  :-) 

Taken individually, these are each moderately strong factors in favor of 
Matz's policy--however, taken together, they *overwhelmingly* favor Matz's 
policy. 

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)

In This Thread

Prev Next