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

>From: Dave Thomas <[e-mail]>
>Reply-To: [e-mail]
>To: [e-mail] (ruby-talk ML)
>Subject: [ruby-talk:02144] Re: Scripting and OO -- thought question
>Date: 24 Mar 2000 13:48:56 -0600
>
>[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/ 
>|
>  
>---------------------------------------------------------------------------

Many things said above would also be true when replacing 'Ruby' with 
'Python'.

For those subjects like chess whose solutions already widely researched, the 
implementors can afford to do it in a "low" High Level language like C or 
C++ for performance reason.

For problems whose solutions are still vague and performance issues can be 
postponed, it's more effective and economic to do it in a "high" High Level 
language like Ruby (or Python). With Ruby (or Python) one can focus on 
finding the solution rather than debugging a memory leak.

Dat
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com