Bug in ruby?

ruby-talk
1

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

Let's see my code first:

[code]def parse(string, starting, ending)
        istart = string.index(starting) + starting.length
        iend = string.index(ending, istart)
        return string.slice(istart, iend - istart)
    end[/code]

This function is called about 13 times in my entire script. It breaks on
the last one with this error:

undefined method `+' for nil:NilClass

Now, I have debugged the living hell out of this application. It's
breaking on the first line, stating that starting.length is a nil object
and that it can't perform a + operator in a nil object. The string
that's getting passed into starting is:

buy_item.phtml?

I debugged the application and put a mark on the first line to examine
it in the following code:

[code]def parse(string, starting, ending)
        length = starting.length
        istart = string.index(starting) + length
        iend = string.index(ending, istart)
        return string.slice(istart, iend - istart)
    end[/code]

And the debugger said that length was an int with the value of 15. Guess
what still happened? Got the exact same error with the + operator on a
nil object. Except that completely contradicts the fact that it's not
nil but it's an int with the value of 15.

I have spent the last hour trying hundreds of different forms of this
code and am getting the same exact error every time. I've come to the
conclusion that this must be some kind of bug in Ruby, I can not pull on
piece of logical evidence out of this.

So my last resort is you guru's here, what am I doing wrong? Is there
some kind of magical law I broke? This application needs to get done
tonight, and I really can't afford anymore time on this tiny little bug.
Thanks in advanced.

~ Alias

···

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

2

Wouldn't it be string.index() that is Nil here:

    string.index(starting).+(starting.length)

starting.length is a parameter to the '+' method being called on the
result of index().

···

On 11/20/06, AliasX Neo <kamipride102@gmail.com> wrote:

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

Let's see my code first:

[code]def parse(string, starting, ending)
        istart = string.index(starting) + starting.length
        iend = string.index(ending, istart)
        return string.slice(istart, iend - istart)
    end[/code]

This function is called about 13 times in my entire script. It breaks on
the last one with this error:

undefined method `+' for nil:NilClass

Now, I have debugged the living hell out of this application. It's
breaking on the first line, stating that starting.length is a nil object
and that it can't perform a + operator in a nil object. The string
that's getting passed into starting is:

3

AliasX Neo wrote:

Well, I've spent the last hour or so debugging one of the stupidest errors I have encountered with Ruby.

<snip>

I debugged the application and put a mark on the first line to examine it in the following code:

[code]def parse(string, starting, ending)
        length = starting.length
        istart = string.index(starting) + length
        iend = string.index(ending, istart)
        return string.slice(istart, iend - istart)
    end[/code]

And the debugger said that length was an int with the value of 15. Guess what still happened? Got the exact same error with the + operator on a nil object. Except that completely contradicts the fact that it's not nil but it's an int with the value of 15.
  
+ is being called on string.index(starting) not length. I'd check to make sure you aren't getting nil from that:

def parse(string, starting, ending)
  p string.index(starting)
        istart = string.index(starting) + length
        iend = string.index(ending, istart)
        return string.slice(istart, iend - istart)
end

Hope that helps.

-Justin

4

This is a subject line that's mildly infuriating. I wonder if I can
recall more than three threads of that name that actually were a bug in
Ruby after all in the past year, and the one that's in living memory was
from Ara, and (unsurprisingly) a very subtle issue where it took me
three reads to find out why it's wrong behaviour in the first place, not
a "method not working at all" issue.

If you're not a syntax lawyer, and / or haven't checked the
documentation for what you're using a code snippet in the first place,
I'd say odds are good it's a bug in your code due to some (maybe not
really) gotcha you overlooked. And in that case it would be better to
present a problem as such, and providing a more informative subject line
to boot.

Also:

def parse(string, start, ending)
string.match(/#{Regexp.escape(start)}.*(?=#{Regexp.escape(ending)}/)[0]
end

David Vallner

5

        istart = string.index(starting) + starting.length

[...]

undefined method `+' for nil:NilClass

Other people have said this, but just to put it explicitly:

Ruby has a message-passing object model - every operation consists of
a message sent to an object. Thus, there are no symmetrical operations
- even binary operations like + translate internally to one object
being sent to the other as part of a "+" message. Indeed, you could
even write the above as

istart = string.index.starting.+(starting.length)

to make it explicit that there's a method call going on under the hood.

One consequence of this is that when an exception or error is thrown,
it is thrown from the context of the receiving object. Thus "undefined
method `+' for nil:NilClass" means you have attempted to call
nil.+(something), not something.+(nil). That should help greatly in
debugging stuff.

martin

···

On 11/21/06, AliasX Neo <kamipride102@gmail.com> wrote:

6

AliasX Neo wrote:

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

It is a stupid error, but to say it diplomatically, the responsibility
assignment is flawed.

/ ...

I have spent the last hour trying hundreds of different forms of this
code

Except the one shown below.

and am getting the same exact error every time. I've come to the
conclusion that this must be some kind of bug in Ruby, I can not pull on
piece of logical evidence out of this.

That is because you are not thinking hard enough.

So my last resort is you guru's here, what am I doing wrong?

You are not breaking the problem down sufficiently. As others have
commented, there are two operands for "+" and you have only looked at one
of them.

Do this:

length = starting.length
si = string.index(starting)
if(length != nil && si != nil)
  istart = si + length
end

Is there some kind of magical law I broke?

Yes, as a matter of fact, there is. You assumed there was a flaw in the
language before exhausting the more obvious possibility that the error is
your own.

This application needs to get done
tonight, and I really can't afford anymore time on this tiny little bug.

Famous last words.

···

--
Paul Lutus
http://www.arachnoid.com

7

"AliasX Neo" <kamipride102@gmail.com> wrote in message
news:86904d117a12656ca6e35c32fd8bcbe0@ruby-forum.com...

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

Let's see my code first:

[code]def parse(string, starting, ending)
       istart = string.index(starting) + starting.length
       iend = string.index(ending, istart)
       return string.slice(istart, iend - istart)
   end[/code]

This function is called about 13 times in my entire script. It breaks on
the last one with this error:

undefined method `+' for nil:NilClass

    Just out of wild curiosity, did you ever figure this thing out? We're
very eager to learn of bugs in Ruby so they may be fixed although it really
looks like this was your error. Surely, it's not outrageous to think that
string.index(starting) can return nil. Was this the case for you?
    Thank you...

8

AliasX Neo wrote:
> Well, I've spent the last hour or so debugging one of the stupidest
> errors I have encountered with Ruby.
>
<snip>
> I debugged the application and put a mark on the first line to examine
> it in the following code:
>
> [code]def parse(string, starting, ending)
> length = starting.length
> istart = string.index(starting) + length
> iend = string.index(ending, istart)
> return string.slice(istart, iend - istart)
> end[/code]
>
> And the debugger said that length was an int with the value of 15. Guess
> what still happened? Got the exact same error with the + operator on a
> nil object. Except that completely contradicts the fact that it's not
> nil but it's an int with the value of 15.
>

+ is being called on string.index(starting) not length. I'd check to
make sure you aren't getting nil from that:

which is expected behavior
http://www.ruby-doc.org/core/classes/String.html#M000805
cheers
Robert

def parse(string, starting, ending)

···

On 11/21/06, Justin Collins <collinsj@seattleu.edu> wrote:

        p string.index(starting)
        istart = string.index(starting) + length
        iend = string.index(ending, istart)
        return string.slice(istart, iend - istart)
end

Hope that helps.

-Justin

--
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.

- George Bernard Shaw

9

David Vallner wrote:

This is a subject line that's mildly infuriating. I wonder if I can
recall more than three threads of that name that actually were a bug in
Ruby after all in the past year, and the one that's in living memory was
from Ara, and (unsurprisingly) a very subtle issue where it took me
three reads to find out why it's wrong behaviour in the first place, not
a "method not working at all" issue.

If you're not a syntax lawyer, and / or haven't checked the
documentation for what you're using a code snippet in the first place,
I'd say odds are good it's a bug in your code due to some (maybe not
really) gotcha you overlooked. And in that case it would be better to
present a problem as such, and providing a more informative subject line
to boot.

Also:

def parse(string, start, ending)
string.match(/#{Regexp.escape(start)}.*(?=#{Regexp.escape(ending)}/)[0]
end

David Vallner

There have been many that I thought were "bugs in Ruby", though mainly in the error message produced rather than that the code should have done what the person objecting thought it should have done.

I'll grant that good error messages are a hard problem, but I frequently find them totally exasperating. E.g., if a loop isn't properly closed, the error message should point to where it started rather than several lines after the end of the program. (Well, perhaps this one's been fixed. I don't remember encountering it recently. But if it hasn't been, I consider it a bug in Ruby.)

In this case the bug was in the message not stating which variable had a nil value. You may not think of it as serious, but he reports spending several hours on it, and I'd call that a bug.

Remember, Ruby is being recommended to total neophytes as a good language to start with. That means that good diagnostic error messages are essential!

10

So, how'd it go? Was it finished in time and under budget? :slight_smile:

···

On 2006-11-21, Paul Lutus <nospam@nosite.zzz> wrote:

AliasX Neo wrote:

...

This application needs to get done
tonight, and I really can't afford anymore time on this tiny little bug.

Famous last words.

--

11

It's not only not outrageous - if one reads the spec., it's obvious:

----------------------------------------------------------- String#index
     str.index(substring [, offset]) => fixnum or nil
     str.index(fixnum [, offset]) => fixnum or nil
     str.index(regexp [, offset]) => fixnum or nil

···

On 2006-11-22, Just Another Victim of the Ambient Morality <ihatespam@hotmail.com> wrote:

"AliasX Neo" <kamipride102@gmail.com> wrote in message
news:86904d117a12656ca6e35c32fd8bcbe0@ruby-forum.com...

Well, I've spent the last hour or so debugging one of the stupidest
errors I have encountered with Ruby.

Let's see my code first:

[code]def parse(string, starting, ending)
       istart = string.index(starting) + starting.length
       iend = string.index(ending, istart)
       return string.slice(istart, iend - istart)
   end[/code]

This function is called about 13 times in my entire script. It breaks on
the last one with this error:

undefined method `+' for nil:NilClass

    Just out of wild curiosity, did you ever figure this thing out? We're
very eager to learn of bugs in Ruby so they may be fixed although it really
looks like this was your error. Surely, it's not outrageous to think that
string.index(starting) can return nil. Was this the case for you?

------------------------------------------------------------------------
     Returns the index of the first occurrence of the given _substring_,
     character (_fixnum_), or pattern (_regexp_) in _str_. Returns +nil+
     if not found. If the second parameter is present, it specifies the
     position in the string to begin the search.

        "hello".index('e') #=> 1
        "hello".index('lo') #=> 3
        "hello".index('a') #=> nil
        "hello".index(101) #=> 1
        "hello".index(/[aeiou]/, -3) #=> 4

--

12

I have also previously requested that this get fixed in a future Ruby.
It's very annoying to try and guess which could be the offending
variable in a complex expression, and it wastes a lot of time. It
would surely be very easy for Ruby to say which variable was nil.

In some of my latest scripts I have this:

def preventNil(*args)
  args.each_with_index do |arg, i|
    raise ArgumentError.new("argument #{i} cannot be nil") if arg.nil?
  end
end

class StatSaver
  def initialize(vehicle, column, dataSet, log)

    preventNil(vehicle, column, dataSet, log)

    @vehicleID = vehicle.VehicleID
    @column = column
    @dataSet = dataSet
    @log = log
  end

...

...as a kind of firebreak contract to prevent nil's from failures in
completely unrelated places causing other code to fall over. You don't
always realise that a certain method might return nil.

I'd be interested to hear if there are nicer solutions to this problem.

Les

···

On 11/21/06, Charles D Hixson <charleshixsn@earthlink.net> wrote:

David Vallner wrote:
> This is a subject line that's mildly infuriating. I wonder if I can
> recall more than three threads of that name that actually were a bug in
> Ruby after all in the past year, and the one that's in living memory was
> from Ara, and (unsurprisingly) a very subtle issue where it took me
> three reads to find out why it's wrong behaviour in the first place, not
> a "method not working at all" issue.
>
> If you're not a syntax lawyer, and / or haven't checked the
> documentation for what you're using a code snippet in the first place,
> I'd say odds are good it's a bug in your code due to some (maybe not
> really) gotcha you overlooked. And in that case it would be better to
> present a problem as such, and providing a more informative subject line
> to boot.
>
> Also:
>
> def parse(string, start, ending)
> string.match(/#{Regexp.escape(start)}.*(?=#{Regexp.escape(ending)}/)[0]
> end
>
> David Vallner
>
There have been many that I thought were "bugs in Ruby", though mainly
in the error message produced rather than that the code should have done
what the person objecting thought it should have done.

I'll grant that good error messages are a hard problem, but I frequently
find them totally exasperating. E.g., if a loop isn't properly closed,
the error message should point to where it started rather than several
lines after the end of the program. (Well, perhaps this one's been
fixed. I don't remember encountering it recently. But if it hasn't
been, I consider it a bug in Ruby.)

In this case the bug was in the message not stating which variable had a
nil value. You may not think of it as serious, but he reports spending
several hours on it, and I'd call that a bug.

Remember, Ruby is being recommended to total neophytes as a good
language to start with. That means that good diagnostic error messages
are essential!

13

Charles D Hixson wrote:

In this case the bug was in the message not stating which variable had a
nil value. You may not think of it as serious, but he reports spending
several hours on it, and I'd call that a bug.

I'm not aware of a programming language that DOES report this. Remember
that a nil value can come out of a fairly complex expression instead of
a single variable, and that nil can have many variables bound to it at a
given moment. The bug was in the OP's code, plain and simple, it's not
the responsibility of the programming language to do in-depth diagnosis
of dangling pointer problems.

Also, in the OP, the error message was consistent to Ruby's semantics -
a NoMethodError on nil usually significates what a NPE in Java,
NullRefError in C#, or segfault in C would be. Since the undefined
method was #+, the culprit was the expression that a method of that name
was called on in that code snippet.

Ruby reported what happened consistently with its computation model
(failed method lookup, nil being a regular object), and where it
happened (with no less detail than any other programming language I've
worked with reports on null pointers).

Further diagnostics (why it could have possibly happened) is the role of
a static code analysis tool; since it's sooner or later guesswork it's
not the task of the interpreter itself.

Coding defensively and using sanity checks on the return value of #index
and other methods that may return nil would also have helped.

Remember, Ruby is being recommended to total neophytes as a good
language to start with. That means that good diagnostic error messages
are essential!

As is learning the syntax rules and how to read the error messages.

Also, whoever makes that recommendation is a fool, and I'm not
responsible for him making that wrong recommendation. AFAIK, the Ruby
language presumes the programmer is a grownup, and there's a LOT of
running with scissors involved. The simplicity makes it easy to pickup,
but in my opinion it gets very difficult to hobble along with only basic
knowledge and get something working done as the emergent behaviours
"noone tells you about" bite you if you don't either delve deeper into
how stuff works to avoid those errors, or get a broader overview of
what's available to end up writing less code (e.g. replacing futzing
around with substrings with a RE.)

David Vallner

14

I'll grant that good error messages are a hard problem, but I frequently find them totally exasperating. E.g., if a loop isn't properly closed, the error message should point to where it started rather than several lines after the end of the program. (Well, perhaps this one's been fixed. I don't remember encountering it recently. But if it hasn't been, I consider it a bug in Ruby.)

Have you thought through how this might work? It seems the obvious
solution may not generate useful information. See for ex:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/209336

Regards,

Bill

···

From: "Charles D Hixson" <charleshixsn@earthlink.net>

15

Charles D Hixson wrote:

/ ...

I'll grant that good error messages are a hard problem, but I frequently
find them totally exasperating. E.g., if a loop isn't properly closed,
the error message should point to where it started rather than several
lines after the end of the program.

But the interpreter cannot do that without reading the programmer's mind.
Maybe the programmer intended to complete the loop in some code, not yet
written, that extends beyond the present end of the program. The evidence
is that the interpreter's scanner ended up at the end of the file, still
happy with the syntax up to that point.

(Well, perhaps this one's been
fixed. I don't remember encountering it recently. But if it hasn't
been, I consider it a bug in Ruby.)

It is not a bug in Ruby if the incomplete loop could in principle continue
beyond EOF.

In this case the bug was in the message not stating which variable had a
nil value. You may not think of it as serious, but he reports spending
several hours on it, and I'd call that a bug.

It is not a bug, at least, not in Ruby. At the point at which the error
condition arises, the '+' method doesn't know the names of the variables
that produced its inputs, it only knows that one of them is nil. Remember
that this is a runtime error.

And the OP used a debugger but still didn't realize there was a possibility
he hadn't considered. This is not something any finite-sized language can
possibly deal with.

Also remember: in an interpreted language, every increase in hand-holding
runtime comprehensiveness decreases execution speed.

Remember, Ruby is being recommended to total neophytes as a good
language to start with. That means that good diagnostic error messages
are essential!

It also means that, as in all computer programming for all time, neophytes
have to pay attention to details.

The single most difficult part of learning how to program is to fully grasp
how simple-minded computers actually are. Successful programmers know
exactly how a computer will react to their code. Learning this, reducing it
to a matter of instinct, takes time.

···

--
Paul Lutus
http://www.arachnoid.com

16

Jim Cochrane wrote:

AliasX Neo wrote:

...

This application needs to get done
tonight, and I really can't afford anymore time on this tiny little bug.

Famous last words.

So, how'd it go? Was it finished in time and under budget? :slight_smile:

I think the OP is a student, in any case someone who isn't that into
programming as recreation.

Professionals don't conceptualize program flaws as "this tiny little bug".
There is no such thing. All the tiny little bugs that weren't so tiny ...
the one that disabled a US Navy destroyer running NT (after someone entered
a zero into a user-level application and precipitated a divide-by-zero
error that brought down the entire network), which then drifted out of
control as the sailor geeks tried to restart the network. The bug that
caused the Airbus to fly into the trees during an air show low pass
(passengers on board).

The microcode bug that caused Intel processors to produce incorrect math
results, and damaged their reputation for a while.

The bug that cause Mars Polar Explorer to prematurely shut down its engine
and fall the last 100 meters to the surface of Mars, never to be heard from
again.

"Tiny little bug." No such thing.

···

On 2006-11-21, Paul Lutus <nospam@nosite.zzz> wrote:

--
Paul Lutus
http://www.arachnoid.com

17

Leslie Viljoen wrote:

It's very annoying to try and guess which could be the offending
variable in a complex expression, and it wastes a lot of time. It
would surely be very easy for Ruby to say which variable was nil.

Meet my good friends, local variable, and return value checking. You'll
get along great once you get to know each other.

Also, see previous post. At any given point in time, there's several
variables that point to nil in the interpreter, and the culprit is also
usually an expression. Finding the possible expressions that returned a
nil would require tracing back to the literal in the stack frames, and
even then the last one wouldn't have to be the cause of the problem. I
stand by my point that this is not the job of a core language runtime,
but of manual or automated code review.

David Vallner

18

Bill Kelly wrote:

From: "Charles D Hixson" <charleshixsn@earthlink.net>

I'll grant that good error messages are a hard problem, but I frequently find them totally exasperating. E.g., if a loop isn't properly closed, the error message should point to where it started rather than several lines after the end of the program. (Well, perhaps this one's been fixed. I don't remember encountering it recently. But if it hasn't been, I consider it a bug in Ruby.)

Have you thought through how this might work? It seems the obvious
solution may not generate useful information. See for ex:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/209336

Regards,

Bill

I admitted it was a hard problem ... but, well,...

if functions are defined, and begins/ends balance within them, it probably happened before or after that. Not guaranteed, as there might be internal functions, but probable. If it's an end that is missing (usual case) start parsing from inner constructs out. Etc.

(FWIW, I normally comment my ends thusly:
    end # initialize
for just this reason. With Ruby syntax it is a REALLY hard problem. When this has occurred a few times I start really agreeing with the languages that do things like "end if" or "end def".)

OTOH, it's also true that by compiling every time I enter a new definition I can generally handle this error with minimal problems .... but it would be a lot easier to include sufficient context markers to ensure localization of errors.

19

Charles D Hixson wrote:
> In this case the bug was in the message not stating which variable had a
> nil value. You may not think of it as serious, but he reports spending
> several hours on it, and I'd call that a bug.

This is one of the things I find irritating as well. Normally Ruby
is rightly praised for not getting in the way of productivity, but
this really does force one to program to meet constraints which are
not actually part of the language as such.

>

I'm not aware of a programming language that DOES report this. Remember

Some other languages report things differently....
        [...]

NullRefError in C#, or segfault in C would be. Since the undefined
method was #+, the culprit was the expression that a method of that name
was called on in that code snippet.

...but in many conventionally constructed arithmetic expressions there
will be more than one plus sign. Some languages use an arrow
        
        y = (a * x**3) + (b * x * x) + (c * x) + d
                       ^

···

On Wed, 22 Nov 2006, David Vallner wrote:
                       >
-----------------------+

or similar. Evidence? The %p construct in vim errorformats
in compiler files for handling error messages, which uses
the arrow to pick up the column:

/usr/local/share/vim/vim70/compiler/ant.vim: \%A\ %#[%.%#]\ %f:%l:\ %m,%-Z\ %#[%.%#]\ %p^,%C\ %#[%.%#]\ %#%m
/usr/local/share/vim/vim70/compiler/bdf.vim: \%-Z%p^,
/usr/local/share/vim/vim70/compiler/eruby.vim: \%-Z%p^,
/usr/local/share/vim/vim70/compiler/fortran_cv.vim: \%-Z%p%^%.%#,
/usr/local/share/vim/vim70/compiler/fortran_elf90.vim: \%C%p\|,
/usr/local/share/vim/vim70/compiler/fortran_g77.vim: \%-C\ \ \ %p%*[0123456789^]%.%#,
/usr/local/share/vim/vim70/compiler/hp_acc.vim: \%Z\ \ \ \ %p^%.%#,
/usr/local/share/vim/vim70/compiler/icc.vim:CompilerSet errorformat=%-Z%p^,%f(%l):\ remark\ #%n:%m,%f(%l)\ :\ (col.\ %c)\ remark:\ %m,%E%f(%l):\ error:\ %m,%E%f(%l):\ error:\ #%n:\ %m,%W%f(%l):\ warning\ #%n:\ %m,%W%f(%l):\ warning:\ %m,%-C%.%#
/usr/local/share/vim/vim70/compiler/intel.vim: \%-Z\ \ %p^,
/usr/local/share/vim/vim70/compiler/irix5_c.vim: \%-Z\ %p^,
/usr/local/share/vim/vim70/compiler/irix5_cpp.vim: \%-Z\ \ %p%^,
/usr/local/share/vim/vim70/compiler/javac.vim:CompilerSet errorformat=%E%f:%l:\ %m,%-Z%p^,%-C%.%#,%-G%.%#
/usr/local/share/vim/vim70/compiler/mips_c.vim: \%-Z\ \ %p^,
/usr/local/share/vim/vim70/compiler/mipspro_c89.vim: \%-Z%p%^,
/usr/local/share/vim/vim70/compiler/mipspro_cpp.vim: \%-Z\ \ %p^,
/usr/local/share/vim/vim70/compiler/ruby.vim: \%-Z%p^,
/usr/local/share/vim/vim70/compiler/xmllint.vim: \%-Z%p^,

So it looks like Ruby does this occasionally itself.

        [...]

Further diagnostics (why it could have possibly happened) is the role of
a static code analysis tool; since it's sooner or later guesswork it's

Which doesn't apply in dynamic languages like Ruby where method creation
on the fly is the norm (attr_accessor, method_missing, and more).

not the task of the interpreter itself.

Coding defensively and using sanity checks on the return value of #index
and other methods that may return nil would also have helped.

This doesn't mean that is is undesirable that Ruby do more. This is
shifting the burden from the developers of ruby to the many users
of it. Not to suggest that the developers have all the time in the
world, but to say that more people are affected by not having this than
are affected by having to implement it.

Now, I would be the first to say that writing parsers is not easy.
I have tried on a number of occasions, and frankly, I am rubbish at
it. Given the constraints imposed by YACC on the future of the
language (see other threads in the past) I suspect that moving to
some other parser may be helpful. But the point of this post is
that there is evidence from other languages that it is possible for
Ruby to be more helpful, there is a desire among its users that it
be more helpful. The next question, which I can't answer given my
weaknesses in this area, is: how can this be improved? Or,
conversely, can it be shown that improving it would be detrimental
to Ruby in some important way?

We know Ruby is excellent. That's why we'd like it to be even better.
        
        Hugh

20

Jim Cochrane wrote:

AliasX Neo wrote:

...

This application needs to get done
tonight, and I really can't afford anymore time on this tiny little bug.

Famous last words.

So, how'd it go? Was it finished in time and under budget? :slight_smile:

I think the OP is a student, in any case someone who isn't that into
programming as recreation.

Yes, that's pretty apparent - I was being jocular, or perhaps,
facetious. :slight_smile:

Professionals don't conceptualize program flaws as "this tiny little bug".

You would hope not, but from what I've seen in the industry, I'd not be
surprised to hear about such a statement.

There is no such thing. All the tiny little bugs that weren't so tiny ...
the one that disabled a US Navy destroyer running NT (after someone entered
a zero into a user-level application and precipitated a divide-by-zero
error that brought down the entire network), which then drifted out of
control as the sailor geeks tried to restart the network. The bug that
caused the Airbus to fly into the trees during an air show low pass
(passengers on board).

The microcode bug that caused Intel processors to produce incorrect math
results, and damaged their reputation for a while.

Yep - famous bugs.

The bug that cause Mars Polar Explorer to prematurely shut down its engine
and fall the last 100 meters to the surface of Mars, never to be heard from
again.

Due to a missing or incorrect unit conversion, right?!

"Tiny little bug." No such thing.

Or how about the Ariane 5 (
http://www.around.com/ariane.html
). I don't remember ever hearing a description of the defect (or
defects) that caused the DIA baggage sysgtem to fail (
http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html
).

Maybe a more severe word than "bug" needs to be invented.

···

On 2006-11-22, Paul Lutus <nospam@nosite.zzz> wrote:

On 2006-11-21, Paul Lutus <nospam@nosite.zzz> wrote:

--