How much would variable declarations in Ruby make you wince?

Ruby
41

On Dec 10, 2007 5:34 PM, Just Another Victim of the Ambient M.
[email protected] wrote:

You're really not thinking this through.
How on God's green Earth are you going to accidentally prepend an

extraneous "var " (or whatever keyword is decided upon) to a variable’s
assignment. Because this is highly unlikely, the described problem will
only happen if you accidentally want to declare a new variable. This is
rather distinct from wanting to use a variable and so the bug should occur
far less frequently…

It isn’t so distinct that the error don’t happen, as I’ve done the
error in Perl. I suspect this has to do with the way either of us
write code; I write a lot of small methods, and I often combine
initialization and variable creation. So, to my mind, first
initialization of a variable is mentally equivalent to declaring the
variable - so I’ll just write “my” when I write the first
initialization. When this happens to be inside a code block (e.g,
inside an if statement), I need to expand the context of the variable,
so I’ll throw a declaration before the code block.

With Ruby, this is just an initialization - “variable = nil”. With
Perl it’s “my variable” - alas, that variable is the shadowed by the
other my declaration I wrote later in the code and earlier in time.

I had this bug just last week.

In my opinion, the noise of repeated “var ”-declarations (or
“my ” declarations) makes the code less readable, with the
corresponding increase in correctness checking being a benefit of less
worth than the cost. This is the same as my view of (other) type
declarations in most cases: Their cost in terms of being in the way of
code readability/transformability exceeds their benefits.

Eivind.

42

On Dec 10, 11:21 am, “Just Another Victim of the Ambient M.”
[email protected] wrote:

Ruby. It was an interesting request and, after I had thought about it a

hardware. Back then, you had to declare variables so that the compiler can
know to allocate them from static store when creating the executable image.
Later on, when functions became more popular, they also had to do this for
the stack. A lot of C syntax comes from how close it is to assembly
language…

Sounds reasonable.  However, I didn't mention the languages'

provenance, but that people continue to be interested in them. And
not just for static typing. People like… you, for example?

43

On 12/8/07, Just Another Victim of the Ambient M.
[email protected] wrote:
[snip]

What do you all think?

I think 47 messages (48th with mine) is A LOT. I don’t think the
subject deserves such attention. There’s already TOO MUCH NOISE in
this mailing list.

And I think I’ve got a solution for your problem. It’s a crazy idea:

what about if instead of bending a language to your preferences you
actually, you know, learn to type.

P.S. I wonder if these people are real. Sometimes I think they’re just
[Perl|Python|Java] trolls testing our patience or wasting our time on
purpose.

If you are honest, JAVotAM, get a grip: that change you’re thinking
of, won’t happen.

44

On Dec 12, 2007 4:21 AM, Roger P. [email protected] wrote:

I would have except I thought I might be bludgeoned by the community or
something. I still would use something like
def func_1(a ==> String, b ==> Fixnum)
end
if I had it. If only to ensure expected use at the beginning of coding
creation.

Try out Index of /~eivind/ruby/types/

It adds a fairly flexible syntax for doing these kinds of checks,
about as compact as the above. You can find out if they are useful to
you or not. (It also allows more appropriate type checks, like
respond_to?)

Eivind.

45

On Dec 11, 12:44 am, “Gerardo S. Gómez Garrido”
[email protected] wrote:

And I think I’ve got a solution for your problem. It’s a crazy idea:

what about if instead of bending a language to your preferences you
actually, you know, learn to type.

P.S. I wonder if these people are real. Sometimes I think they’re just
[Perl|Python|Java] trolls testing our patience or wasting our time on
purpose.

What gets me, is that so many people respond to threads like this.
While other, much more reasonable ideas get so little attention.

T.

46

On Dec 10, 10:30 am, “Just Another Victim of the Ambient M.”
[email protected] wrote:

empty promise in flow-control.

You're really not thinking this through.
How on God's green Earth are you going to accidentally prepend an

extraneous "var " (or whatever keyword is decided upon) to a variable’s
assignment. Because this is highly unlikely, the described problem will
only happen if you accidentally want to declare a new variable. This is
rather distinct from wanting to use a variable and so the bug should occur
far less frequently…

Far less frequent, given the way you do things now…but just wait
until “var” is the norm; you’ll be saying the opposite. When you’re
used to typing “var” for everything, you’ll inevitably use it in
places you don’t mean it. Then the complaint will be that ruby allows
too much control. The basic fact is that programmers are fallible,
and no matter how much “safety” is built into the language; there will
still be error between user and keyboard. I might ask how on God’s
green earth one could type “liist” instead of "list’…but it happens
anyhow, despite my incredulity.

Regards,
Jordan

47

“Gerardo S. Gómez Garrido” [email protected] wrote in
message
news:[email protected]…

On 12/8/07, Just Another Victim of the Ambient M.
[email protected] wrote:
[snip]

What do you all think?

I think 47 messages (48th with mine) is A LOT. I don’t think the
subject deserves such attention. There’s already TOO MUCH NOISE in
this mailing list.

First of all, if you don't think the subject deserves any attention,

why
pay it any?
Secondly, why do you think there’s too much “noise” in the mailing
list?
Are you not capable of threading the discussions with your mail client?
Do
you think there’s too much noise despite threading the discussions? I
can
understand if you think there’s noise but… too much noise?

And I think I’ve got a solution for your problem. It’s a crazy idea:

what about if instead of bending a language to your preferences you
actually, you know, learn to type.

That's about as helpful as responding to someone who's having

trouble
with something by saying “grow a brain.” It sounds like you’re the one
making noise, here…

P.S. I wonder if these people are real. Sometimes I think they’re just
[Perl|Python|Java] trolls testing our patience or wasting our time on
purpose.

If you check Google G., you'll see that I've been here a some

time,
now. I’m quite real and sincere…

If you are honest, JAVotAM, get a grip: that change you’re thinking
of, won’t happen.

If you read the subject line for this thread, you might get an

inkling
of how confident I am that this change will ever happen.
I thought it’s been an interesting thread. I don’t see why it has
bothered you so much. If you don’t like the subject matter, don’t read
it.
How hard is that? It seems that you’re the one who’s lost a grip…

48

On 12/11/07, Just Another Victim of the Ambient M.
[email protected] wrote:

First of all, if you don't think the subject deserves any attention, why

pay it any?

Yawn.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

49

On Dec 11, 2007 2:12 PM, Rick DeNatale [email protected] wrote:

On 12/11/07, Just Another Victim of the Ambient M.
[email protected] wrote:

First of all, if you don't think the subject deserves any attention, why

pay it any?

Yawn.

Yeah, me too. I love elitism. That’s being sarcastic for the unwary.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Todd

50

On Dec 10, 11:15 am, “Just Another Victim of the Ambient M.”
[email protected] wrote:

This is interesting but kind of overkill.  Checking for a contract is a

non-trivial, especially if you want to keep duck-typing. This would
increase programmer effort so much that it would become comparable to
programming in C, I think…

Sure, but you asked :wink:

was difficult to modify code to do something else. I don’t think
artificially keeping method definitions small necessarily solves anything…

Nah… Sure, a lot of small methods requires a little more tracking
around, but if they are named well and organized well the whole will
be much easier to work with and understand. The method names should
actually help self document the program, not obscure it. When you
divide a problem into small components it becomes much more manageable
and easier to test too.

The most annoying bug I ever have is tracking an errant “end”.

I've had this problem, before, but luckily it's quite rare for me.

Perhaps it’s because I’ve gotten into the habit of typing out my loop bounds
before filling in the loop body. I’ve always considered this a bad habit of
mine but perhaps it’s not so bad…

Of course it is fairly rare (it usually occurs during refactoring, not
first write). But when it does happen I haven’t found a better way to
track it down then to just look for it or comment out sections of
code, which sucks. Highlighting would help, but alas my editor does
not support it --even so, it wouldn’t completely solve the problem.

T.

51

On Dec 11, 8:01 am, Trans [email protected] wrote:

[Perl|Python|Java] trolls testing our patience or wasting our time on
purpose.

What gets me, is that so many people respond to threads like this.
While other, much more reasonable ideas get so little attention.

T.

Although I don’t think it is the case, if what Mr. Santana Gómez
Garrido said in his above post–which I presume he intended as a sort
of coup de grâce for the thread–is true, and the original poster is a
troll, then the real problem is that there are a bunch of us
respondents hanging around who are too stupid to know better. So you
really wouldn’t want us participating in the ‘more reasonable’
discussions, would you? The problem takes care of itself.
If you still aren’t convinced that we are a lost cause, by all means
recommend such a topic.

-J

52

“Eivind E.” [email protected] wrote in message
news:[email protected]…

It isn’t so distinct that the error don’t happen, as I’ve done the
error in Perl. I suspect this has to do with the way either of us
write code; I write a lot of small methods, and I often combine
initialization and variable creation. So, to my mind, first
initialization of a variable is mentally equivalent to declaring the
variable - so I’ll just write “my” when I write the first
initialization. When this happens to be inside a code block (e.g,
inside an if statement), I need to expand the context of the variable,
so I’ll throw a declaration before the code block.

I'm not exactly sure what you're describing, here.  Are you

describing
behaviour in PERL? Is PERL like C/C++, where variables declared in “if”
blocks (or any code blocks, for that matter!) are local to that block?
In
Ruby, variables leak right out of if and loop code blocks, so your
coding
style wouldn’t be any worse off by this change. If I haven’t been
misinformed, variables in Ruby blocks (the things that are closures) are
going to leak too, so there will be no situation where your habit will
trip
you up. Variable declarations will help prevent some bugs and will not
encourage any others (that I’ve thought of)!

declarations in most cases: Their cost in terms of being in the way of
code readability/transformability exceeds their benefits.

As I've mentioned, above, there should be no cost except that of

actually having to type it out. My guess is that declarations are far
less
common than variable use, so I don’t think you’d have to type it out all
that often, either. It will even have the strange side effect of
encouraging funcitonal programming, which is funny…

53

On Dec 10, 2007 8:50 PM, Just Another Victim of the Ambient M.
[email protected] wrote:

declarations in most cases: Their cost in terms of being in the way of
code readability/transformability exceeds their benefits.

As I've mentioned, above, there should be no cost except that of

actually having to type it out.

I think maybe we would communicate better if you read what you were
replying to?

One strength of Ruby - an important one - is that it is succinct.
There is very little extra noise compared to what is strictly
necessary to say what the program is doing. Your proposal introduce
extra noise. This noise has a cost for readability in some cases. My
opinion is that this cost is higher than the utility of the construct,
as the construct guard against an error that is easy to guard against
in other ways, other ways that are generally better, like unit
testing or string completion.

My guess is that declarations are far less common than variable use,

This depends on code style. Those that use a lot of short methods
also have more variable declarations compared to variable assignments,
in my experience.

Eivind.

54

From: “Trans” [email protected]

Highlighting would help, but alas my editor does
not support it

Whoa… just out of curiosity… what editor do you use? :slight_smile:

Regards,

Bill

55

On Dec 10, 12:16 pm, “Bill K.” [email protected] wrote:

From: “Trans” [email protected]

Highlighting would help, but alas my editor does
not support it

Whoa… just out of curiosity… what editor do you use? :slight_smile:

Oh, don’t read that the wrong way, it supports highlighting, just not
“end” highlighting.

I use Kate.

T.

56

On Mon, 10 Dec 2007 19:45:21 GMT, Just Another Victim of the Ambient
Morality wrote:

Variable declarations will help prevent some bugs and will not
encourage any others (that I’ve thought of)!

I think what he’s describing is a situation something like this:

[Horb-dee-dorb-dee-dorb, I need a new function to say hello.]

def say_hello
var first_name = “Jay”
puts “Hi, #{first_name}.”
end

[Great, that works perfectly. Two weeks later: I need to add some
initialization to that.]

def say_hello
init_screen
init_printer
init_window_system
init_text_to_speech

var first_name = "Jay"
puts "Hi, #{first_name}."

end

[Wonderful. Two weeks later: Oh, yeah, I should actually use those
outputs.]

def say_hello(destination)
var destination

if (destination == "screen")
  init_screen
if (destination == "printer")
  init_printer
if (destination == "window")
  init_window_system
if (destination == "voice")
  init_text_to_speech

var first_name = "Jay"
destination.puts "Hi, #{first_name}."

end

[Two weeks later: More cruft I don’t feel like making up a fake example
for.]

def say_hello(destination)
var destination

if (destination == "screen")
  init_screen
if (destination == "printer")
  init_printer
if (destination == "window")
  init_window_system
if (destination == "voice")
  init_text_to_speech

var first_name = "Jay"

var a = 3 * 4 + 5
Thread.join
acts_as_bad_example

destination.puts "Hi, #{first_name}."

end

[Two weeks later: Hey, why is the name even hard-coded?]

def say_hello(destination, first_name)
var destination
var first_name

if (destination == "screen")
  init_screen
if (destination == "printer")
  init_printer
if (destination == "window")
  init_window_system
if (destination == "voice")
  init_text_to_speech

var first_name = "Jay"

var a = 3 * 4 + 5
Thread.join
acts_as_bad_example

destination.puts "Hi, #{first_name}."

end

Oooooops.

And even if you remember to delete the hardcoding of “first_name”
completely, you could just as easily misspell it in the new definition.

The problem is that requiring “var” on the first use of a variable works
really well if, and only if, you write all your code in order.

57

On Dec 10, 4:13 pm, Jay L. [email protected] wrote:

def say_hello
init_window_system
var destination
var first_name = “Jay”
init_screen
Thread.join

completely, you could just as easily misspell it in the new definition.

The problem is that requiring “var” on the first use of a variable works
really well if, and only if, you write all your code in order.

–
Jay L. |
Boston, MA | My character doesn’t like it when they
Faster: jay at jay dot fm | cry or shout or hit.http://www.jay.fm | - Kristoffer

In languages that support this, isn’t it normal for the compiler to
generate an error if you declare the same variable twice at the same
scope level? So even if you do make this kind of mistake, it
announces its presence on the first pass?

58

On Mon, 10 Dec 2007 16:02:05 GMT, Just Another Victim of the Ambient
Morality wrote:

How are you testing your code?

The usual way: by running it?

That’d be the wrong way, then.

Try testing it instead! (See my previous post about TDD vs static
typing.)

59

On Mon, 10 Dec 2007 13:44:15 -0800 (PST), Dumaiu wrote:

In languages that support this, isn’t it normal for the compiler to
generate an error if you declare the same variable twice at the same
scope level? So even if you do make this kind of mistake, it
announces its presence on the first pass?

Sure, but again, if you mistyped the chronologically-second,
semantically-first var as

def say_hello(destination, first_name)
var destination
var firsst_name

Hey, no error, no overlap!

Ruby already has a way (several ways, actually!) for all these errors to
be
announced on the “first pass”. Test::Unit, RSpec, etc.

60

“Eivind E.” [email protected] wrote in message
news:[email protected]…

corresponding increase in correctness checking being a benefit of less
One strength of Ruby - an important one - is that it is succinct.
There is very little extra noise compared to what is strictly
necessary to say what the program is doing. Your proposal introduce
extra noise. This noise has a cost for readability in some cases. My
opinion is that this cost is higher than the utility of the construct,
as the construct guard against an error that is easy to guard against
in other ways, other ways that are generally better, like unit
testing or string completion.

I disagree that "succinctness" is an important part of Ruby's

strength.
At least, not in the same manner that I think you mean it. Ruby lacks
much
of C/C++ redundant “scaffolding code” (a term I’ve made up) and that
lends
it power. However, I don’t think variable declarations are redundant.
There are times when you deliberately mean to create a variable and
there
are times when you don’t. This is a real distinction and it takes real
information to distinguish it, although not much in my opinion.
Besides, if you were really serious about reducing “line noise,”
you’d
be advocating Python-esque whitespace block definitions. Seriously,
what’s
with all these “end” keywords sprinkled all over the place? That’s just
extra noise. Surely you want to remove that noise, right? Right?

My guess is that declarations are far less common than variable use,

This depends on code style. Those that use a lot of short methods
also have more variable declarations compared to variable assignments,
in my experience.

...those that use a lot of short methods and make use of short lived

variables rather than a more functional structure, yes, have more
variable
declarations. Still, I don’t think it’s so bad…