A major ruby annoyance!

ruby-talk
1

I am a newbie in Ruby. I have read several books including pickaxe and wrote
several thousands lines of code. So far, as an ex perl user, I have found
the major annoyance with ruby is the lack of declaration of variables.
Automatic creation, in perl jargon autovification is the common feature of
many high level languages such as perl, paython, visual basic etc. but most
of the these languages have seen that this not necessarily a good thing and
created flags, commands to prohibit it if the developer wants to. I really
wish ruby had one. Last several hours I spent debugging a malfunctioning
code just to see mistyped variable name was causing all the problem. I had
to put many log statements which polluted to the code.

I guess in Pickaxe book, unit testing is presented as the cure for this
problem which I do not agree. I can not write a test code for every peace of
little functionality, besides I am eager to make the compiler or interpreter
to work for me. Why not tell the interpreter to check the code, instead of
writing very detailed test programs. I am not a very good typist and I often
mistype variable names, often I had to depend on vim's auto completion
feature. But I do not want to depend to an editor or an IDE for this.

I have also found the ruby's -w flag does not work as I perl -w flag does.
In perl warnings are really descriptive. You can even use a module called
diagnostics which almost teaches to fix the problem that crashes program or
generates warning etc. I often do not use -w as because I receive warnings
from libraries that my code includes or warnings I do not understand at all.

May be I am the only one who is bothered with these. I do not know.

2

Only instance variables are auto-vivified.

% irb
irb(main):001:0> puts a
NameError: undefined local variable or method `a' for main:Object
         from (irb):1
irb(main):002:0>

I would suggest using the attr_* methods or writing your own accessors for any case where you might need to access an instance varible

@something = exp

is probably a bad sign anywhere but initialize and/or

def something=(x)
   ...
end

likewise a = @something should almost always be a = self.something

···

On May 6, 2006, at 7:00 PM, Talha Oktay wrote:

I am a newbie in Ruby. I have read several books including pickaxe and wrote
several thousands lines of code. So far, as an ex perl user, I have found
the major annoyance with ruby is the lack of declaration of variables.
Automatic creation, in perl jargon autovification is the common feature of
many high level languages such as perl, paython, visual basic etc. but most
of the these languages have seen that this not necessarily a good thing and
created flags, commands to prohibit it if the developer wants to. I really
wish ruby had one. Last several hours I spent debugging a malfunctioning
code just to see mistyped variable name was causing all the problem. I had
to put many log statements which polluted to the code.

I guess in Pickaxe book, unit testing is presented as the cure for this
problem which I do not agree. I can not write a test code for every peace of
little functionality, besides I am eager to make the compiler or interpreter
to work for me. Why not tell the interpreter to check the code, instead of
writing very detailed test programs. I am not a very good typist and I often
mistype variable names, often I had to depend on vim's auto completion
feature. But I do not want to depend to an editor or an IDE for this.

I have also found the ruby's -w flag does not work as I perl -w flag does.
In perl warnings are really descriptive. You can even use a module called
diagnostics which almost teaches to fix the problem that crashes program or
generates warning etc. I often do not use -w as because I receive warnings
from libraries that my code includes or warnings I do not understand at all.

May be I am the only one who is bothered with these. I do not know.

3

I am a newbie in Ruby. I have read several books including pickaxe and wrote
several thousands lines of code. So far, as an ex perl user, I have found
the major annoyance with ruby is the lack of declaration of variables.
Automatic creation, in perl jargon autovification is the common feature of
many high level languages such as perl, paython, visual basic etc. but most

You can customize autovivification in Ruby. Consider the Hash

h1 = Hash.new { |h,k| h[k] = 0 }
h1[:a] #=> 0

h2 = Hash.new { |h,k| h[k] = 1 }
h2[:a] #=> 1

h3 = Hash.new { |h,k| h[k] = }
h2[:a] << "alpha" #=> ["alpha"]

l = lambda { |h,k| h[k] = Hash.new &l }
h4 = Hash.new &l
h[:a][:b][:c] = 5 #=> { :a => { :b => { :c => {} }}}

of the these languages have seen that this not necessarily a good thing and
created flags, commands to prohibit it if the developer wants to. I really
wish ruby had one. Last several hours I spent debugging a malfunctioning
code just to see mistyped variable name was causing all the problem. I had
to put many log statements which polluted to the code.

You can try to up the warning level. It might also help to make smaller methods.
I you want, post your code and let some people take a look to give
you some pointers on how to prevent this type of thing.

I guess in Pickaxe book, unit testing is presented as the cure for this
problem which I do not agree. I can not write a test code for every peace of
little functionality, besides I am eager to make the compiler or interpreter
to work for me. Why not tell the interpreter to check the code, instead of
writing very detailed test programs. I am not a very good typist and I often
mistype variable names, often I had to depend on vim's auto completion
feature. But I do not want to depend to an editor or an IDE for this.

The compiler can't think for you. In Ruby, a little bit of code can do a lot,
in fact, a lot more than a compiler can guess at. Consider:

   [1,2,3].inject(0) { |prod,x| prod * x }
   [1,2,3].inject(1) { |prod,x| prod * x }

How is an interpretive language supposed to know (or take the time to know)
that the second case is what you want, not the first?

I have also found the ruby's -w flag does not work as I perl -w flag does.
In perl warnings are really descriptive. You can even use a module called
diagnostics which almost teaches to fix the problem that crashes program or
generates warning etc. I often do not use -w as because I receive warnings
from libraries that my code includes or warnings I do not understand at all.

May be I am the only one who is bothered with these. I do not know.

Some mental reprogramming takes time. We can't brain wash you overnight. :wink:

Jim Freeze

···

On May 6, 2006, at 6:00 PM, Talha Oktay wrote:

4

Weeellll....

if this does really bother you sooo much
(actally it bothers me a bit as well), you
can anytime trap the object creation process.

Simplest possibility would be to add two
functions to allow/disallow/throw-a-fit/or-
whatever-you-like-best on any attempt to
create an object.

Where is the problem?

Regards, 0ffh

···

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

5

In my case, I use -w always, and try to depend on autocompletion feature
available
in vim. (^P, ^N, ^XO) Other than that, AFAIK, there are no alternatives in
the language
which doesn't have variable declaration feature.

Thought Ruby has syntax check facility, "ruby -wc", it does not find typos.
It just check
syntactic errors.

Sincerely,
Minkoo Seo

···

On 5/7/06, Talha Oktay <toktay@gmail.com> wrote:

I am a newbie in Ruby. I have read several books including pickaxe and
wrote
several thousands lines of code. So far, as an ex perl user, I have found
the major annoyance with ruby is the lack of declaration of variables.
Automatic creation, in perl jargon autovification is the common feature
of
many high level languages such as perl, paython, visual basic etc. but
most
of the these languages have seen that this not necessarily a good thing
and
created flags, commands to prohibit it if the developer wants to. I really
wish ruby had one. Last several hours I spent debugging a
malfunctioning
code just to see mistyped variable name was causing all the problem. I had
to put many log statements which polluted to the code.

I guess in Pickaxe book, unit testing is presented as the cure for this
problem which I do not agree. I can not write a test code for every peace
of
little functionality, besides I am eager to make the compiler or
interpreter
to work for me. Why not tell the interpreter to check the code, instead of
writing very detailed test programs. I am not a very good typist and I
often
mistype variable names, often I had to depend on vim's auto completion
feature. But I do not want to depend to an editor or an IDE for this.

I have also found the ruby's -w flag does not work as I perl -w flag does.
In perl warnings are really descriptive. You can even use a module called
diagnostics which almost teaches to fix the problem that crashes program
or
generates warning etc. I often do not use -w as because I receive warnings
from libraries that my code includes or warnings I do not understand at
all.

May be I am the only one who is bothered with these. I do not know.

6

Allow me to rearrange your statements a bit.

I am a newbie in Ruby. I have read several books including pickaxe and wrote
several thousands lines of code. So far, as an ex perl user, I have found
the major annoyance with ruby is the lack of declaration of variables.
Automatic creation, in perl jargon autovification is the common feature of
many high level languages such as perl, paython, visual basic etc. but most
of the these languages have seen that this not necessarily a good thing and
created flags, commands to prohibit it if the developer wants to. I really
wish ruby had one.

I guess in Pickaxe book, unit testing is presented as the cure for this
problem which I do not agree. I can not write a test code for every peace of
little functionality, besides I am eager to make the compiler or interpreter
to work for me.

Yes, you can. I do.

Last several hours I spent debugging a malfunctioning code just to see mistyped variable name was causing all the problem. I had to put many log statements which polluted to the code.

Or, you could have written some tests that wouldn't have polluted your code and saved yourself several hours (and having to pull out all those log statements).

···

On May 6, 2006, at 4:00 PM, Talha Oktay wrote:

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

7

Uhm, I need to correct some hasty typos.

h3 = Hash.new { |h,k| h[k] = }
h2[:a] << "alpha" #=> ["alpha"]

should be

h3[:a] << "alpha" #=> ["alpha"]

l = lambda { |h,k| h[k] = Hash.new &l }
h4 = Hash.new &l
h[:a][:b][:c] = 5 #=> { :a => { :b => { :c => {} }}}

should be

h4[:a][:b][:c] = 5 #=> { :a => { :b => { :c => 5 }}}

Jim Freeze

8

Also, how is Ruby meant to know wether something is a typo, or a new var?

Joey

···

On 5/7/06, Minkoo Seo <minkoo.seo@gmail.com> wrote:

In my case, I use -w always, and try to depend on autocompletion feature
available
in vim. (^P, ^N, ^XO) Other than that, AFAIK, there are no alternatives
in
the language
which doesn't have variable declaration feature.

Thought Ruby has syntax check facility, "ruby -wc", it does not find
typos.
It just check
syntactic errors.

Sincerely,
Minkoo Seo

On 5/7/06, Talha Oktay <toktay@gmail.com> wrote:
>
> I am a newbie in Ruby. I have read several books including pickaxe and
> wrote
> several thousands lines of code. So far, as an ex perl user, I have
found
> the major annoyance with ruby is the lack of declaration of variables.
> Automatic creation, in perl jargon autovification is the common feature
> of
> many high level languages such as perl, paython, visual basic etc. but
> most
> of the these languages have seen that this not necessarily a good thing
> and
> created flags, commands to prohibit it if the developer wants to. I
really
> wish ruby had one. Last several hours I spent debugging a
> malfunctioning
> code just to see mistyped variable name was causing all the problem. I
had
> to put many log statements which polluted to the code.
>
> I guess in Pickaxe book, unit testing is presented as the cure for this
> problem which I do not agree. I can not write a test code for every
peace
> of
> little functionality, besides I am eager to make the compiler or
> interpreter
> to work for me. Why not tell the interpreter to check the code, instead
of
> writing very detailed test programs. I am not a very good typist and I
> often
> mistype variable names, often I had to depend on vim's auto completion
> feature. But I do not want to depend to an editor or an IDE for this.
>
> I have also found the ruby's -w flag does not work as I perl -w flag
does.
> In perl warnings are really descriptive. You can even use a module
called
> diagnostics which almost teaches to fix the problem that crashes program
> or
> generates warning etc. I often do not use -w as because I receive
warnings
> from libraries that my code includes or warnings I do not understand at
> all.
>
> May be I am the only one who is bothered with these. I do not know.
>

9

Hi --

···

On Sun, 7 May 2006, Logan Capaldo wrote:

I would suggest using the attr_* methods or writing your own accessors for any case where you might need to access an instance varible

@something = exp

is probably a bad sign anywhere but initialize and/or

def something=(x)
...
end

likewise a = @something should almost always be a = self.something

It all depends. The attr_* family uses instance variables to do what
it does, but there's no reason that should be viewed as the only or
best or likeliest use of instance variables. It's layered on top of
a subsystem (instance variables) that have other uses too.

David

--
David A. Black (dblack@wobblini.net)
* Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
   > Ruby and Rails consultancy and training
* Author of "Ruby for Rails" from Manning Publications!
   > Paper version coming in early May! http://rubyurl.com/DDZ

10

I think this is what the OP is getting at. In ruby:

    hard_to_spell_variable = 43

    puts 'run a few statements'
    puts "maybe output the var #{hard_to_spell_variable}"

    hard_to_speel_variable = 'a new value' # oops...

    print "output the new value."
    puts " Should == 'a new value': #{hard_to_spell_variable}" # doh!!!

Whereas in perl, under the strict pragma, you get:

    my $hard_to_spell_variable = 43

    # ...

    $hard_to_speel_variable = 'a new value' # perl throws a hissy fit.

This does present problems in other places as well. I've seen it a
couple of times when people are trying to define DSLs. You want to
force ruby to dispatch to missing_method, but it won't because it
assumes that you are trying to assign to a new local variable

    my_dsl do
      please_dispatch_method = 'some value'
      # undefined local variable!
    end

···

--
Lou

11

Okay, this should be a start!

---------------- cut here ----------------<

def local(context,*declared)
  declared=declared.map{|e| e.id2name}
  found=eval("local_variables",context)
  found.each do |name|
    if !declared.include?(name)
      raise "hell"
    end
  end
end

def test
  local binding,:foo,:bar
  foo=0
  bar=0
# baz=0 # uncomment to raise hell!
end

---------------- and here ----------------<

Beautify and extend this for a few days,
and you may have something you can live with.

Regards, 0ffh

···

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

12

Hi --

I would suggest using the attr_* methods or writing your own accessors for any case where you might need to access an instance varible

@something = exp

is probably a bad sign anywhere but initialize and/or

def something=(x)
...
end

likewise a = @something should almost always be a = self.something

It all depends. The attr_* family uses instance variables to do what
it does, but there's no reason that should be viewed as the only or
best or likeliest use of instance variables. It's layered on top of
a subsystem (instance variables) that have other uses too.

David

I wans't suggesting only using ivars for accessors, but I believe strongly in the uniform access principle. Even if you using ivars for something completely internal that no one sees, you should still wrap the accesses to them in methods (private ones).

···

On May 7, 2006, at 5:00 AM, dblack@wobblini.net wrote:

On Sun, 7 May 2006, Logan Capaldo wrote:

--
David A. Black (dblack@wobblini.net)
* Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
  > Ruby and Rails consultancy and training
* Author of "Ruby for Rails" from Manning Publications!
  > Paper version coming in early May! http://rubyurl.com/DDZ

13

Hi,

Thank you all for the posts. They were all helpful and inspiring. I am
neither live in States(I live in Turkey) nor a native speaker and Louis J.
Scoras presented my problem beautifully much better than I could. So I
especially thank him for that.

First of all, I would like to say that the problem is valid for all types of
variables. You can mistype a local variable name in the same block and you
just create a second variable instantly. You can create an instance variable
anywhere in the class by adding @ in front of the variable name. If you
mistyped an instance variable name in a method, probably the one you had
properly initialized in your constructor, oops, sorry, you just created a
new variable and had a brand new bug. If you are agile guy, and spent double
time writing test for every little functionality, hopefully you would find
it soon. Nothing protecting us from these kinds of errors. For global
variables, constants they have all the same problem.

What I have understood from all the posts, is that; there is no syntactical
way for predeclaration of variables. All the solutions that you have
provided includes partial solutions to the problem and includes some kind
of error handling or conventional code and using them consistently which I
do not want. According to me, they look ugly in such a consistent beautiful
language. Besides that kind of custom solutions, according to me, just
increase the complexity of the code.

I would like to comment against posts which simply emphasizes that the
interpreter can not think for us. I know that of course. What if we could
tell the interpreter by saying that these are the variables that I am going
to use in the class scope, in a block, in a method or in global scope etc.
and ask the interpreter not to allow any other variable usage in the
specified scope? Then the interpreter would definitely know our intent? I
meant that.

What I liked most about ruby how easy to write classes. While using ruby I
had to mind shift myself persistently for using object oriented techniques
in even small scripts. Writing classes, using objects are no longer burden.
The built in attr_* removes all burden of getters and setters etc. For
example to write a class in perl, java, c++ one has to implement all the
getters or setters. In perl, one can use some custom modules from cpan which
creates a class for you, but all of which all are non-standard modules.(Okay
some of the most widely used ones come with the distribution, but they are
not part of the language) There are many other jewels that ruby has built-in
or in its standard libraries. Ruby made unconventional, custom
implementations made public and mainstream by making them built-in to the
language as in attr_* example. On the other hand, for the problem that I
present in my post, I am required to implement custom solutions which
partially solve the problem. The problem that I stated here is one of the
biggest sources of unintentional bugs. Ruby is supposed to cut down
development time and reduce the unintentional complexity dramatically. It is
one of most high level languages I have encountered. So I believe ruby
should have not missed this feature. I really hope to see that ruby language
supports these with a new set of keywords in its next releases. Otherwise, I
do not think that ruby would be able get of out scripting and the
lightweight web world or get into world big production systems. I believe
ruby has a capacity to go forward if these kinds of doors could be closed.

Of course, I talk without understanding the language guts. I know that
variables are just references and everything is dynamically decided etc. It
may not be easy to implement this. I do not know. But as the user/customer
of ruby, I find that my development time does not dramatically increased as
much as I expected. Yes I develop faster, but I lose the time that I gained
in coding in testing. I prefer testing the functionality and the
requirements not the guts. If I can run the code, I expect that language
issues must be solved. I am very much suprised when I receive a no method
error. Why do I have to run the statement just to see that object does not
have that method implemented. I would like to deal with bugs that are caused
by the misapprehension or misimplementation of the problem. I expect the
compiler, interpreter to handle inconsistencies in the language usage
itself. Ruby currently mixes the problem domain with the language domain
because it does not let developer inform itself about language set the
developer wants to use. I do not expect the language to be as strict as Ada
by default but it should let the developer to configure how strict the
interpreter should be. In perl, a developer can dynamically command the perl
interpreter how strictly interpret the code. If perl can, whose latest major
release about 12 years old, ruby has got to do this.

I prefer a language that loudly shouts at with discriptive information when
I do something wrong instead of running but producing erroneous results.
Just because of this I have the habit of using zillions of assertions in my
code when I developed in other languages. I have not been able to find an
assertion module in ruby by the way (yes I know, you do not need it because
it is very easy to write one or hey, another answer why do I ever need
it..:)). I really admire you all guys because of your self confidence.

Yes, as the Pickaxe books says strict typing made some code less portable
and less reusable, but I am ready to make that compromise most of the time
if my name depends on the correct functionality of the software I wrote.

My comments are not to criticize ruby language and its community but to
contribute to it's perfection. I already feel myself as rubyist but
want this language make its way more broader domain, even better to my
domain..:slight_smile:

Sincerely.

···

On 5/7/06, Logan Capaldo <logancapaldo@gmail.com> wrote:

On May 7, 2006, at 5:00 AM, dblack@wobblini.net wrote:

> Hi --
>
> On Sun, 7 May 2006, Logan Capaldo wrote:
>
>> I would suggest using the attr_* methods or writing your own
>> accessors for any case where you might need to access an instance
>> varible
>>
>> @something = exp
>>
>> is probably a bad sign anywhere but initialize and/or
>>
>> def something=(x)
>> ...
>> end
>>
>> likewise a = @something should almost always be a = self.something
>
> It all depends. The attr_* family uses instance variables to do what
> it does, but there's no reason that should be viewed as the only or
> best or likeliest use of instance variables. It's layered on top of
> a subsystem (instance variables) that have other uses too.
>
> David
>
I wans't suggesting only using ivars for accessors, but I believe
strongly in the uniform access principle. Even if you using ivars for
something completely internal that no one sees, you should still wrap
the accesses to them in methods (private ones).

> --
> David A. Black (dblack@wobblini.net)
> * Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
> > Ruby and Rails consultancy and training
> * Author of "Ruby for Rails" from Manning Publications!
> > Paper version coming in early May! http://rubyurl.com/DDZ
>

14

Hi --

Hi --

I would suggest using the attr_* methods or writing your own accessors for any case where you might need to access an instance varible

@something = exp

is probably a bad sign anywhere but initialize and/or

def something=(x)
...
end

likewise a = @something should almost always be a = self.something

It all depends. The attr_* family uses instance variables to do what
it does, but there's no reason that should be viewed as the only or
best or likeliest use of instance variables. It's layered on top of
a subsystem (instance variables) that have other uses too.

David

I wans't suggesting only using ivars for accessors, but I believe strongly in the uniform access principle. Even if you using ivars for something completely internal that no one sees, you should still wrap the accesses to them in methods (private ones).

But then you are suggesting that they only be used for accessors :slight_smile:

I can't help feeling it's a lot of trouble to do this:

   class C
     def initialize
       self.container =
     end

     private
     attr_writer :container
   end

rather than:

   class C
     def initialize
       @container =
     end
   end

if you're just using @container as a state variable here and there.

I think the role of the uniform access principle here is open to
question. As I understand it, that principle states that the outside
user shouldn't be able to tell whether a value is stored or calculated
-- essentially, an attribute vs. the return value of a method call.
But instance variables are neither attributes nor methods; so they're
not really candidates for being evaluated for uniform/non-uniform
access. And Ruby's attributes *are* methods. To that extent, Ruby
actually enforces the UA principle; when you do this:

   obj.something

you know that you've called a method. There's no other possibility,
so there's no opportunity for divergence of the interface.

David

···

On Mon, 8 May 2006, Logan Capaldo wrote:

On May 7, 2006, at 5:00 AM, dblack@wobblini.net wrote:

On Sun, 7 May 2006, Logan Capaldo wrote:

--
David A. Black (dblack@wobblini.net)
* Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
   > Ruby and Rails consultancy and training
* Author of "Ruby for Rails" from Manning Publications!
   > Paper version coming in early May! http://rubyurl.com/DDZ

15

You probably should really invest some time into unittesting - it's worth a lot.
And it is true, i spend at least half of my time on unittests (using
RSpec http://rspec.rubyforge.org/ and RubySelenium
http://rubyselenium.rubyforge.org) but have a solution that works (TM)
and that i can use universally afterwards - always being confident
that it behaves the way i want it to.
I am sorry that I don't have time to answer lengthy on your mail - but
i have to say that wrapping your head around unittesting is worth the
effort and really rewarding in the end.
ah, and controlled declaration of variables would probably kill me :expressionless:

···

On 5/8/06, Talha Oktay <toktay@gmail.com> wrote:

Hi,

Thank you all for the posts. They were all helpful and inspiring. I am
neither live in States(I live in Turkey) nor a native speaker and Louis J.
Scoras presented my problem beautifully much better than I could. So I
especially thank him for that.

First of all, I would like to say that the problem is valid for all types of
variables. You can mistype a local variable name in the same block and you
just create a second variable instantly. You can create an instance variable
anywhere in the class by adding @ in front of the variable name. If you
mistyped an instance variable name in a method, probably the one you had
properly initialized in your constructor, oops, sorry, you just created a
new variable and had a brand new bug. If you are agile guy, and spent double
time writing test for every little functionality, hopefully you would find
it soon. Nothing protecting us from these kinds of errors. For global
variables, constants they have all the same problem.

What I have understood from all the posts, is that; there is no syntactical
way for predeclaration of variables. All the solutions that you have
provided includes partial solutions to the problem and includes some kind
of error handling or conventional code and using them consistently which I
do not want. According to me, they look ugly in such a consistent beautiful
language. Besides that kind of custom solutions, according to me, just
increase the complexity of the code.

I would like to comment against posts which simply emphasizes that the
interpreter can not think for us. I know that of course. What if we could
tell the interpreter by saying that these are the variables that I am going
to use in the class scope, in a block, in a method or in global scope etc.
and ask the interpreter not to allow any other variable usage in the
specified scope? Then the interpreter would definitely know our intent? I
meant that.

What I liked most about ruby how easy to write classes. While using ruby I
had to mind shift myself persistently for using object oriented techniques
in even small scripts. Writing classes, using objects are no longer burden.
The built in attr_* removes all burden of getters and setters etc. For
example to write a class in perl, java, c++ one has to implement all the
getters or setters. In perl, one can use some custom modules from cpan which
creates a class for you, but all of which all are non-standard modules.(Okay
some of the most widely used ones come with the distribution, but they are
not part of the language) There are many other jewels that ruby has built-in
or in its standard libraries. Ruby made unconventional, custom
implementations made public and mainstream by making them built-in to the
language as in attr_* example. On the other hand, for the problem that I
present in my post, I am required to implement custom solutions which
partially solve the problem. The problem that I stated here is one of the
biggest sources of unintentional bugs. Ruby is supposed to cut down
development time and reduce the unintentional complexity dramatically. It is
one of most high level languages I have encountered. So I believe ruby
should have not missed this feature. I really hope to see that ruby language
supports these with a new set of keywords in its next releases. Otherwise, I
do not think that ruby would be able get of out scripting and the
lightweight web world or get into world big production systems. I believe
ruby has a capacity to go forward if these kinds of doors could be closed.

Of course, I talk without understanding the language guts. I know that
variables are just references and everything is dynamically decided etc. It
may not be easy to implement this. I do not know. But as the user/customer
of ruby, I find that my development time does not dramatically increased as
much as I expected. Yes I develop faster, but I lose the time that I gained
in coding in testing. I prefer testing the functionality and the
requirements not the guts. If I can run the code, I expect that language
issues must be solved. I am very much suprised when I receive a no method
error. Why do I have to run the statement just to see that object does not
have that method implemented. I would like to deal with bugs that are caused
by the misapprehension or misimplementation of the problem. I expect the
compiler, interpreter to handle inconsistencies in the language usage
itself. Ruby currently mixes the problem domain with the language domain
because it does not let developer inform itself about language set the
developer wants to use. I do not expect the language to be as strict as Ada
by default but it should let the developer to configure how strict the
interpreter should be. In perl, a developer can dynamically command the perl
interpreter how strictly interpret the code. If perl can, whose latest major
release about 12 years old, ruby has got to do this.

I prefer a language that loudly shouts at with discriptive information when
I do something wrong instead of running but producing erroneous results.
Just because of this I have the habit of using zillions of assertions in my
code when I developed in other languages. I have not been able to find an
assertion module in ruby by the way (yes I know, you do not need it because
it is very easy to write one or hey, another answer why do I ever need
it..:)). I really admire you all guys because of your self confidence.

Yes, as the Pickaxe books says strict typing made some code less portable
and less reusable, but I am ready to make that compromise most of the time
if my name depends on the correct functionality of the software I wrote.

My comments are not to criticize ruby language and its community but to
contribute to it's perfection. I already feel myself as rubyist but
want this language make its way more broader domain, even better to my
domain..:slight_smile:

Sincerely.

On 5/7/06, Logan Capaldo <logancapaldo@gmail.com> wrote:
>
> On May 7, 2006, at 5:00 AM, dblack@wobblini.net wrote:
>
> > Hi --
> >
> > On Sun, 7 May 2006, Logan Capaldo wrote:
> >
> >> I would suggest using the attr_* methods or writing your own
> >> accessors for any case where you might need to access an instance
> >> varible
> >>
> >> @something = exp
> >>
> >> is probably a bad sign anywhere but initialize and/or
> >>
> >> def something=(x)
> >> ...
> >> end
> >>
> >> likewise a = @something should almost always be a = self.something
> >
> > It all depends. The attr_* family uses instance variables to do what
> > it does, but there's no reason that should be viewed as the only or
> > best or likeliest use of instance variables. It's layered on top of
> > a subsystem (instance variables) that have other uses too.
> >
> > David
> >
> I wans't suggesting only using ivars for accessors, but I believe
> strongly in the uniform access principle. Even if you using ivars for
> something completely internal that no one sees, you should still wrap
> the accesses to them in methods (private ones).
>
> > --
> > David A. Black (dblack@wobblini.net)
> > * Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
> > > Ruby and Rails consultancy and training
> > * Author of "Ruby for Rails" from Manning Publications!
> > > Paper version coming in early May! http://rubyurl.com/DDZ
> >
>

16

Talha Oktay wrote:

Hi,

Thank you all for the posts. They were all helpful and inspiring. I am
neither live in States(I live in Turkey) nor a native speaker and Louis J.
Scoras presented my problem beautifully much better than I could. So I
especially thank him for that.

[snip]

I am not trying to say your concerns are not valid. But every
newbie comes to Ruby and wants to change it.

My advice is always: Use it for 90 days as it is, and then think
about it some more.

The top things, as I recall, that people insist Ruby absolutely
HAS TO HAVE are:

1. significant whitespace as in Python
2. braces instead of keyword...end
3. static typing
4. variable declarations

But in my opinion Ruby doesn't "have to have" any of these things.
In fact, Ruby evolved from languages that had those things. It
evolved away from them, not toward them.

Humans' evolutionary forebears might feel that gills or a tail or
full-body fur are indispensable. I as a human do not feel a special
need for them.

Hal

17

Hi

I have a good friend from Turkey.
You've moved farther than him, he still clings to Perl and thinks
$%; help readability. But other than that, you have a lot of similarities.

He has no time for unit testing. The reason? He's too busy fixing bugs.

I would like to comment against posts which simply emphasizes that the
interpreter can not think for us. I know that of course. What if we could
tell the interpreter by saying that these are the variables that I am going
to use in the class scope, in a block, in a method or in global scope etc.
and ask the interpreter not to allow any other variable usage in the
specified scope? Then the interpreter would definitely know our intent? I
meant that.

One could do this. I'm not sure of the performance hit though. Probably
wouldn't be used by experienced Rubyists.

much as I expected. Yes I develop faster, but I lose the time that I gained
in coding in testing. I prefer testing the functionality and the
requirements not the guts.

Are you sure? You need to consider the aggregate of time wasted
by your users and yourself from releasing bugs that could have been
caught from simple unit tests. From my experience, coding without
testing is 4x bad. Programmers can produce twice the code with
twice the bugs instead of 1x the code and 0.01x the bugs.

If I can run the code, I expect that language
issues must be solved.

This is not even true with static languages.

I am very much suprised when I receive a no method
error. Why do I have to run the statement just to see that object does not
have that method implemented.

Try unit testing for a while and you will see. After doing
   1) write code
   2) write test
   3) run test and see it succeed

you start to get paranoid that your tests aren't being run. :slight_smile:
Seeing them fail, then succeed has a euphoric effect.

I would like to deal with bugs that are caused
by the misapprehension or misimplementation of the problem.

Unit tests help here a lot since you essentially have to state the problem
from the users perspective.

I prefer a language that loudly shouts at with discriptive information when
I do something wrong instead of running but producing erroneous results.

Dynamic languages typically don't shout. Ruby has much more decorum.

Just because of this I have the habit of using zillions of assertions in my
code when I developed in other languages. I have not been able to find an

Why are you willing to write assertions but not unit tests?

Jim Freeze

···

On May 7, 2006, at 6:18 PM, Talha Oktay wrote:

18

Well at least if you do it my way, you don't get tripped up by typos, :wink:

···

On May 8, 2006, at 4:10 PM, dblack@wobblini.net wrote:

Hi --

On Mon, 8 May 2006, Logan Capaldo wrote:

On May 7, 2006, at 5:00 AM, dblack@wobblini.net wrote:

Hi --
On Sun, 7 May 2006, Logan Capaldo wrote:

I would suggest using the attr_* methods or writing your own accessors for any case where you might need to access an instance varible
@something = exp
is probably a bad sign anywhere but initialize and/or
def something=(x)
...
end
likewise a = @something should almost always be a = self.something

It all depends. The attr_* family uses instance variables to do what
it does, but there's no reason that should be viewed as the only or
best or likeliest use of instance variables. It's layered on top of
a subsystem (instance variables) that have other uses too.
David

I wans't suggesting only using ivars for accessors, but I believe strongly in the uniform access principle. Even if you using ivars for something completely internal that no one sees, you should still wrap the accesses to them in methods (private ones).

But then you are suggesting that they only be used for accessors :slight_smile:

I can't help feeling it's a lot of trouble to do this:

  class C
    def initialize
      self.container =
    end

    private
    attr_writer :container
  end

rather than:

  class C
    def initialize
      @container =
    end
  end

if you're just using @container as a state variable here and there.

I think the role of the uniform access principle here is open to
question. As I understand it, that principle states that the outside
user shouldn't be able to tell whether a value is stored or calculated
-- essentially, an attribute vs. the return value of a method call.
But instance variables are neither attributes nor methods; so they're
not really candidates for being evaluated for uniform/non-uniform
access. And Ruby's attributes *are* methods. To that extent, Ruby
actually enforces the UA principle; when you do this:

  obj.something

you know that you've called a method. There's no other possibility,
so there's no opportunity for divergence of the interface.

David

--
David A. Black (dblack@wobblini.net)
* Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
  > Ruby and Rails consultancy and training
* Author of "Ruby for Rails" from Manning Publications!
  > Paper version coming in early May! http://rubyurl.com/DDZ

19

Well, either you can be an agile guy and type twice as much or you can do it your way and spend several hours debugging malfunctioning code and adding log statements.

I've found its easier to be an agile guy and spend my time doing a little more typing.

Rather than chasing down the same errors over and over why not write some tests. I don't like to repeat my mistakes and a solid test suite keeps that from happening.

···

On May 7, 2006, at 4:18 PM, Talha Oktay wrote:

If you mistyped an instance variable name in a method, probably the one you had properly initialized in your constructor, oops, sorry, you just created a new variable and had a brand new bug. If you are agile guy, and spent double time writing test for every little functionality, hopefully you would find it soon.

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

20

First of all, I would like to say that the problem is valid for all types of
variables. You can mistype a local variable name in the same block and you
just create a second variable instantly.

Not necessarily. You have to mistype a local variable name IN AN ASSIGNMENT.

I loved Pascal's requirement of pre-declaring variables. It seemed a very sensible practice to me, and forced other people's code to be more readable to me, as well as making my own current code more readable to my future self.

"So why," I asked myself, "haven't I had more problems with variable name typos in Ruby?"

In point of fact, I *do* have a lot of problems with getting the name wrong, especially since Ruby, like most primitive computer systems but unlike the standard behavior of people, thinks that an "A" is fundamentally different than an "a". That one causes me constant irritation.

But it's easy to spot and fix, because the error message is almost always "NIL doesn't have a .whatever method." And lo and behold, it's because I got my variable name wrong.

I think, Talha, that it's not "Unit testing" that would alleviate your problems. I think that what would help the most is if you used fewer variables in the first place. One of my favorite 'tricks' in Ruby is being able to stack method calls up. In the process of doing that, I eliminate the need for a lot of intermediate variables.

What I have understood from all the posts, is that; there is no syntactical
way for predeclaration of variables. All the solutions that you have
provided includes partial solutions to the problem and includes some kind
of error handling or conventional code and using them consistently which I
do not want. According to me, they look ugly in such a consistent beautiful
language. Besides that kind of custom solutions, according to me, just
increase the complexity of the code.

But *any* means of adding declarations is going to be a "custom solution." I mean, there's absolutely no way that variable declaration would become a required component of Ruby. At best, it would be an option. So if somebody wants to use it, first they have to enable it, probably by including the module that causes it to be possible. Then each module or class that wants to enforce it has to mix it in, because all the existing Ruby code would immediately break if it's required globally. Then there are the new declarations themselves.

How did you imagine this could be added to Ruby without doing something "ugly?"

On the other hand, for the problem that I
present in my post, I am required to implement custom solutions which
partially solve the problem. The problem that I stated here is one of the
biggest sources of unintentional bugs. Ruby is supposed to cut down
development time and reduce the unintentional complexity dramatically. It is
one of most high level languages I have encountered. So I believe ruby
should have not missed this feature.

I'm not sure you'd get consensus that variable declaration is a feature. :slight_smile:

I prefer a language that loudly shouts at with discriptive information when
I do something wrong instead of running but producing erroneous results.

Probably the #1 reason why, having tried using C, I have no intention of ever exposing myself to such a poorly designed language again.

I really hope to see that ruby language
supports these with a new set of keywords in its next releases.

What kind of keywords would you want, and how would they work?

···

On May 7, 2006, at 16:18, Talha Oktay wrote: