> > > Someone please tell me if this is an inappropriate question for this list -
> > > I don't want to irritate or offend anyone here.
> > > What is the benefit of a true object-oriented language (Ruby), in which
> > > everything is an object, as opposed to, say (arbitrarily) a language that is
> > > not strictly object-oriented (yet is still popular) like Java?
> > > 
> > > Forgive the newbie his ignorance  =)
> > 
> > 	You're forgiven, but I can't speak for the rest of the folks on 
> > the list.  ;~)
> > 
> > 	Two big points come to mind:
> > 
> > 	1)  Big projects.  Because everything is encapsulated in bite
> > (byte?) sized functionality, you can divvy out the workload easily and 
> > test the components very easily.
> > 
> > 	2)  Similar to point 1, code reuse.  Because you have an
> > abstract set of layers, you can pass out simple API trees and have 
> > developers re-use various parts of a system.
> > 
> > 	There are many more reasons, but those are the two biggies that 
> > I always cite when someone asks, but your milage may vary depending on 
> > the project and group of people that you're working with.  <:~)  -sc
> 
> But, playing Devil's Advocate here, how is that an improvement over
> Java/Python/OOPerl? Points 1 and 2 are both addressed in these
> languages. 

	I knew someone would call me on that as soon as I read my 
response.  ::grin::


	In principle, there isn't any huge difference between
Java/Python/OOPerl and Ruby.  What is different, is that Ruby, to me, is
a significantly more elegant language to work in than its rival
languages.

	Why is that important on a project?  With any large project, esp
under a time crunch, there are always half baked classes, shims,
kludges, etc.  Ruby's still susceptible to this, however because the
language (matz and company to be specific) elegantly solves many
problems that developers have with the language itself, you spend less
time working around the language and more time working on the project at
hand.

	In OOPerl, an object or class is a pretty brutish/blessish hack.  
In Python, that's not necessarily the case but you still have an arcane
syntax structure that leaves my pallet screaming for something else
(MO).  Java isn't bad, but it's very similar to C and for some reason,
after using it for 4 years, it still leaves me with a shallow taste...  
almost like it's a toy language that doesn't have any umpfh behind it
probably because of RAM and performance issues, its marketing dept, and
commercialization (read: philosophical issues).

	Ruby on the other hand has a very clean syntax (leaves me with a
warm and fuzzy feeling), can be extended into C with relative ease for
native speed, the garbage collector can be controlled for increased
performance of tight iterations in ruby, multiple inheritance isn't an
issue with mixins, you can tie pretty much every C API to ruby in less
than a week making ruby a great glue language, and because its scripted
development time is decreased even further (never mind the module support
that's already out there which is fantastic and more well maintained
than Perl's modules).

	None of these reasons, however, prevent you from doing a project
in Java, Python, or OOPerl.  You can substitute Python, Ruby, Java,
OOPerl, C++, and even BASIC (if you're skilled enough) with any other
language and get any task completed, they're all just 1's and 0's that
are manipulated through an interface to some assembly routines.  
Thinking in terms of the bits is more important than thinking in terms
of the constraints of the language.  With that in mind, I endorse having
someone use whatever language is the easiest for the developers on the
project to use (within the scope limitations of a project, sometimes you
need binaries ::hint hint::).  In my universe, Ruby has many advantages
that will make it the preferred language for development projects for me
and whatever team I'm heading up for quite some time.  So much so, that
I fully intend to teach as many programmers as necessary so that ruby is
the language in use.

-sc

	PS  Normal legal and opinion disclaimer applies.

-- 
Sean Chittenden