From: ara.t.howard@...
Date: 2006-12-05T14:14:42+09:00
Subject: Re: Question about Ruby philosophy

On Tue, 5 Dec 2006, Edwin Fine wrote:

> Ah, but here's the difference. You have to know a fair amount of C to
> even build a shared library, using malloc() and friends for memory
> (mis)management. You have to compile and link the code.
>
> It's a lot more work than writing
> class Array
>  def clobbersomething
>  end
> end

gcc -shared a.c

??

not too hard.  but i understand your point.  still, i disagree that the people
releasing rubygems are of any lower quality than the people releasing shared
libraries.  remember, if the code is not available the question is rather moot
and, in any language, you'll notice only 1% of coders releasing libraries.
this works in our favour with respect to robustness.

> In Java, it's not trivial to manipulate bytecode. It's usually done by
> experts, although there are frameworks out there that make it easier.
> It's a lot more work than writing
>
> class Array
>  def clobbersomething
>  end
> end

the same can be said of meta-programming and manipulating built-ins in ruby.
i've spoken on both subjects a few times and have many libraries out there
that do some of each or both - my perception has never been that the even
above average ruby hacker is doing tons of either, especially without thinking
about it.

> You are not going to get rank beginners to use Boost::anything. It
> doesn't even compile on all major compilers (e.g. Only the most recent
> versions of HPUX aCC support partial template specialization), and I
> defy any average intern to decipher C++ compile-time error messages
> relating to template problems.

no argument there.  the point though, was that boost and many other powerful
tools do indeed subvert the safety systems of their respective languages.  as
in ruby, great power is dangerous.

> It sure is a lot more work than writing
> class Array
>  def clobbersomething
>  end
> end

on thing to consider, however, is also how easy it would be to debug such an
error.  it'd literally be

   Array.freeze
   require 'clobbersomething.rb'  #=> beautiful stack-trace

this is no small point.  as someone who doesn't even write c code without
firing up gcc i can assure you that, in 6 years of full-time ruby hacking,
i've never pulled those week long
sinking-feeling-in-the-pit-of-your-stomach-marathon-gdb-sessions i used to
routinely pull when i worked with c-- and c more often!

we've all corrupted the heap before...  ;-)


> Please, I am not Ruby-bashing. I know there are far worse languages out
> there from the point of view of shooting yourself in the foot (I've used
> enough of them that I'm lucky even to have any feet left :). Any language
> that provides a lot of power can be misused. Ruby simply makes this one
> thing so easy to do, with such potentially dire consequences.  If anything,
> I'd just want an optional way (besides .freeze) to control what can and
> can't be extended at run-time, to prevent accidental, ill-advised, or even
> malicious tampering, or to help identify it). Hey, maybe there's a way to do
> it already?

i think everyone is on the same page with you here, and you comments are
certainly well taken.  i'll leave to others to comment on potential solutions.

kind regards.

-a
-- 
if you want others to be happy, practice compassion.
if you want to be happy, practice compassion.  -- the dalai lama