Sharp knives and glue

Ruby
41

On 5/4/06, James Edward G. II [email protected] wrote:

are making things up now. I’m pretty confident the order Ruby loads
code is a well defined process. Please show us some sample code.

How about this (long) example:

cat a.rb
class A; def a; “a”; end end

cat a2.rb
class A; def a; 10; end end

cat aizer.rb
require ‘a’
require ‘a2’

class B;
def b
A.new.a + 25
end
end

cat kaiser.rb
require ‘a2’
class A; def b; a + 10; end end

cat this_works.rb
require ‘aizer’
require ‘kaiser’

puts((A.new.b rescue ‘A#b failed’))
puts((B.new.b rescue ‘B#b failed’))

cat this_breaks.rb
require ‘kaiser’
require ‘aizer’

puts((A.new.b rescue ‘A#b failed’))
puts((B.new.b rescue ‘B#b failed’))

How can this be avoided?

Ilmari

42

(I was keeping out of this thread, but…)

On Thu, 2006-05-04 at 06:58 +0900, David P. wrote:

I’m sorry, but please, go back and read my posts. I love Ruby. I think
Ruby is awesome. There are parts of Ruby that need improvement. Some of
these things need to be improved/fixed before Ruby is ready to compete with
J2EE or .Net for enterprise systems. The reason I am spending a lot of time
hammering on this issue is that I believe Ruby should be the next
language/system that captures developer mindshare like Java did 10 years
ago.

How to win friends and influence people, eh? I’m sure ruby could be
improved in some ways, and I’m sure Matz will make any improvements that
fit. But ‘fixed’ is the wrong word here - if some idiot chef cuts
himself misusing a sharp knife, should the kitchen throw out all the
knives, or just the idiot chef?

Yes there is ruby-based software out there that, through careless
metaprogramming, breaks in combination with other stuff. I guess we’ve
all been bitten by a subtlety here and there. One of the benefits of
ruby is that a “very, very good programmer” like yourself can jump right
in and fix such broken software if you wish, rather than complaining
that ruby’s sharp knives are defective because they’re sharp.

43

Ross B. wrote:

One of the benefits of
ruby is that a “very, very good programmer” like yourself can jump right
in and fix such broken software if you wish, rather than complaining
that ruby’s sharp knives are defective because they’re sharp.

www.apa.org/journals/features/psp7761121.pdf

44

On Wed, May 03, 2006 at 12:33:24AM +0900, Leslie V. wrote:

everything worked again, but it took me two days to find the problem.
I must say that this worries me too, sometimes, since I have been bitten
by
this problem a few times in Perl. Although it really isn’t Ruby’s fault,
I
see a lot of example code and “ways of working” that just assume people
will
create top-level classes with the logical name.

Whenever I create programs with more than a few classes, I try to put
all of
them into one or a few “namespaces” to help prevent this. I believe you
can also
do this with Rails / active record, though I can’t recall exactly how
that workes.

In any case, yes this is a potential pitfall, and one of the things that
Java
is supposed to prevent. In my opinion the tradeoffs java makes in the
name of
“code security” aren’t worth it unless you’re working on really huge
projects,
with many programmers simultaneously, but YMMV.

On the other hand: from what I can see, some Ruby programmers and book
writers
could be a bit more careful and explicit about choosing class names and
polluting
namespaces.

Joost.

45

On 5/4/06, Ross B. [email protected] wrote:

time

hammering on this issue is that I believe Ruby should be the next
language/system that captures developer mindshare like Java did 10 years
ago.

How to win friends and influence people, eh? I’m sure ruby could be
improved in some ways, and I’m sure Matz will make any improvements that
fit. But ‘fixed’ is the wrong word here - if some idiot chef cuts
himself misusing a sharp knife, should the kitchen throw out all the
knives, or just the idiot chef?

Ruby is fine for the existing Rubyists who are willing to live with the
issues. If Ruby wants to become more that a niche language that’s
currently
getting 15 minutes of fame because of Rails, Ruby has to evolve to
support
the needs of enterprise users. Matz has taken the best from a number of
languages. Reading his slides on Ruby 2.0, it’s clear that he
understands a
lot about how Ruby has to grow and evolve. I am suggesting that there
are
other languages to look at and learn from such that Ruby > 2.0 continues
to
evolve to support the needs of larger teams building larger systems.

Yes there is ruby-based software out there that, through careless

metaprogramming, breaks in combination with other stuff. I guess we’ve
all been bitten by a subtlety here and there. One of the benefits of
ruby is that a “very, very good programmer” like yourself can jump right
in and fix such broken software if you wish, rather than complaining
that ruby’s sharp knives are defective because they’re sharp.

Perhaps you should go back and read the entirety of my posts rather than
making this statement.

My premise is that Ruby is not ready for enterprise use because the
inability to predict the behavior of programs. If one cannot predict
the
behavior of programs, one cannot test the programs. If one cannot test
the
programs, one cannot deploy the programs into environments that have
significant regulation (e.g., financial services, health care,
insurance,
etc.)

I gave as an instance of this issue, Instiki. So… let’s drill down.

  • Instiki was written by someone who was not an ‘idiot chef’ but a
    skilled Ruby programmer.
  • Instiki was written using Rails… the “way” to write web apps in
    Ruby.
  • Instiki is not a complex app (the application itself is < 2,000
    LOC).
  • Yet Instiki has somehow fallen into this issue of unpredictability
    because of the order of class loading.
  • If a non-complex Ruby app written by a skilled Ruby developer using
    standard Ruby tools breaks, how can a large company trust that a very
    complex Ruby program that has passed QA won’t fall into the same
    issue if
    the first user opens the “latest transaction” rather than the
    “account” page
    first thus causing a different order for class loads.

We can take two approaches to this issue:

  1. Not worry about and 3 years from now sit around saying, “Ruby
    coulda woulda shoulda”
  2. Discuss the issues in a way that leads to solutions being found so
    we can all improve something that we’re all passionate about.

To address the personal issues… I’m not here to make friends. Search
for
[email protected] in comp.sys.next.misc. You’ll see why I spend time in
newsgroups. It’s also not worth my time to spend more than the 3 hours
that
I spent tracking down an issue in 3rd party software. I’m hosting my
Ruby
Playground on Instiki because I think it’s best to eat the Ruby dog
food.
If I wanted a solution to the wiki issue and I didn’t want bugs, I’d
install
a PHP or Perl based package. If I wanted a mature environment for
writing
code, I’d stick with Java. I want something new and better… Ruby…
and I
want it to grow in popularity by servicing the needs of a larger and
larger
user base.

46

On May 4, 2006, at 8:19 AM, David P. wrote:

  • Instiki was written by someone who was not an ‘idiot chef’ but a
    skilled Ruby programmer.

I’m pretty sure DHH has claimed publicly that he didn’t think we was
a terrific Ruby programmer when he invented Rails and that would have
been after he invented Instiki.

  • Instiki was written using Rails… the “way” to write web apps in
    Ruby.

Instiki has been ported to Rails recently. It use to be a stand-
alone application. To my knowledge, the port was done by Instiki’s
new maintainer, not DHH.

  • If a non-complex Ruby app written by a skilled Ruby developer
    using
    standard Ruby tools breaks, how can a large company trust that a
    very
    complex Ruby program that has passed QA won’t fall into the same
    issue if
    the first user opens the “latest transaction” rather than the
    “account” page
    first thus causing a different order for class loads.

You have yet to show us your Instiki issue, but I’m pretty sure you
did not claim it was an issue of visiting a certain page caused a
page to break. I think you claimed that certain installed software
broke Instiki with some careless class hackery. To me, those are
pretty different issues.

If I wanted a solution to the wiki issue and I didn’t want bugs,
I’d install
a PHP or Perl based package.

Right, because Perl is definitely not a dynamic language like Ruby.
It’s so readable too, I’m sure a lot less mistakes are made with it.
Good point.

James Edward G. II

47

On 5/4/06, James Edward G. II [email protected] wrote:

On May 4, 2006, at 8:19 AM, David P. wrote:

  • Instiki was written by someone who was not an ‘idiot chef’ but a
    skilled Ruby programmer.

I’m pretty sure DHH has claimed publicly that he didn’t think we was
a terrific Ruby programmer when he invented Rails and that would have
been after he invented Instiki.

But whether he claimed it or not I think we can all agree he’s pretty
good!
Better than me anyway.

  • Instiki was written using Rails… the “way” to write web apps in

Ruby.

Instiki has been ported to Rails recently. It use to be a stand-
alone application. To my knowledge, the port was done by Instiki’s
new maintainer, not DHH.

But we’re getting away from the issue aren’t we?
The issue seems to be: should execution behaviour change with the
order of require statements in a program? Is it sufficient to have Ruby
warn us that a method is being redefined?

If I wanted a solution to the wiki issue and I didn’t want bugs,

I’d install
a PHP or Perl based package.

Right, because Perl is definitely not a dynamic language like Ruby.
It’s so readable too, I’m sure a lot less mistakes are made with it.
Good point.

AFAIR Perl’s require also allows redefinition of the world. If David is
saying
that Perl is easier to write bug free code in, he’s wrong in my
experience.

48

On 5/4/06, David P. [email protected] wrote:

I gave as an instance of this issue, Instiki. So… let’s drill down.
standard Ruby tools breaks, how can a large company trust that a very
2. Discuss the issues in a way that leads to solutions being found so
we can all improve something that we’re all passionate about.

The majority of your argument seems to center around the fact that
poorly
written software, or code that relies heavily on re-opening classes
(which
you seem to lump in with meta programming), can break in certain
circumstances. And I don’t think anyone would argue that at all. But
to
say that Ruby is not ready for “the enterprise” (I’m sure ara t howard
and a
few others would argue this one), because you can’t trust that code
added
later won’t break existing code is ridiculous. So, because in C/C++ I
can
gain direct access to memory, and modify objects IN memory, it isn’t
enterprise ready either, as depending on what order the code is run,
things
will act very differently.

And a very, very good programmer such as yourself, must welcome the
ability
to re-open the classes of existing code, to provide patched
functionality,
on a per-library, or per-application basis, without needing to add your
code
to a list of “approved” classes to be able to modify it. Oh wait,
that’s
dangerous and can’t be tested and shouldn’t be allowed in “the
enterpirse”,
nevermind.

Ruby may not be ready to fill the “enterprise” nitch that Java currently
sits in. The right tool, for the right job. Ruby is great at what it
does,
and I’d hate to see it become the bloated beast that Java is.

Of course you neglect the fact that no open-source language ever gains
significant market in “the enterprise” as PHB’s want a specific someone
to
hold accountable for everything, you won’t get that with Ruby.

49

I was doing a good job staying out of this thread, but no more. I
have been too annoyed at the lack of understanding, and while I don’t
expect to single-handedly change anybody’s mind, I wish to point out
what is going wrong here.

If Ruby wants to become more [than] a niche language that’s currently
getting 15 minutes of fame because of Rails […]

I’m going to go slightly off topic because this is just not true.
Ruby was getting extremely popular in Japan long before Rails. I
myself, in America, used Ruby for at least a year before I ever heard
of Rails.

Perhaps you should go back and read the entirety of my posts […]

You keep claiming that we are not paying you attention, but we are,
and I think it’s feeding the troll. Yes, I said it, this has been
reduced to a troll thread. The problem here is not that we are not
paying you enough attention or misunderstanding you. The problem is
in quite the other direction.

My premise is that Ruby is not ready for enterprise use because the
inability to predict the behavior of programs.

You are seeing this wrong. The ability to change the behavior of a
class is a feature, definitely not a bug. You know this, but you
refuse to just accept it.

If one cannot predict the
behavior of programs, one cannot test the programs.

Not true. Properly tested code will not be screwed up unknown by
meddling with it. If your testing practices are good (especially
extensive use of mock objects), then method-changing and duck-typing
will not mess up the program if the tests pass.

If one cannot test the
programs, one cannot deploy the programs into environments that have
significant regulation (e.g., financial services, health care,
insurance,
etc.)

Properly tested programs are tested under every environment they
are meant be introduced to, so this is no argument.

Frankly, I think your arguments are quite ridiculous and I find it
hard to believe that you are the very, very good programmer that you
say you are. Sorry to be harsh, but quit trying to lead everybody on.

  • Jake McArthur
50

Ruby has to evolve to support the needs of enterprise users.

Perl doesn’t seem to have catered particularly much to enterprise users
…
pretty much just keeps adding libraries and not changing itself that
much
and yet it seems to keep going strong.

[Yes i’m ignoring perl 6 because it’s a) not finished and b) a
completely
different beast. It may as well be a different language that just
happens to
have similar syntax.]

As far as being a rails app, last time i checked instiki had some pretty
significant deviations from the rails way of doing things check out it’s
storage mechanism … something which is at the core of most rails apps
and
the fact that it maintains state (rails apps are generally stateless, as
far
as the app is concerned).

Instiki may be a great app, but i don’t think it’s a great example of a
rails app.

As for idiot chefs. Even the greatest chefs screw something up from time
to
time when trying something new, or working in a different kitchen.

Your comment about “If a non-complex Ruby app written by a skilled Ruby
developer using standard Ruby tools breaks…” Are you honestly
suggesting
that if one non-complex app by a skilled developer breaks then the
language
it was written in can’t be trusted? Because in that case we can throw
out
EVERY programming language EVER invented.

-kate

51

David P. wrote:

The consquences of this is I can’t recommend Ruby to my enterprise
clients
because they can’t predictably deploy applications unless they have a
freeze-dried perfectly versioned system that will never change because
of
the unpredictability and instability of changing library versions.

Isn’t this the case with any language? As I see it this is not a
language specific problem. You want this kind of control for any
production system in any language. You don’t want the throw in new
libraries, or any piece of software for that matter, into a production
system without testing in on a test system first.

Oh… BTW – Instiki passes its unit tests because the load sequence is
correct for the unit tests… but it’s not correct when Instiki is
launched
as a CGI or FastCGI. So… the consquences of this is that you can’t
trust
unit tests in Ruby because they can be impacted by Module/Class load
sequences.

It sounds like they need to add a test case for this then and then fix
it (if they support that configuration, I don’t know). This sounds like
an Instiki issue, I wouldn’t apply this generally to Ruby. I think we’ve
all had problems like this before in systems (whether or not they use
Ruby). I know I’ve had my share.

Generally, I believe a language or system is considered not ready for
enterprise apps until many people think that it is, and that usually
comes from many people using it for enterprise apps. I know, it’s a
catch-22 and it’s just based on people’s perception which is not based
on reality. Once people believe that it’s suitable for this type of app,
people will just start to solve problems like you have found rather than
point to the language as the problem.

Candidly, I personally believe that any language or tool can work in
enterprise, mission critical systems. I also believe that any language
or tool can fail in the enterprise. The only true test is the empirical
test, to test it for what you are going to do with it. In my mind that
is the only proof that matters for whatever problem domain that it
applies too.

Going all the way back to the original question, talk about whether
something is ready for this or that, while very interesting discussion,
is sort of in the clouds intellectually, so to speak. While this can
lead to interesting and very useful ideas it seems impossible to prove
this point one way or another, without actually seriously trying it for
whatever your needs are.

I think what really matters is the comfort level with the people on the
team with the tools that they use. Ruby might work for the system, but
if the developers involved don’t think that it is a good tool or doubt
that they know how to use it properly then they are bound to have a
miserable time building the thing. I’d tend to say just use what the
team has the highest confidence with.

52

On 5/4/06, David P. [email protected] wrote:

Emphasis added.

There are problems with Ruby that make is not ready for enterprise systems.
These problems have fixes. Admitting there are problems and admitting that
Ruby needs to make it into the enterprise will help to address things rather
than having Ruby wind up in the heap of “coulda-been” systems like Lisp,
SmallTalk, Objective-C/NextStep/Interface Builder, OS/2 (okay, I hated OS/2,
but many thought it was great), etc.

I refuse to admit that ‘Ruby needs to make it into the enterprise’. I
don’t believe that’s true any more than I believe that brainf*ck[1] or
logo[2] ‘need’ to make it into the world of enterprise apps.

If Ruby wants to become more that a niche language that’s currently
getting 15 minutes of fame because of Rails, Ruby has to evolve to support
the needs of enterprise users.

Ruby is a programming language. It has no wants, or needs. It seems
that you want to use it for enterprise apps, and you believe it needs
to be changed for that to happen, but you are not Ruby. This reads
like a case of transference[3].

[1] Brainfuck - Wikipedia
[2] Logo (programming language) - Wikipedia
[3] Transference - Wikipedia

53

My premise is that Ruby is not ready for enterprise use because the
inability to predict the behavior of programs. If one cannot predict the
behavior of programs, one cannot test the programs. If one cannot test
the
programs, one cannot deploy the programs into environments that have
significant regulation (e.g., financial services, health care, insurance,
etc.)

I’m a Ruby newbie, but having done a bunch of work in other languages, I
do
think you have a point.

OTOH, I think you’re exaggerating the extent of the problem. As others
have
mentioned, various testing practices can mitigate the legitimate issues
that
you put forth. It’s also worth stating, again, that these kinds of
problems
aren’t exclusively Ruby’s.

I gave as an instance of this issue, Instiki. So… let’s drill down.
…

  • If a non-complex Ruby app written by a skilled Ruby developer using
    standard Ruby tools breaks, how can a large company trust that a very
    complex Ruby program that has passed QA won’t fall into the same issue
    if
    the first user opens the “latest transaction” rather than the “account”
    page
    first thus causing a different order for class loads.

IMO, a large company will have their own QA procedures which should test
the
deployment platform. In this particular example it’s hard to say that
this
provides anything more than a single datapoint.

Besides, a skilled programmer like yourself has diagnosed the problem
right?
In my experience, these kinds of deployment issues bite many projects
regardless of the language chosen.

Certainly there is a bit of frustration involved in tracking down a kind
of
bug that might not happen in other languages that one is familiar with,
but
there are other kinds of bugs that happen in other languages that don’t
happen in Ruby.

We can take two approaches to this issue:

  1. Not worry about and 3 years from now sit around saying, “Ruby
    coulda woulda shoulda”
  2. Discuss the issues in a way that leads to solutions being found so
    we can all improve something that we’re all passionate about.

I agree that the Ruby community should be thinking/talking about these
kinds
of things. I also think that there is a natural tendency to get
defensive/offensive about what one is passionate about.

I think what would be most effective at this point is to discuss some
possible solutions to the issues raised rather than trying to
continually
discussing the problem.

These facilities might already exist in Ruby, as I am a newbie myself,
but
for example: is there any way in Ruby to log the order of class loading?
Perhaps a way to require or specify order dependencies of the loading?

FWIW, I too don’t feel comfortable with changing lower level classes
that
alter “default” behavior, so it would be nice to at least have some easy
way
of detecting if this has occured for the “core” Ruby classes. Maybe a
RubyLint? I see there is CheckR on RubyForge, but it looks to be in the
very early stages.

Anyway, I’d like to have those more knowledgeable/skilled discuss
possible
solutions beyond the testing suggestions offered before.

54

I think the problem is in the expectations. Why would you expect that
two /executable runtime/ statements would not depend on the order in
which they are executed? Require is just another method.

I have to agree with James on this one. If I’ve written a library
that plays nicely and then somebody comes along and pulls the rug out
from under my feet, there’s not much I can do about it. My code isn’t
the one that is mucking things up. Besides, if I was suitable
paranoid I could check to make sure I’m not redefining a class and
steping on anybody elses feet:

fail %q{I don't like what's going on here!} if

Object.const_defined ‘ProblemClass’

class ProblemClass
    # ...
end

If I throw caution to the wind and stick my nose in other modules
buisness I deserve to get rapped.

55

On 5/4/06, Louis J Scoras [email protected] wrote:

–
Lou

I’m pretty sure the problem is that you don’t get rapped for
sticking your nose in other modules.

If I write ProblemClass, then install a gem that defines it, or some
newbie on my team messes around with it, then I’m the one who gets
the nasty surprise. Now there are some pretty simple solutions to
this - ensure you have good procedures in place to keep this from
happening, have a thorough test suite, etc - but the only thing that
David is suggesting is that there be a mechanism to keep these
modifications from happening.

I’m reading David’s comments as, “Yeah there are ways to protect
against this, but why not just let the computer handle it?”
Procedures don’t always get followed, and really I see no reason why
my unit tests should break because somebody else was careless. I
don’t have a need for it, but David’s opinion here seems entirely
reasonable to me.

Wouldn’t it be a lot nicer to do

class DontTouchMe
include Freezable
end

to ensure that nobody messes around with it? Procedures can be
error-prone, cause let’s face it, sometimes they just take a back seat
when you’re in a crunch, and having your unit tests randomly blow up
is inconvenient, not to mention a waste of time when you have to
search for the culprit.

Pat

56

On 5/4/06, Bill K. [email protected] wrote:

Should we start by closing the String class, then? :slight_smile:

Personally, I have no use for closing a class. If I were to write an
app to be used in a financial or health care organization, I would
probably want to be able to write some code with the knowledge that
nobody could arbitrarily change it.

Perhaps I shouldn’t even be commenting because I don’t have any
real-world experience with designing these kinds of apps. It just
seems to me that the main point is that sometimes a business has
requirements with a very high cost of failure. In these specialized
instances, I think it’s more than reasonable to protect your code.

Pat

57

From: “Pat M.” [email protected]

Wouldn’t it be a lot nicer to do

class DontTouchMe
include Freezable
end

to ensure that nobody messes around with it?

Should we start by closing the String class, then? :slight_smile:

What sorts of classes do you think should be made closed?

And why is the author of the class in the best position to
determine whether or not it should be open?

Regards,

Bill

58

On 5/4/06, Bill K. [email protected] wrote:

Should we start by closing the String class, then? :slight_smile:

What sorts of classes do you think should be made closed?

And why is the author of the class in the best position to
determine whether or not it should be open?

irb(main):001:0> class String
irb(main):002:1> def whee
irb(main):003:2> “whee”
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> “”.whee
=> “whee”

irb(main):007:0> String.freeze
=> String
irb(main):008:0> class String
irb(main):009:1> def yarr
irb(main):010:2> “yarr”
irb(main):011:2> end
irb(main):012:1> end
TypeError: can’t modify frozen class
from (irb):9
from :0
irb(main):013:0>

59

On Thursday 04 May 2006 5:37 pm, James B. wrote:

Right. And in those cases it may make sense to use a different
language. Various degrees of security often come with corresponding
development costs. For me, those day-to-day costs aren’t justified for
what I write; the pros and cons of Ruby work out quite well. But,
just as one might prefer C to Ruby when speed is the main concern, a
different language might be called for to satisfy other needs.

Better to change languages than to change Ruby.

Just as a data point, while what I produce are not large team, high
dollar,
multiyear projects (though I would love the opportunity to take on such
a
task), I make the vast majority of my income writing software, in Ruby,
for
customers in the financial, construction, and environmental sectors of
business. I’ve been doing this for four years. Some of the software is
web
related, and some is more related to issues of data handling, storage,
transfer, and transformation.

Kirk H.

60

Leslie V. wrote:

I just have a hard time accepting that we can’t just all program in Ruby
all the time! I have tried using IRB as a shell! I am eagerly awaiting
QtRuby
for Windows! I wish I could somehow load Ruby into my little ARM
processor
based embedded devices and kiss C and Assembler goodbye! (ie. in 32k of
RAM!)
Well … I had a hard time accepting that I couldn’t choose the language
I programmed in if I wanted to get paid for programming … for about a
week. If I had my druthers, I’d program in Lisp or assembler. It ain’t
gonna happen where I work. I program in Perl and R because I know them,
and because I’m on a team with other people who can read my code.

I wrote a very wonderful queuing modeling package a few years back in
Java. Why? Because I wanted something that would run on Windows or UNIX,
which ruled out Visual Basic. That left Perl and Java, and Java was
quite a bit faster, so Java it was.

That code is still sitting in CM untouched! My colleagues are off in a
class learning queuing modeling using something called PDQ, written
first in C and ported to Perl. It looks a lot like the package I
wrote. The difference is that it is being used, and my code isn’t.

Oh yeah … PDQ has also been ported to Python. Java? Ruby? R? Not
likely unless I do it, and since it’s open source, what glory or money
would I get out of it? My point is that virtually no one, even “lone
wolf” consultants, gets to pick the language on a for-profit project.
It’s only in the open-source world where any choice exists. Which is why
Ruby is as good as it is.

–
M. Edward (Ed) Borasky