[ruby-talk:02144] Re: Scripting and OO -- thought question

[e-mail] writes:

> In his words, "If I were going to write a 60,000 line chess program
> or something, I wouldn't do it in Perl or any other script; I'd use
> Java or C++ or something. And if I were doing something like a
> filter, like 'munging' a text file, I wouldn't really need OO."

Well, I guess I'd first say that it would clearly be his choice.

I think I'd then ask him what differentiates a scripting language from 
any other. Clearly it's not the fact that it's interpreted, as he
accepts Java as a "real" language. I'd point to the many successful
implementations using Smalltalk and Lisp as examples of the successful 
use of technologies such as Ruby.

Then I think I'd discuss the nature of development itself. Take his
chess program. It sounds to me that there'd have to be a lot of
exploratory work before you got a program that played effectively.
When I'd doing that kind of exploration, I need an environment that
gets out of my way, and lets me express myself as directly as
possible. C doesn't do that--I have to provide too much infrastructure
stuff. Java doesn't do it--there's too much scaffolding required. C++?
Nah.

However, in Ruby, I can express myself very close to the problem
domain. The combination of functional programming, linear code and
object orientation is potent. The fact that the language can be
extended at run-time let's me defer decisions to the ultimate
point. And the fact that there's no edit/compile/run cycle is
tremendous. Within emacs, I even get some of the benefits of the
Smalltalk browser environment--I can highlight a block of code and
execute in on the spot.

Then there's the issue of using OO for munging. I don't agree.
One of the main benefits of OO is encapsulation---managing
dependencies in a controlled way. I used to script in Perl. I'd write
big scripts---filters with many thousands of lines. They'd start of
clean and tidy, but gradually they'd start to decay. Perl makes it
hard to encapsulate both data and code, so people tend not to do too
good a job of it. With Ruby, such encapsulation is natural. Even
simple scripts are easier to understand and to maintain.

Then I'd talk about performance. Sure Ruby is slower than C. But
mostly the economics of development make that irrelevant. For a
one-off program, it's often cheaper to buy a faster machine than pay
me for the extra time to write in Java. The difference between a
400MHz x86 and a 600 Mhz one is probably a small number of hours of my 
time.

However, there will be times when performance is a real issue. This is
where the ability to extend Ruby comes in. Build the framework of your
application quickly, in Ruby. Show it to the client, and make sure it
does what they want. Then see if there _are_ performance issues.
Isolate them, and then recode just the required sections in C.  Ruby
makes this easy. This is the approach Andy and I are taking in a
current project, where we're writing portions of an X11 window manager
in Ruby.

However, probably the only thing that will _really_ convince someone
is to try it, and that's quite a large step to take.

Let us know if we can help.


Regards


Dave



 ___________________________________________________________________________
| The Pragmatic Programmers, LLC     |  http://www.pragmaticprogrammer.com  |
| Read "The Pragmatic Programmer"    |  www.pragmaticprogrammer.com/ppbook/ |
 ---------------------------------------------------------------------------