[ruby-talk:02177] Re: The evolution of Ruby

Dat Nguyen writes:
> 
> 
> >From: Dave Thomas <[e-mail]>
> >Reply-To: [e-mail]
> >To: [e-mail] (ruby-talk ML)
> >Subject: [ruby-talk:02174] Re: The evolution of Ruby
> >Date: 26 Mar 2000 10:31:44 -0600
> >
> >"Dat Nguyen" <[e-mail]> writes:
> >
> > > They all are implemented in C and have to deal with the same
> > > language design problems.
> >
> >I'm not sure I see your point.
> >
> >Are you saying things should evolve, or shouldn't evolve?
> 
> Things will evolve until they reach similar level of complexity.

I do not buy this!!! IMHO no language, I know currently, can become so
complex like Perl. This is because Perl's C-API sucks, its OO model
sucks and the language in itself has context sensitivity built-in.

That means in Perl:

   $copy = @arr;

is different from:

   @copy = @arr;

only because there are different contexts valid. I do not say I do not
like this (but OTOH, I have also not said I do ;-), but this makes
Perl more complex then e.g. Ruby.

And because of this (context thingy) I cannot believe that as long as
Ruby will not introduce this, it can ever become so complex like Perl!

> >Is the underlying implementation language significant?
> 
> It looks that way, unless you have a totally different kind of tool.

No! Never! You should bear in mind that in the end, all is machine
code. Even GCC will translate C code into Assembler code first and
then let the Assembler translate this into machine code.

I can code crap using C, and I also can code excellent apps in even
C++! I russian guy, I have the luck to know, has written an own
language called C-Talk. This language is a much-better C++. In fact it
is stright a concurrent to Java. Only as Java is more popular, he has
not believed that is language can survive. So he has not worked on on
this.

This language has true GC, multithreading like Ruby, persistent
objects, is absolutely type-safe and compiles to byte-code. It is
really a very nice peace-of-work.

Is is implemented in C++!!!! You can simply extend the interpreter
using C++. You introduce a new class to it, by implementing a C++
class. Very nice, really.

> I saw kludges being done in C to achieve an impression of having another 
> kind of language. Trade-off will have to be made.

Of course! And this is true for every language!

> Mastering C is still essential to complement the scripting language when it 
> comes to performance.

I would say: you are right, but with exceptions. Look at Oberon, for
instance. It is a OS, a language and a compiler. No C involved. The
compiler was bootstrapped using a Modula-2 compiler. Very nice
environment! Excellent desktop environment with super flexible
toolkit. And it needs only a small part of RAM or disk space of a
e.g. Linux system.

...

> Guido was doing the same with C to create Python, ditto Matz created Ruby.

Ohh! That is a too simple point-of-view. Using that way you could say
a painting is only some color on a paper. A book is only white paper
with some black whatever on it.

Neither Guido nor matz have tried to add some OOP feature to C. Both
have used C as theirs implementation language to write
compiler/interpreter for a totally different language that has NOTHING
in common with C!

They had also chosen Forth, Modula-2 or even Assembler to implement
theirs language.

I really think, you have to separate the product from the language it
is realized in.

Do you want to say that Billy-Boy has tried to add some graphical
window features to C and the result was M$-Windoofs?

> Dat
> 
> >
> >Dave

\cle

-- 
Clemens Hintze  mailto: [e-mail]