From: Edwin Fine <efine145-nospam01@...>
Date: 2006-12-05T13:28:19+09:00
Subject: Re: Question about Ruby philosophy

unknown wrote:
> On Tue, 5 Dec 2006, Edwin Fine wrote:
> 
>> in (say) Array, that do different things <shudder>. That could be fun to
>> debug.
>>
>> Sure, you can decide not to use such a library, but you have to get
>> burned first before you realize it's not good to use. I'm probably
>> showing my age here, but I remember cases where people used to code
>> macros in C header files (like MIN and MAX) that would clash with other
>> uses of MIN and MAX and cause untold havoc. Some of these were from
>> mainstream companies.
> 
>    harp:~ > irb
>    irb(main):001:0> Array.freeze
>    => Array
> 
>    irb(main):002:0> class << Array; def each() 'ha-ha'; end; end
>    TypeError: can't modify frozen object
>            from (irb):4
>            from :0
> 
> 
>> It's one thing to say "What if I'm stupid?". It's quite another thing to
>> say, "What if lots of stupid/undisciplined people start using Ruby?"
>> This tends to be the price of language popularity, I fear.
>>
>> Probably, evolutionary forces will get rid of the poorly designed
>> libraries in time. I'm more worried about the beleaguered corporate IT
>> developer who often does not have much choice and has to use in-house
>> code.
>>
>> I dunno. Thoughts?
> 
> what if people start coding in c and leave dangling pointers lying 
> around,
> double free pointers, corrupt the heap in their lib, forget the clean-up
> resources in at_exit handlers, or don't prefix each and every
> var/function/macro with something like my_lib_XXX?
> 
> where would we be?  ;-)
> 
> i can hear people thinking 'java' out there already - but those guys are
> manipulating byte code to subvert their fist-cuffs already!  anyone know 
> a
> thing or two about boost::any?  on a related note, it seems the most 
> useful
> ocaml code uses the type system in a way that makes the promise of 
> 'safe'
> programs more difficult or impossible for the compiler to ensure...
> 
> history has shown that there is exactly __one__ re-usable component of 
> code:
> the shared library.  at least in the *nix world, nearly all of them are 
> written
> in c and it is plagued by issues at least two orders of magnitude, imho, 
> worse
> than clobbering Array#each!  yet, the internet continues to be powered 
> by *nix
> servers running said c libraries ;-)
> 
> (ducking)
> 
> -a

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

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

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.

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

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?

-- 
Posted via http://www.ruby-forum.com/.