On Tue, 5 Dec 2006, Edwin F. 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
