Gregory Brown wrote:
> After my first day back at my University, I was quickly reminded that
> not everyone in the world embraces the "You'll shoot your eye out"
> nature of Ruby as much as we all do.  I just started a course on
> object oriented design in C++ and naturally the issues of security
> came up as soon as the fact that I had been working in Ruby had been
> mentioned.
> 
> Rather than spending an hour arguing for why Ruby's openness makes
> *my* life easier, I decided that i'd do a little research and digging
> around and then form an O'Reilly blog article on the topic.  As part
> of that research, I'm asking the RubyTalk community for some well
> founded opinions that make the case for dynamicity and openness,
> particularly the meta-programming tricks many of us have become
> acquainted with.

Here's a common case for me.  I often have some code that needs to 
escape or transform a string for some purpose. Rather than write

  stuff << NameSpacedUtilClass.some_modifier( my_string )

I prefer

  stuff << my_string.some_modifier

because I prefer Tell, Don't Ask.  It tends to make for crisper, clearer 
code.  And I can do that because I can add custom behavior to Strings.

I believe that is simpler and more correct than subclassing String to 
get my custom String-like class with custom behavior.

I've also grown found of being able to find and slurp in code files and 
instantiate classes based on some string.  My blogging software allows 
one to specify an output format as part of the URL. The code knows how 
to break up the path_info string and recognize when, say, there is a 
request for rss or xfml or OOo or whatever,  It knows that there is a 
file named rss.rb or xfml.rb or whatever.rb, with a class named (ready 
now?) Rss or Xfml or Whatever.  And so on.  So I can easily add new 
output formats by dropping rendering coding into a running app.

Now, I acquired this taste coding while Java in the late '90s, so this 
is not a Ruby thing per se, but I find it easier and more natural in 
Ruby.  The idea of convention over configuration is quite old (well, as 
software ideas go), but dynamic languages strike me as more friendly in 
this regard.  Far fewer hoops.  I don't get tied down in interfaces and 
'extends' or 'implements' or any of that crap.  Code just needs to be 
where it is expected and Do The Right Thing when asked.

The URL as [command line|method(arguments)|encoded message] is also not 
special to Ruby apps, with a history in PHP/Java/Perl, but again somehow 
Ruby makes it easier for me.  The line between plain text and program 
command is flexible.  I like that.

The availability of method_missing allows one to completely decouple the 
exposed API (the messages understood by an object) from the 
implementation (the methods inside an object), allowing for more robust, 
less brittle code.

Plus the ability to do sketch-driven development, 
code/run/tweak/test/code while adjusting designs and goals suits my 
temperament.

It seems to help me evolve DSLs, and follow the adage, "Build a 
language, not an application."

> 
> I'd also like to hear places that people would NOT use ruby due to
> it's open nature, and the reasons for that.  I'd like this article to
> be more a technical piece on why a little bit of life on the wild side
> can be a wise decision, and also why it can be less of a dangerous
> endeavor than some might believe when done correctly.  I'd like to
> avoid zealotry and flamage and my meta-programming-fu can kick your
> static ass type things, and instead focus on the nuts and bolts of the
> issue.

Good question.    I don't have a real answer.  Perhaps for medical 
equipment software or something where risk factors are so high that 
every and all means to ensure program correctness are required.  That 
means static typing, unit and functional tests,  whatever you can get 
your hands on.

Maybe.


James

-- 

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools