[ruby-talk:02148] Scripting and OO -- thought question

[e-mail] writes:
> Here's an opinion question for you all.
> 
> I was telling a friend about Ruby the other day,
> and I told him how it was OO from the ground up,
> unlike Perl, etc.
> 
> His interest level was mild. He said that he 
> thought object orientation was a good thing in
> general, but that for the things scripting 
> languages are generally used for, it's not that
> useful.
> 
> 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."
> 
> That's an interesting thought. How would you answer
> him?

That is difficult, I think. IMHO, your friend has a total archaic
understanding of the term scripting. If he does not want to revise
this understanding, he never will catch the whole truth, I fear.

His understanding seems to be from the time of the good old Bourne
shell. In that time scripting was used to glue several programs
together to do a more complex work.

Today the term scripting has changed its meaning, IMO. Today we do not 
necessarily glue programs together, but libraries or modules and the
like!

In the past we have used so-called high level languages like C, C++ or
other to describe an algorithm in a high-level form. It was easier for
the programer to use such languages to come to a solution than
to program into Assembler directly. Although programs written in
Assembler were faster than the ones written in C. So programmer has
begun to combine the both worlds. First write an application in
e.g. C, then tune it by re-writing time critical parts of them in
Assembler.

Today a new level has open. The task of the high-level languages in
the past, are now taken over by the so-called scripting languages. 
What Assembler was for C yesterday, is C for scripting languages like
Ruby or Perl today. Unfortunately much people has not recognized it
yet. But I am sure they will!

Today I am writing a whole application in e.g. Ruby. That is done much 
faster than writing it in e.g. C++. If the customer is convinced I can 
begin to tune it by re-writing the time critical parts in C. Normally
Assembler is not necessary anymore. C has taken over its part.

I believe that most of the fault why people think so ancient about
scripting goes to Perl. Perl was invented to allow the system
administrator to write scripts like the good old Bourne shell, sed,
awk mixmax more convenient. Not using three or more programs but only
one ... Perl! 

I do not know for sure, but after looking into the Perl C API --the
how to extend Perl-- I got the impression Perl was not invented with
easy extendability using C in mind. There is really a big difference
in extending Perl compared with languages like Tcl, Python or
Ruby. The last is the easiest, IMO!

> I think I see his point; but perhaps one reason he
> would not use a scripting language for a large 
> project is that he simply has never SEEN a scripting
> language powerful enough for large projects.

Then he has not looked to such languages very carefully, IMO. Due to
the facts I mentioned above, I dare to guess he is biased against
scripting languages. 

I mean, I can take every one of Ruby, Python, Perl or Tcl to bring a
large project to success. Only I have to bear in mind, that I probably
have also to use C to do some small parts of the project. Scripting
only may be difficult or impossible; but the combination of scripting
and e.g. C ... no problem at all. The only remaining problem is: how
to hide my source code against the customer. ;-)

> There is also the speed issue; but he cites Java as
> a "real" language, and we are certainly not 
> guaranteed that it will be speedy on every platform.

Then he cannot mean interpreted languages. Does he think only deep
compiled ones are 'real'? Have a look onto Objective C; this language
is compiled but its object system has much in common with Smalltalk. 
Or take Smalltalk ... it is interpreted most of the time. Whether
directly via syntax tree (Ruby, Perl), or indirectly via bytecode like
Java, Python or Tcl. Is Smalltalk a 'real' language?

If Smalltalk is a real language, have a look to Ruby. Many Smalltalk
programs can simply be transferred to Ruby by changing the syntax; not 
the semantic. Does that make Ruby a 'real' language? Are only
languages with type system be 'real'? Then Objective C is also not
'real'. Its variables are totally typeless like Ruby's, Python's or
Smalltalk's.

What is with Prolog? Or do you know the good old UCSD-Pascal? It was
bytecode interpreted! 'Real' language?

And the speed issue ... I think there is no such an issue, if you can
code time critical parts in C. I strongly believe that my app using
scripting and C together would be nearly as performant as his one
coded in C/C++ only. And perhaps more reliable, thinking for Ruby's
true garbage collector, for instance.

I think your friend has to widen his horizon. The world has changed. 
His opinions were true, but a long time ago. Not today. What is a
'real' language is not so easy decideable today. I would say that
question concerning 'real' or not 'real' is nearly meaningless now.

There are problems, there are solutions and there are languages. Take
the one, that helps you most to come to your solution. That would be
the right one!

> Opinions?

I think, he should first try to understand my claims about scripting. 
Then we could begin to discuss whether one could/should use OOP for
e.g. text filter or chess problem solvers.

Just my US$1.20. Sorry for being so verbose. I hope I had not waste
too much bandwith :-)

> 
> Hal Fulton

\cle

-- 
Clemens Hintze  mailto: [e-mail]