[ruby-talk:00902] Re: Contrast Ruby and Other Languages

From: gotoken@... (GOTO Kentaro)
Date: 1999-11-02 10:28:13 UTC
List: ruby-talk #902
Hi, 

I've read comp.lang.python. Those are caused by some improper my
words, "ugly" or "(Memory leak occur) often".  Ah, you've corrected
them? Thanks!

In message "[ruby-talk:00899] Re: Contrast Ruby and Other Languages"
    on 99/11/02, Yukihiro Matsumoto <matz@netlab.co.jp> writes:

>In addition, contol structure being object is mere illusion in most
>Smalltalk implementation.  The compiler detect the ifTrue selecter,
>etc., then turn them into conditional bytecode instructions.  No block
>object generated in execution.  So that even if you redefine ifTrue
>method, the bytecode interpreter wouldn't invoke the method.
>
>Why do I have to put the thing even Smalltalk abandoned (leaving
>illusion though) in Ruby?  They are ugly too, I think.

I agree, though the illusions are needed in some special cases...  

In our project on numerical calculation, we feel necessarily of a such
kind of control object for an abstruct enormous numerical array,
because we would define and apply some oprations to each element but
we would not like to make each element be an object in the processing
in order to keep performance.  Unfortunately, a parsed node isn't open
information in a ruby intepretor, so we consider that we have to
design "a language in a langage" such that it can be translated into
efficient byte code and it sould be purely object-oriented or purely
functional even on controls, which can be portable in a ruby
interpreter implementation. 

For example (it is just my not enough consideration):

  ary = NumArray.load("datafile")
  ary.apply!( (GEQ(Threshold) + op1 + op2)*IF_THEN_ELSE )

instead of

  ary = ary.collect{|i| if i >= Threshold then op1(i) else op2(i) end }


We are discussing such problem now. By the way, I would like to
emphasize that Ruby is helpful to prototype even in such situations.

-- gotoken

In This Thread

Prev Next