On 13 Jan 2004, GGarramuno wrote:

> Date: 13 Jan 2004 13:35:24 -0800
> From: GGarramuno <GGarramuno / aol.com>
> Newsgroups: comp.lang.ruby
> Subject: Re: faster integer arithmetics & arbitrary precision floating
>     number
> 
> Gavin Sinclair <gsinclair / soyabean.com.au> wrote in message news:<16176736811.20040113210844 / soyabean.com.au>...
> > On Tuesday, January 13, 2004, 2:21:37 PM, GGarramuno wrote:
> > 
> > Like many things about Ruby: a problem in theory (or can be construed
> > as such), but not in practice.
> > 
> 
> Disagree.  I'm new to the language and I am evaluating it to see if it is
> worth investing on it and I can tell you this is NOT a minor issue.  For me,
> it is the first real big, big, big problem to consider ruby as a scripting
> replacement to current tools.
<snip>

gavin is right.

the proof is in the pudding.  do a search on clr and you'll not find (m)any
instances of this as a real problem.  do a search on people claim it's a
problem and you'll find many.  i understand people are simply uncomfortable
with the notion, but i've been doing web, database, scripting, image
processing, system, gui, tui, network, etc. programming with ruby (nearly
exclusively) for the last 1 1/2 years and _never_ seen an instance if this as
a problem and i open up system classes pretty often.

i had the same objection you have when i first started with ruby (i blame
c--).  however, consider that all of your arguments as applying to wikis - as
they too seem to suffer from being over-exposed/not-protected.  and yet they
work?  or consider that it's perfectly valid to update a 'constant' in ruby,
possibly breaking someones carefully crafted class.  it doesn't happen -
though it could.

on a broader note, consider that there really is no such thing as 'private' or
'protected' in open source... you are free to change the c code and recompile!

i took me a while to finally decide that all the developers out there aren't
out there to get me.  if code works in some sort of intuitive way people don't
often decide to go mucking with internals - check out dan berstein's cdb
package, it's raw, exposed, unprotected c source that works like a champ.  in
fact, there are about a billion c libs that would be _very_ easy to break if
one cared to; and yet, good c libs seem to abound at 100 times the rate of
good c-- ones.  hmmm.  i know that c programers sometime try to protect using
'static' and 'const' - but it's rather lazy isn't it?:

  most would do

    /* hash lookup */
    const char *fetch(const char * key);

  when really they should be doing

    /* hash lookup */
    const char * const fetch(const char * const key);

for some reason, this bothers no one.  neither does that fact that one can
simply redefine any ol struct in c and break things left and right...

another thing to consider is that it IS dangerous to muck with internals in
c-- libs - all too easy to core dump and corrupt the heap and we've _all_ been
through those debugging sessions....

i've never even _needed_ a debugger with ruby and all it's dangerous features.

MHO. 

cheers.

-a

-- 

ATTN: please update your address books with address below!

===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| STP     :: http://www.ngdc.noaa.gov/stp/
| NGDC    :: http://www.ngdc.noaa.gov/
| NESDIS  :: http://www.nesdis.noaa.gov/
| NOAA    :: http://www.noaa.gov/
| US DOC  :: http://www.commerce.gov/
|
| The difference between art and science is that science is what we
| understand well enough to explain to a computer.  
| Art is everything else.  
|   -- Donald Knuth, "Discover"
|
| /bin/sh -c 'for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done' 
===============================================================================