So, I had a conversation with a colleague of mine and he brought up a
feature request for another language that is a lot like Ruby but is not
Ruby. It was an interesting request and, after I had thought about it a
bit, I discovered that I would like this feature, too!
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
2) Accidentally creating a new variable.
Unfortunately for me, very little can be done about my first point. I
understand and enjoy the power of duck-typing, which specifically allows me
to exercise this bug.
However, something can be done about the second point. Let me exemplify
the problem:
list = create_useful_list
if should_modify_list(list)
# I meant to modify the variable "list" here...
liist = modify_list(list)
end
use_list(list)
...obviously, this is a seriously contrived example but it should
clarify my point. I so amazingly meant to assign to the pre-existing
variable "list" but I accidentally created a new variable. It's not even
typos with me. I often thought I named a variable something descriptive
when I actually named it something else equally descriptive. This can be a
surprisingly annoying bug to track...
A solution to my problem would be to require variable declarations.
Something like the "my" keyword of a strict PERL script. Ruby would
probably not use "my," despite its PERL roots. Maybe "var?"
var list = create_useful_list
if should_modify_list(list)
# A compile time error will occur here...
# ...after 1.9 is released...
liist = modify_list(list)
end
Quoth Just Another Victim of the Ambient Morality:
A solution to my problem would be to require variable declarations.
Something like the "my" keyword of a strict PERL script. Ruby would
probably not use "my," despite its PERL roots. Maybe "var?"
var list = create_useful_list
if should_modify_list(list)
# A compile time error will occur here...
# ...after 1.9 is released...
liist = modify_list(list)
end
Lots of hardcore wincing going on in my spleen now.
Just Another Victim of the Ambient Morality wrote:
...obviously, this is a seriously contrived example but it should clarify my point. I so amazingly meant to assign to the pre-existing variable "list" but I accidentally created a new variable. It's not even typos with me. I often thought I named a variable something descriptive when I actually named it something else equally descriptive. This can be a surprisingly annoying bug to track...
How are you testing your code?
···
--
James Britt
"You harmonize; then you customize."
- Wilson Pickett
So, I had a conversation with a colleague of mine and he brought up a
feature request for another language that is a lot like Ruby but is not
Ruby. It was an interesting request and, after I had thought about it a
bit, I discovered that I would like this feature, too!
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
def some_method(a,b,c)
contract_for_some_method(a,b,c) if $DEBUG
...
end
def contract_for_some_method(a,b,c)
raise ArgumentError unless a.is_a?(Foo)
raise ArgumentError unless b.is_a?(Bar)
raise ArgumentError unless c.is_a?(Baz)
# or whatever
end
2) Accidentally creating a new variable.
Unfortunately for me, very little can be done about my first point. I
understand and enjoy the power of duck-typing, which specifically allows me
to exercise this bug.
However, something can be done about the second point. Let me exemplify
the problem:
list = create_useful_list
if should_modify_list(list)
# I meant to modify the variable "list" here...
liist = modify_list(list)
end
use_list(list)
...obviously, this is a seriously contrived example but it should
clarify my point. I so amazingly meant to assign to the pre-existing
variable "list" but I accidentally created a new variable. It's not even
typos with me. I often thought I named a variable something descriptive
when I actually named it something else equally descriptive. This can be a
surprisingly annoying bug to track...
A solution to my problem would be to require variable declarations.
Something like the "my" keyword of a strict PERL script. Ruby would
probably not use "my," despite its PERL roots. Maybe "var?"
var list = create_useful_list
if should_modify_list(list)
# A compile time error will occur here...
# ...after 1.9 is released...
liist = modify_list(list)
end
use_list(list)
What do you all think?
Thank you...
Why do you have troubles like this? How big are your methods? Keep
them small and this, I think, would be very rare.
The most annoying bug I ever have is tracking an errant "end".
T.
···
On Dec 8, 7:55 pm, "Just Another Victim of the Ambient Morality" <ihates...@hotmail.com> wrote:
A solution to my problem would be to require variable declarations.
Something like the "my" keyword of a strict PERL script. Ruby would
probably not use "my," despite its PERL roots. Maybe "var?"
I think it would be useful especially for people coming to ruby from
non case sensitive languages. I certainly don't see any harm in
setting up something like strict. If you don't want to use it you
don't have to.
So, I had a conversation with a colleague of mine and he brought up a
feature request for another language that is a lot like Ruby but is not
Ruby. It was an interesting request and, after I had thought about it a
bit, I discovered that I would like this feature, too!
Hum. Why don't you try comp.lang.ruby.like.but.not.ruby instead? I
hear it's "phat."
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
2) Accidentally creating a new variable.
Seriously, as someone prone to lack of concentration, I agree. A
great many programmers have concluded, probably from painful
experience, that typed variables reduce error. Also I think that
building error-testing into the code will scale better than reliance
only on unit testing.
1). I'm not yet convinced that some kind of sophisticated DBC thing
amenable to duckies can't be created.
2) would be helpful, but it may be a mistake to insist on a keyword.
I think we should concentrate on putting everything that can be into a
DUIIYDLI module ('Don't use it if you don't like it'). Then the
skeptics can't complain.
-Jonathan
···
On Dec 8, 7:51 pm, "Just Another Victim of the Ambient Morality" <ihates...@hotmail.com> wrote:
I suspect that both #1 and #2 are because you're not doing TDD/BDD.
When I first came to Ruby from statically-typed languages, I had exactly
the same problem, for exactly that reason. I *constantly* made typos.
Then I started playing with RSpec, and writing all my specs first, and -
magically - all those types of bugs disappeared (or, rather, were caught
the minute I clicked "save", thanks to ZenTest's autotest).
The proof, to me, was that I've recently been on a contract that took me
back to PL/I - one of the more restrictive statically-typed languages.
Wouldn't you know it: Nearly every time I tried to compile, I found at
least one mistyped variable name.
Go figure.
···
On Sun, 09 Dec 2007 00:51:17 GMT, Just Another Victim of the Ambient Morality wrote:
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
2) Accidentally creating a new variable.
Unfortunately for me, very little can be done about my first point. I
understand and enjoy the power of duck-typing, which specifically allows me
to exercise this bug.
However, something can be done about the second point. Let me exemplify
the problem:
--
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
var l = [1,2,3]
var h = {:a=>"b"}
wants_an_array(h) # => error
2.) While that may alleviate the typo problem, it introduces another
class of bugs which are just as subtle:
var list = create_useful_list
if should_modify_list(list)
# I meant to modify the variable "list" here...
var list = modify_list(list)
end
use_list(list)
Once one became accustomed to typing "var", there is every chance that
it would be used places where a pre-existing variable was meant, but
the "var" just got typed out of habit.
Regards,
Jordan
···
On Dec 8, 6:51 pm, "Just Another Victim of the Ambient Morality" <ihates...@hotmail.com> wrote:
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
2) Accidentally creating a new variable.
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
2) Accidentally creating a new variable.
I agree with number 1. I like duck typing and respect it, but I have
seriously thought of suggesting 'voluntary' type checks to Ruby before,
since it is a very common problem to pass a String instead of an
Integer.
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.
-Roger
Once you make something like that optional it has a way of becoming
mandatory in a cultural sense. Go ahead, write a Perl program without
strict and try to get Perl community support. You'll be berated (and
probably insulted) within 2 seconds.
No, the solution is to stop writing monolithic top-down scripts where
you can trip yourself up with such a mistake and/or write tests that
would catch something so simple anyway. In all the years I've
programmed in Ruby I have never been bitten by the lack of strict
variable declaration.
Where it *can* be an issue is with instance variables. However, those
are easily smoked out when you run with -w. You *do* run your tests
with warnings on, right. Yes, of course you do.
Regards,
Dan
PS - I've suggested to Jim that warnings be turned on by default for
test tasks in Rake.
···
On Dec 9, 3:27 am, "Tim Uckun" <timuc...@gmail.com> wrote:
> A solution to my problem would be to require variable declarations.
> Something like the "my" keyword of a strict PERL script. Ruby would
> probably not use "my," despite its PERL roots. Maybe "var?"
I think it would be useful especially for people coming to ruby from
non case sensitive languages. I certainly don't see any harm in
setting up something like strict. If you don't want to use it you
don't have to.
So, I had a conversation with a colleague of mine and he brought up a
feature request for another language that is a lot like Ruby but is not
Ruby. It was an interesting request and, after I had thought about it a
bit, I discovered that I would like this feature, too!
Hum. Why don't you try comp.lang.ruby.like.but.not.ruby instead? I
hear it's "phat."
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
2) Accidentally creating a new variable.
Seriously, as someone prone to lack of concentration, I agree. A
great many programmers have concluded, probably from painful
experience, that typed variables reduce error.
Item 2 above was about declared variables, not necessarily typed ones.
Also I think that
building error-testing into the code will scale better than reliance
only on unit testing.
1). I'm not yet convinced that some kind of sophisticated DBC thing
amenable to duckies can't be created.
IMHO DBC and duck typing do not mix very well because DBC takes away the flexibility which is one of the strengths. Fact is, apparently there are people who are able to write complex applications in Ruby - even with more smart automatisms added.
2) would be helpful, but it may be a mistake to insist on a keyword.
I think we should concentrate on putting everything that can be into a
DUIIYDLI module ('Don't use it if you don't like it'). Then the
skeptics can't complain.
That will we hard because you want the missing declaration be caught during parsing and compiling. If you put this into a module then you probably need to go back to the source and reparse it which is not always possible. I don't know how Perl does it but frankly, I do not really see Perl as the ideal example to model Ruby after.
Bottom line: if you want a safer language with typed and declared variables use one. This is such a fundamental change to the language that it does not fit in very well. I also suggest to keep methods short. This will help improve structure of the code and avoid all sorts of other bugs as well.
Kind regards
robert
···
On 09.12.2007 16:11, Dumaiu wrote:
On Dec 8, 7:51 pm, "Just Another Victim of the Ambient Morality" > <ihates...@hotmail.com> wrote:
Just Another Victim of the Ambient Morality wrote:
> 1) Passing the wrong object as a parameter to a method.
Do you mean object or type here? Checking the type is easy if you need to.
irb(main):001:0> "hello".type
(irb:1): warning: Object#type is deprecated: use Object#class
=> String
You can tell the "type" how exactly? This is a simple example of
semantics, but what's really important for newbies to understand is
that there is no such thing as "type".
> 2) Accidentally creating a new variable.
This is a danger that will plague any language, IMO.
Since I started using NetBeans, I would say this is a non-issue now.
That editor is pretty intelligent when it comes to spotting typos in
Ruby code.
Best regards,
Jari Williamsson
Todd
···
On Dec 9, 2007 10:40 AM, Jari Williamsson <jari.williamsson@mailbox.swipnet.se> wrote:
Just Another Victim of the Ambient Morality wrote:
> 1) Passing the wrong object as a parameter to a method.
Do you mean object or type here? Checking the type is easy if you need to.
The problem as I see it is that it's too easy; it comes off as
lazy. The argument for duck typing, valid, is that you should never
really need to. Object#respond_to?() is considered better but not
perfect.
> 2) Accidentally creating a new variable.
Since I started using NetBeans, I would say this is a non-issue now.
That editor is pretty intelligent when it comes to spotting typos in
Ruby code.
That's an interesting point, the IDE argument. Although I'm
partial to Vim, I guess trying new things is usually a good idea.
Best regards,
Jari Williamsson
You, too.
-Jonathan
···
On Dec 9, 11:40 am, Jari Williamsson <jari.williams...@mailbox.swipnet.se> wrote:
"The most annoying bug I ever have is tracking an errant "end"."
I too often complain about missing end's.
But I was one of those coders that, in PHP, often forgot a ';'
I cant tell you how happy I am with ruby. No more need for ';'
About the missing end's, over time I kinda developed a habit of
knowing where I made an error and can fix it up quickly.
It is not really that problematic for me. HOWEVER, I would actually
not mind some magical per-file way to omit end's based on
indent. :>
This happens to me in perl, possibly about as often as the typo
problem in Ruby, possibly more. I'll note that I have a habit
intended to avoid typo problems: I fairly consistently use Vim's
"Ctrl-N" (complete based on string search in other parts of code),
even for short strings, just to avoid typos.
Eivind.
···
On Dec 10, 2007 12:10 PM, MonkeeSage <MonkeeSage@gmail.com> wrote:
2.) While that may alleviate the typo problem, it introduces another
class of bugs which are just as subtle:
var list = create_useful_list
if should_modify_list(list)
# I meant to modify the variable "list" here...
var list = modify_list(list)
end
use_list(list)
Once one became accustomed to typing "var", there is every chance that
it would be used places where a pre-existing variable was meant, but
the "var" just got typed out of habit.
"James Britt" <james.britt@gmail.com> wrote in message
news:475B7171.4010601@gmail.com...
Just Another Victim of the Ambient Morality wrote:
...obviously, this is a seriously contrived example but it should
clarify my point. I so amazingly meant to assign to the pre-existing
variable "list" but I accidentally created a new variable. It's not even
typos with me. I often thought I named a variable something descriptive
when I actually named it something else equally descriptive. This can be
a
surprisingly annoying bug to track...
"Trans" <transfire@gmail.com> wrote in message
news:2d146480-3006-421a-9204-153fce5cf3c8@e23g2000prf.googlegroups.com...
So, I had a conversation with a colleague of mine and he brought up a
feature request for another language that is a lot like Ruby but is not
Ruby. It was an interesting request and, after I had thought about it a
bit, I discovered that I would like this feature, too!
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
def some_method(a,b,c)
contract_for_some_method(a,b,c) if $DEBUG
...
end
def contract_for_some_method(a,b,c)
raise ArgumentError unless a.is_a?(Foo)
raise ArgumentError unless b.is_a?(Bar)
raise ArgumentError unless c.is_a?(Baz)
# or whatever
end
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...
2) Accidentally creating a new variable.
Unfortunately for me, very little can be done about my first point.
I
understand and enjoy the power of duck-typing, which specifically allows
me
to exercise this bug.
However, something can be done about the second point. Let me
exemplify
the problem:
list = create_useful_list
if should_modify_list(list)
# I meant to modify the variable "list" here...
liist = modify_list(list)
end
use_list(list)
...obviously, this is a seriously contrived example but it should
clarify my point. I so amazingly meant to assign to the pre-existing
variable "list" but I accidentally created a new variable. It's not even
typos with me. I often thought I named a variable something descriptive
when I actually named it something else equally descriptive. This can be
a
surprisingly annoying bug to track...
A solution to my problem would be to require variable declarations.
Something like the "my" keyword of a strict PERL script. Ruby would
probably not use "my," despite its PERL roots. Maybe "var?"
var list = create_useful_list
if should_modify_list(list)
# A compile time error will occur here...
# ...after 1.9 is released...
liist = modify_list(list)
end
use_list(list)
What do you all think?
Thank you...
Why do you have troubles like this? How big are your methods? Keep
them small and this, I think, would be very rare.
They're not that big. Having said that, it's often hard to keep a
method definition too small 'cause, well, sometimes there's a lot to do!
Sometimes there's a lot to do that's inherently related and splitting that
up would serve no logical purpose other than to keep the method definition
small. Finally, I've actually worked with entire programs where no function
body was more than six lines of code. It wasn't understandable nor easy to
work with. It was extremely difficult to tell what any function did and it
was difficult to modify code to do something else. I don't think
artificially keeping method definitions small necessarily solves anything...
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...
···
On Dec 8, 7:55 pm, "Just Another Victim of the Ambient Morality" > <ihates...@hotmail.com> wrote:
"Dumaiu" <Dymaio@gmail.com> wrote in message
news:399c73dc-226e-4e6c-bda5-37104b24dd16@v4g2000hsf.googlegroups.com...
So, I had a conversation with a colleague of mine and he brought up a
feature request for another language that is a lot like Ruby but is not
Ruby. It was an interesting request and, after I had thought about it a
bit, I discovered that I would like this feature, too!
Hum. Why don't you try comp.lang.ruby.like.but.not.ruby instead? I
hear it's "phat."
The two most popular sources of bugs for me when programming in Ruby
are:
1) Passing the wrong object as a parameter to a method.
2) Accidentally creating a new variable.
Seriously, as someone prone to lack of concentration, I agree. A
great many programmers have concluded, probably from painful
experience, that typed variables reduce error. Also I think that
building error-testing into the code will scale better than reliance
only on unit testing.
I actually don't think this is the case. Statically typed languages
didn't come from long experience with bugs, it was just happenstance...
If I'm not mistaken, typed variables came from a world where compiled
programming languages failed to completely shield the user from the
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...
···
On Dec 8, 7:51 pm, "Just Another Victim of the Ambient Morality" > <ihates...@hotmail.com> wrote:
