hello,
i just started with ruby. i've been off the front-lines of programming for about 15 years. recently, our company was purchased by a died-in-the-wool java shop that is just starting to adopt ruby and rails. i've always had at least a working knowledge of our programming environment, so i started investigating ruby. truth be told, i've never before worked in an object oriented environment. so, when i, just moments ago, executed a small program which demonstrates how easily even methods in an internal (ships-with-ruby) class can be redefined, i experienced a holy s#@! moment. well, possibly unrelated to topics dealing with an amazing object model, i have my first (of what may be many) really dumb questions: why is it advantageous to be able to distinguish aVariableName from avariablename?
thanks,
doug
Are you asking why identifiers are case-sensitive?
-Jeremy
···
On 12/2/2010 11:07 AM, Doug Stone wrote:
hello,
i have my first (of what may be many) really dumb questions: why is it advantageous to be able to distinguish aVariableName from avariablename?
<snip>
advantageous to be able to distinguish aVariableName from avariablename?
thanks,
doug
I would not say it is advantageous. Maybe one could argue about
a_variable_name vs. AVariableName (bad example for camel case I guess)
It is a matter of taste, ... [computer! erase the last sentence!]
It is a matter of style and convention, Ruby has chosen the former
style and about everybody I know sticks to it. Note that camel case is
used for constants and that helps us to distinguish those two;)
thus in Ruby it is my_variable and MyConst. in Java it would be
MyVariable and MYCONST
I believe the Ruby style is more readable but that might be because I
read almost infinitely more ruby code than Java code :P.
Cheers
Robert
···
On Thu, Dec 2, 2010 at 6:07 PM, Doug Stone <dstone@concerro.com> wrote:
--
The 1,000,000th fibonacci number contains '42' 2039 times; that is
almost 30 occurrences more than expected (208988 digits).
N.B. The 42nd fibonacci number does not contain '1000000' that is
almost the expected 3.0e-06 times.
So you basically ask why Ruby's identifiers are case sensitive. It's that way in many (most?) programming languages. I suspect that what to us humans looks like simple (identifying both variants as the same variable) is more difficult for computers: case handling is highly dependent on the encoding used and may actually be difficult to compute. For a machine it is easier to just test for binary identity.
Good news is: you can actually get used to this. 
Kind regards
robert
···
On 12/02/2010 06:07 PM, Doug Stone wrote:
why is it advantageous to be able to distinguish aVariableName from avariablename?
Yes, thanks: I was asking why, when designing a language, why make identifiers case sensitive. One list member responded that there would be an extra overhead involved in equating, say, aVariableName with avariablename. Overhead considerations aside, I think it would be desirable to have identifiers be case-insensitive... ?
···
-----Original Message-----
From: Jeremy Bopp [mailto:jeremy@bopp.net]
Sent: Thursday, December 02, 2010 9:24 AM
To: ruby-talk ML
Subject: Re: newbie: variable names
On 12/2/2010 11:07 AM, Doug Stone wrote:
hello,
i have my first (of what may be many) really dumb questions: why is it advantageous to be able to distinguish aVariableName from avariablename?
Are you asking why identifiers are case-sensitive?
-Jeremy
Robert Klemme wrote:
···
On 12/02/2010 06:07 PM, Doug Stone wrote:
why is it advantageous to be able to distinguish aVariableName from avariablename?
So you basically ask why Ruby's identifiers are case sensitive. It's
that way in many (most?) programming languages. I suspect that what to
us humans looks like simple (identifying both variants as the same
variable) is more difficult for computers: case handling is highly
dependent on the encoding used and may actually be difficult to compute.
It's actually impossible. My favorite example:
def maße; end
def masse; end
MASSE # Oops. Which one do I mean?
jwm
As an extremely visually oriented person, I think I would incur a mental
overhad as well if you could talk about the same variable/method in
different places, but have the method name look different in each of them.
Interestingly, in JRuby, when dealing with Java libs, you can call methods
with either snake_case, or camelCase, and both will work just fine.
···
On Thu, Dec 2, 2010 at 2:29 PM, Doug Stone <dstone@concerro.com> wrote:
Yes, thanks: I was asking why, when designing a language, why make
identifiers case sensitive. One list member responded that there would be
an extra overhead involved in equating, say, aVariableName with
avariablename. Overhead considerations aside, I think it would be desirable
to have identifiers be case-insensitive... ?
I can't speak to the reasoning behind the design decision, but I see
potential problems with either methodology.
When using case-sensitive identifiers, you can make your program
confusing by purposely using capitalization differences between
identifiers in order to hold different values or carry out different
functions. In a scripting language such as Ruby, a simple typoed
identifier could cause hard to find bugs, especially if the typo was a
minor capitalization difference. It would definitely be worse if the
convention for most identifiers was camel case as that could easily hide
incorrect caps. Fortunately, I have never seen this to be a common
issue even within some outrageously bad code I've inherited over the years.
OTOH, one could get pretty sloppy with identifier names, perhaps
unintentionally, if capitalization is ignored and thereby make a program
a challenge for a human to read later. Maybe that wouldn't be a
frequent problem either though.
What would be the biggest advantage of allowing case-insensitivity in
your opinion?
-Jeremy
···
On 12/2/2010 2:29 PM, Doug Stone wrote:
Yes, thanks: I was asking why, when designing a language, why make identifiers case sensitive. One list member responded that there would be an extra overhead involved in equating, say, aVariableName with avariablename. Overhead considerations aside, I think it would be desirable to have identifiers be case-insensitive... ?
Overhead considerations aside, I think it would
be desirable to have identifiers be case-insensitive... ?
As Robert Dober said, in Ruby, constants (Upper case) are
different beasts than variables (lower case).
An unfortunately unpasteable example:
irb(main):001:0> Hello = "I am a constant!"
=> "I am a constant!"
irb(main):002:0> hello = "I am a variable."
=> "I am a variable."
irb(main):003:0> Hello = "Indeed, I am a constant."
(irb):3: warning: already initialized constant Hello
=> "Indeed, I am a constant."
irb(main):004:0> def access_variable_example
irb(main):005:1> puts hello
irb(main):006:1> end
irb(main):007:0> access_variable_example
NameError: undefined local variable or method `hello' for main:Object
from (irb):5:in `access_variable_example'
from (irb):7
from /usr/local/bin/irb:12:in `<main>'
irb(main):008:0> def access_constant_example
irb(main):009:1> puts Hello
irb(main):010:1> end
=> nil
irb(main):011:0> access_constant_example
Indeed, I am a constant.
=> nil
It is desirable for a language to have a syntax which reflects the
semantics. Capitalization is easy to see, easy to type, and
doesn't add any extra waffle.
Also, case sensitivity gives me more choice. I can have sockets and
Sockets and SOCKETS, and have them, individually, mean whatever I want
to.
Johnny
I worked with macromedia( now adobe) lingo which was case insensitive
pre internet days. Though it was a "feature" no one used it. That
language it was more common to use hungerian notation for naming.
The token parser would have to have some extra checks and some
conversions but once turned into byte code and cached the program
should run just as fast. in c a char is still sizeof(char) and an
integer is still sizeof(int).
I would imagine the 'design decision' would have more to do with
creating something that is useful as opposed to making a feature which
though interesting would never be used in a real world application.
···
On Thu, Dec 2, 2010 at 2:29 PM, Doug Stone <dstone@concerro.com> wrote:
Yes, thanks: I was asking why, when designing a language, why make identifiers case sensitive. One list member responded that there would be an extra overhead involved in equating, say, aVariableName with avariablename. Overhead considerations aside, I think it would be desirable to have identifiers be case-insensitive... ?
-----Original Message-----
From: Jeremy Bopp [mailto:jeremy@bopp.net]
Sent: Thursday, December 02, 2010 9:24 AM
To: ruby-talk ML
Subject: Re: newbie: variable namesOn 12/2/2010 11:07 AM, Doug Stone wrote:
hello,
i have my first (of what may be many) really dumb questions: why is it advantageous to be able to distinguish aVariableName from avariablename?Are you asking why identifiers are case-sensitive?
-Jeremy
This can get even worse if you have a font with an upper case ß (these exist):
MAßE # Er...
That's also a good example why Unicode is a good thing, but can be
painful when using Unicode characters to name programming constructs.
···
2010/12/2 Jörg W Mittag <JoergWMittag+Ruby@googlemail.com>:
Robert Klemme wrote:
On 12/02/2010 06:07 PM, Doug Stone wrote:
why is it advantageous to be able to distinguish aVariableName from avariablename?
So you basically ask why Ruby's identifiers are case sensitive. It's
that way in many (most?) programming languages. I suspect that what to
us humans looks like simple (identifying both variants as the same
variable) is more difficult for computers: case handling is highly
dependent on the encoding used and may actually be difficult to compute.It's actually impossible. My favorite example:
def maße; end
def masse; endMASSE # Oops. Which one do I mean?
--
Phillip Gawlowski
Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.
What would be the biggest advantage of allowing case-insensitivity in your opinion?<
Jeremy,
After feedback from this list, I don't now see an advantage to case-insensitivity. Prior to posting, I was thinking (perhaps grounded from a "human reading level") that "aVariableName" just simply should equal "avariablename". I also thought that having a situation where case matters might actually increase the chance for error.
Doug
p.s. Since the topic here is identifiers, I do want the folks on this list to know that I realize: died_in_the_wool != dyed_in_the_wool
···
-----Original Message-----
From: Jeremy Bopp [mailto:jeremy@bopp.net]
Sent: Thursday, December 02, 2010 1:17 PM
To: ruby-talk ML
Subject: Re: newbie: variable names
On 12/2/2010 2:29 PM, Doug Stone wrote:
Yes, thanks: I was asking why, when designing a language, why make identifiers case sensitive. One list member responded that there would be an extra overhead involved in equating, say, aVariableName with avariablename. Overhead considerations aside, I think it would be desirable to have identifiers be case-insensitive... ?
I can't speak to the reasoning behind the design decision, but I see
potential problems with either methodology.
When using case-sensitive identifiers, you can make your program
confusing by purposely using capitalization differences between
identifiers in order to hold different values or carry out different
functions. In a scripting language such as Ruby, a simple typoed
identifier could cause hard to find bugs, especially if the typo was a
minor capitalization difference. It would definitely be worse if the
convention for most identifiers was camel case as that could easily hide
incorrect caps. Fortunately, I have never seen this to be a common
issue even within some outrageously bad code I've inherited over the years.
OTOH, one could get pretty sloppy with identifier names, perhaps
unintentionally, if capitalization is ignored and thereby make a program
a challenge for a human to read later. Maybe that wouldn't be a
frequent problem either though.
What would be the biggest advantage of allowing case-insensitivity in
your opinion?
-Jeremy