On 1/9/06, gwtmp01 / mac.com <gwtmp01 / mac.com> wrote:

> I'm not saying there aren't valid concerns.  What I'm saying
> is: can those concerns be elaborated beyond some general
> notion of 'fear' or 'security' and wouldn't that help construct
> a more appropriate response?

The fear in part has to do with type checking.  Ruby being typeless
scares people who tend to believe that type checking is absolutely
essential to 'safe' programming.  But as David Black and many others
had mentioned, safety is in the hands of the programmer.

I personally have never crashed my computer using Ruby.  On the
gripping hand, I've done many unsavory things in C, and at least a
couple in Perl.  These were 'accidents'.

I think that it's worthwhile to point that since low-level management
is not something we need to do in Ruby, such accidents are far less
likely to happen.  I think that this type of thing makes up the
lionshare of bugs and vulnerabilities.  You hear about overflow
exploits on a day to day basis... you very rarely hear of the l33t
h4x0r using metaprogramming to destroy a system.

People are afraid that without the type checking safety net, that the
program will begin to act unpredictable or will be capable of doing
random unsavory things.

The bottom line is, if you're in a production environment, you should
have all of your projects running against a comprehensive test suite. 
Continuous integration should be assumed.  Though it's universally
agreeable that regardless of the language you choose, you 'should' be
doing this, I do believe the popular opinion in most of the
experienced ruby core community is that you *MUST* be doing this.

And you know what?  It takes me about 30 seconds to find out what
jimmy's evil little gem has done to my system when I run my units on
all my projects to make sure they haven't broken with the addition of
a new library.

I mean, come on, does anyone add a require 'foo' from the wild into
production code WITHOUT running their units?  If they do, well then
all bets are off.

The biggest thing that those with a fear of dynamicity need to
recognize is that it's not as if we're programming in Java or C++ but
just removing the type checking and other 'security' measures.  We're
programming in a language that was designed from the ground up to be
used in the way we're using it.

Reflection and introspection in Ruby are so good we can actually use
it to PREVENT  unsavory effects through using it in our unit tests. 
Things like method_missing and respond_to? and the ability to search
our entire object space are features, not bugs.

This type of design allows for things like inversion of control /
dependency injection, which can be used to cleanly tack on logging and
unit testing features WITHOUT having to pollute methods with secondary
code.

I think that things like automated memoization make me LESS likely to
screw up than it would to roll my own in every single method that
needs it.

Ruby is no different than any other language.  Bad code and bad coders
will cause problems, good code and good coders will solve problems. 
Simply because it was not a design goal to make the programmer feel
safe and 'secure', but rather to make them feel powerful is NOT a
flaw.

Wow... i'm ranting here.  Better here than in my article I suppose,
but there are my answers to our still yet to be precisely defined
questions ;)

Let me know what you think.
-Greg