How much would variable declarations in Ruby make you wince?

<snippy>

>
> > > 2) Accidentally creating a new variable.
>
> This is a danger that will plague any language, IMO.

    To be fair, it has to be said that it is less of a problem in
languages that require variables to be declared or typed.

Hmm. Maybe, but I kind of doubt it. var temp is no more or less
succinct than anything else. It doesn't guarantee you "safeness".
Safeness is what databases are for. Pre-declaration is sort of an
empty promise in flow-control.

<snip>

>
> Todd

     -Jonathan

Todd

···

On Dec 9, 2007 11:39 AM, Dumaiu <Dymaio@gmail.com> wrote:

On Dec 9, 12:19 pm, Todd Benson <caduce...@gmail.com> wrote:

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

···

From: "Trans" <transfire@gmail.com>

> 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

···

On Dec 11, 2007 2:12 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:

On 12/11/07, Just Another Victim of the Ambient Morality > <ihatespam@hotmail.com> wrote:

Perhaps I should avoid buzzwords. I admit that, having never
actually looked 'optimization' up, I may define it more loosely than
you. I didn't mean optimization for performance but for elegance. Ça
ne se dit pas? The purpose of refactoring is to improve code by
increasing elegance, unless I seriously misunderstand. My own
tendency is to overthink it and try to reevaluate a design after every
single change. I think this is another case where balance is best.
If you have achieved such a balance with your "cycles,"
congratulations. I apologize if I offended you.

  -Jonathan

···

On Dec 9, 12:07 pm, Bill Kelly <bi...@cts.com> wrote:

From: "Dumaiu" <Dym...@gmail.com>

> This sounds like Trans's objection. But it's a post facto solution.
> Relentlessly refactoring and testing during development could fall
> into the 'premature optimization' category.

No. Optimizing almost invariably makes code more obscure and more
complex. Thus the reason to do as little optimization as possible,
as late in the project as possible.

The drivers for refactoring are completely opposite from those of
optimization.

The point of refactoring is to improve and simplify the design of
existing code. Refactoring tends to become more difficult the longer
it is put off, and is more risky in the absence of good test
coverage.

As such, it is ideal if refactoring can become a straightforward daily
occurrence; and a comprehensive test suite helps make this possible.
Some kinds of applications are harder to test than others, but it's
almost always worth it to find a way to write automated tests.

In any case, comparing frequent refactoring to premature optimization
is just wrong. . . .

Regards,

Bill

Do you really, truly believe this? I'm going to argue this point.
I'm not saying that predeclaration is innately good: the
disadvantages, whatever they be, might outweigh the advantages. The
only 'promise' I can see it making is that the kind of error that
started this discussion will be less likely. After writing

  var list = create_useful_list

writing

  liist = modify_list

will report an error. Actually, because it is more succinct. My
reasoning is as follows: if someone thinks declarations are merely
pointless, he might not use them himself but won't object to others
using them. If he objects on principle, it's because he thinks they
clutter the code. Performance aside, declarations are disliked
because they take up space and are annoying to write. They're
annoying to write because it takes extra effort; the extra effort
makes it less likely that it'll happen by accident. It doesn't
'guarantee you "safeness,"' it just guarantees you a little more
safety.

  -Jonathan

···

On Dec 9, 12:54 pm, Todd Benson <caduce...@gmail.com> wrote:

On Dec 9, 2007 11:39 AM, Dumaiu <Dym...@gmail.com> wrote:

> On Dec 9, 12:19 pm, Todd Benson <caduce...@gmail.com> wrote:

> To be fair, it has to be said that it is less of a problem in

> languages that require variables to be declared or typed.

Hmm. Maybe, but I kind of doubt it. var temp is no more or less
succinct than anything else. It doesn't guarantee you "safeness".
Safeness is what databases are for. Pre-declaration is sort of an
empty promise in flow-control.

"Todd Benson" <caduceass@gmail.com> wrote in message
news:eaeff8c10712090954k3304961tb8fc1be4a7531ab8@mail.gmail.com...

<snippy>

>
> > > 2) Accidentally creating a new variable.
>
> This is a danger that will plague any language, IMO.

    To be fair, it has to be said that it is less of a problem in
languages that require variables to be declared or typed.

Hmm. Maybe, but I kind of doubt it. var temp is no more or less
succinct than anything else. It doesn't guarantee you "safeness".
Safeness is what databases are for. Pre-declaration is sort of an
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...

···

On Dec 9, 2007 11:39 AM, Dumaiu <Dymaio@gmail.com> wrote:

On Dec 9, 12:19 pm, Todd Benson <caduce...@gmail.com> wrote:

Oh, don't read that the wrong way, it supports highlighting, just not
"end" highlighting.

I use Kate.

T.

···

On Dec 10, 12:16 pm, "Bill Kelly" <bi...@cts.com> wrote:

From: "Trans" <transf...@gmail.com>

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

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

Perhaps I should avoid buzzwords. I admit that, having never
actually looked 'optimization' up, I may define it more loosely than
you.

For what it's worth, I'd suggest that the phrase "premature
optimization" may be more akin to canon, than buzzword, and
tends to mean something very specific.

(By canon, I mean, "the body of rules, principles, or standards
accepted as axiomatic and universally binding in a field of study
or art.")

For completeness sake, the original appearance of the phrase in
publication:

  "We should forget about small efficiencies, say about 97% of
  the time: premature optimization is the root of all evil."

  (Knuth, Donald. Structured Programming with go to Statements,
  ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
  ((Knuth is said to have been parahprasing C.A.R. Hoare))

I didn't mean optimization for performance but for elegance. Ça
ne se dit pas? The purpose of refactoring is to improve code by
increasing elegance, unless I seriously misunderstand. My own
tendency is to overthink it and try to reevaluate a design after every
single change. I think this is another case where balance is best.
If you have achieved such a balance with your "cycles,"
congratulations. I apologize if I offended you.

I think I *was* actually offended. <grin> But it was obviously
based on a misunderstanding.

I don't think I've achieved ideal balance yet... I'm usually
coming at it from the other direction: skipping a few refactorings
until I realize some part of the code is really bothering me, then
having to make time for a larger cleanup. But hopefully I'm
improving.

Regards,

Bill

···

From: "Dumaiu" <Dymaio@gmail.com>

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

···

On Dec 10, 10:30 am, "Just Another Victim of the Ambient Morality" <ihates...@hotmail.com> wrote:

"Todd Benson" <caduce...@gmail.com> wrote in message

news:eaeff8c10712090954k3304961tb8fc1be4a7531ab8@mail.gmail.com...

> On Dec 9, 2007 11:39 AM, Dumaiu <Dym...@gmail.com> wrote:
>> On Dec 9, 12:19 pm, Todd Benson <caduce...@gmail.com> wrote:

>> <snippy>

>> > > > 2) Accidentally creating a new variable.

>> > This is a danger that will plague any language, IMO.

>> To be fair, it has to be said that it is less of a problem in
>> languages that require variables to be declared or typed.

> Hmm. Maybe, but I kind of doubt it. var temp is no more or less
> succinct than anything else. It doesn't guarantee you "safeness".
> Safeness is what databases are for. Pre-declaration is sort of an
> 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...

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 <stuff>"-declarations (or
"my <stuff>" 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.

···

On Dec 10, 2007 5:34 PM, Just Another Victim of the Ambient Morality <ihatespam@hotmail.com> 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...

Hi, to respond briefly towards

"There are actually at least two measures that help preventing this: 1.
use an editor with proper syntax indentation and highlighting."

[...]

"2. Exercise the habit to enter matching pairs always together before you
enter the content

What makes you believe I do not already? :wink:

But editor aside, there is a huge difference in visually appealing
on something. The greatest IDE can make Java [*1] look great, folding
away
all the ugly bits, but under the hood it still remains ugly and
needlessly
verbose. Your brain adapts to the ugliness and blends away the
yucky parts, but the ugliness is still there, and the great
editor just conceals it, like a veil.

In this regard, I do find no "end" visually _more_ appealing to
my eyes than an existing "end". Or multiple ones, if one chose
to rely on heavy if-else branching.

It is not without reason that people prefer python or ruby these
days compared to perl. Years ago perl had no real competition,
it was still used heavily (and still is), but was it visually
really appealing? I think I wrote only about 100 .pl scripts,
compared to around 2000 .rb files so far.
I never had the impression that perl bothered at all about
visual elegance.

It is not a question of habit. Habit changes over time, you
adapt anyway. You have to use "workarounds" everywhere
too and can use your editor to easen up the workload.

It is a question of beauty and elegance.
This is a more general remark, don't think I am focusing
only on 'end' - 'end' is not that important anyway :wink:

[*1] Replace Java with another language as you see fit.
I could mention (((lisp))) but I am afraid i would get
(burned) ...

···

--
Posted via http://www.ruby-forum.com/\.

"Eivind Eklund" <eeklund@gmail.com> wrote in message
news:dc9b20bb0712100945m1dd2ab73p9ab3cf104d5be858@mail.gmail.com...

    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.

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

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 <stuff>"-declarations (or
"my <stuff>" 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.

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

···

On Dec 10, 2007 5:34 PM, Just Another Victim of the Ambient Morality > <ihatespam@hotmail.com> wrote:

<snip>

[*1] Replace Java with another language as you see fit.
I could mention (((lisp))) but I am afraid i would get
(burned) ...

     ...or receive the "death of a thousand 'cdr's." Can't resist.

     -J

···

On Dec 10, 8:18 pm, Marc Heiler <sheve...@linuxmail.org> wrote:

I've had a chance to think some more. First, is the word 'canon'
canonical? I mean, do I have to use it? I've not encountered a field
outisde of computer science or the Roman Catholic Church in which
standards would be described as canon, even if they were 'universally
binding,' which they aren't. It makes me feel like we ought to be
arguing about Star Wars or something.
  But on a more serious note: I am bemused by the discovery that I
still cannot convince myself of any fundamental distinction of intent
between what we call the processes of optimization and of refactoring,
despite the great differences in procedure by which they are
undertaken. I earlier made the error of trying to see the issue in
terms of performance v. "good design," you could say, but it's really
more like a radial tug-of-war between many competing priorities.
After all, even when optimizing purely to decrease the load on the
computer, you still have to choose which *part* of the computer needs
the most attention. By comparison, you refactor code to decrease the
load on at least one, but never all, of the human "parts" of the
software project. And it's blurred further within the domain of
dynamic languages. Even if you think only of maintainability, i.e.,
the human element, tradeoffs must still be made: the more you separate
interface from implementation, the uglier the implementation is going
to get.
  Is that a contentious statement? I'm spinning this out as I go. Let
me know know what you think.

  -Jonathan

···

On Dec 9, 11:17 pm, Bill Kelly <bi...@cts.com> wrote:

From: "Dumaiu" <Dym...@gmail.com>

> Perhaps I should avoid buzzwords. I admit that, having never
> actually looked 'optimization' up, I may define it more loosely than
> you.

For what it's worth, I'd suggest that the phrase "premature
optimization" may be more akin to canon, than buzzword, and
tends to mean something very specific.

(By canon, I mean, "the body of rules, principles, or standards
accepted as axiomatic and universally binding in a field of study
or art.")

For completeness sake, the original appearance of the phrase in
publication:

  "We should forget about small efficiencies, say about 97% of
  the time: premature optimization is the root of all evil."

  (Knuth, Donald. Structured Programming with go to Statements,
  ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
  ((Knuth is said to have been parahprasing C.A.R. Hoare))

> I didn't mean optimization for performance but for elegance. Ça
> ne se dit pas? The purpose of refactoring is to improve code by
> increasing elegance, unless I seriously misunderstand. My own
> tendency is to overthink it and try to reevaluate a design after every
> single change. I think this is another case where balance is best.
> If you have achieved such a balance with your "cycles,"
> congratulations. I apologize if I offended you.

I think I *was* actually offended. <grin> But it was obviously
based on a misunderstanding.

I don't think I've achieved ideal balance yet... I'm usually
coming at it from the other direction: skipping a few refactorings
until I realize some part of the code is really bothering me, then
having to make time for a larger cleanup. But hopefully I'm
improving.

Regards,

Bill

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.

···

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

--
Jay Levitt |
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

> 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 <stuff>"-declarations (or
> "my <stuff>" 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.

    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.

···

On Dec 10, 2007 8:50 PM, Just Another Victim of the Ambient Morality <ihatespam@hotmail.com> 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?

···

On Dec 10, 4:13 pm, Jay Levitt <jay+n...@jay.fm> wrote:

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.

--
Jay Levitt |
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

"Eivind Eklund" <eeklund@gmail.com> wrote in message
news:dc9b20bb0712101505n32086fdcgb11d508192064d03@mail.gmail.com...

> 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 <stuff>"-declarations (or
> "my <stuff>" 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.

    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.

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

···

On Dec 10, 2007 8:50 PM, Just Another Victim of the Ambient Morality > <ihatespam@hotmail.com> wrote:

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.

···

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?

--
Jay Levitt |
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?

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

   def say_hello(destination, first_name)
     var destination

     Boy, I know that if I were implementing this 'var' stuff, I would
make that illegal too!

     var firsst_name

     ...And that wouldn't get written at all...

Hey, no error, no overlap!

      ...and the real issue would be how to handle the naming of block
parms, which I don't think has been brought up yet.

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

      I can get back to you once I've tried RSpec.

       -Jonathan

···

On Dec 10, 5:57 pm, Jay Levitt <jay+n...@jay.fm> wrote:

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