From: David Pollak <pollak@...>
Date: 2006-05-03T22:10:52+09:00
Subject: Re: Sharp knives and glue

------=_Part_43858_22796847.1146661849257
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ed,

I love Ruby.  I love it.  I totally, totally love the language!!!

The Ruby community is totally awesome.  It's full of some of the brightest
people I've met in a computing community!!

Perhaps most importantly, Ruby is not a religion, but a philosophy of
computing.  Think about that and think about why it's important.

I am not arguing for turning Ruby into a strongly typed static piece of dog
poop.  I'm not arguing that Ruby should make a binary switch from what it i=
s
to what Java/C++, etc. are.

I am arguing that there are constructs that have worked for building large
scale systems.  There are constructs that have worked for building systems
that need to be created and maintained by geographically and temporally
distributed teams.

There are ways known today (e.g., the DbC MixIn for Ruby) that can improve
Ruby's development team scalability.  For all you DbC deriders, just think
of it as unit tests written right into the code rather than living in
separate files.  It's easier unit tests.

Ruby also needs better package name enforcement so there's not namespace
pollution.  Ruby needs multiple protected execution spaces so that a Ruby
application server can exist (FastCGI is not good enough.)  Ruby needs ways
of protecting private methods and data (obj.send(:my_private_method) is
bad... private methods are private for a reason.)  Ruby needs a way to say,
"only the following classes may modify the functionality of my classes and
the following methods cannot be changed" so I can protect myself from an
over-exurberant third-party modules.

I think there are other ways to improve Ruby... not by forcing Ruby to
change but by "Mixing In" tools/code/etc. that incrementally improve Ruby
for large scale system.

This sort of liquid scripting to slushy programming, but not rigid C++ styl=
e
programing might just allow Ruby to be better.

And if Ruby gets better, then I get to recommend Ruby to some big companies
and I get to do my projects in Ruby rather than prototyping in Ruby and
converting to Java before I deliver stuff to my clients.

I want Ruby to succeed the way Java succeeded.  I want Ruby to be a force
across computing the way Java is.  That's why I want to make Ruby a better
language and a better programming system.

On 5/2/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>
> Yeah, but ...
>
> There actually *is* a language designed more or less from the ground up
> for extensive compile-time error checking, package management, enforcing
> good programming habits and just in general making the discipline of
> software engineering a reality. That language is Ada, and it's still
> around.
>
> So ... why hasn't it dominated software engineering? Is it just because
> programmers are mostly undisciplined creative cowboys who refuse to
> program in languages that hold them accountable to some kind of
> discipline? Why, when Ada has been around so long, is there a need for
> Java, Perl, C++, Ruby, Javascript, Visual Basic, Python, PHP, etc.?
>
> David Pollak wrote:
> > Yep... unit tests help, but don't cure everything.  Design by Contract
> > puts
> > the unit tests in the code rather than separating them out.  Ruby has
> > a DbC
> > module.  See my rant:
> >
> http://dppruby.com/dppsrubyplayground/show/Rant+about+weakly+typed+langua=
ges+and+design+by+contract
> >
>
>
--
--------
David Pollak's Ruby Playground
http://dppruby.com

------=_Part_43858_22796847.1146661849257--