Re: OO Strengths (was: Strong advantages over Python)

| me: 	"yeah OO is great, it reflects real world!"
| friend:	"Sure. How do you make coffe?"
| me:	"well, I open the coffe machine and put in coffe and water,
| 	put it on fire, wait and drink"

Person instance interacts w/ HeatSource instance which results in an instance 
whose class mixes in Water and Coffee?

This reminds me of the (in)famous elevator control example quoted by 
proponents of concurrent programming (erlang, specifically):

"I recall reading a flamewar somewhere about Erlang vs. OO languages. The 
sample problem was a control system for three elevators. The Erlang person 
claimed that Erlang matched the problem naturally, because you just create 
three processes, one for each elevator, and make each respond to (callbutton 
Floor), (door_open), and (door_close) messages. The OO person pointed out 
that you could just as easily create three objects with the same methods and 
get the same result. From an interface point of view, there's no difference. 
But try to actually implement this, with actual elevators going up and down 
and motors starting and stopping. In Erlang, it's about as complex as you'd 
expect. In most OO languages it's a nightmare, because the real world has 
stuck it's asynchronous nose in and suddenly you've got to deal with either 
threads or a nasty control flow inversion."

I love OO, but agree that different paradigms do, really, match up better in 
certain circumstances... not that an ICBM missile control system wouldn't be 
fun to implement in Ruby (albeit scary).  I'd just use Test::Unit copiously. 
;-)

// Bruce

-- 
author: Bruce R. Williams 
url: http://codedbliss.com
irc: { nick: iusris, channel: [ruby-lang,yaml], server: irc.freenode.net }
quote: >
  It does not require a majority to prevail, but rather an irate,
  tireless minority keen to set brush fires in people's minds.'
  -- Samuel Adams