Re: Compiling Ruby to Native Code?

Bob Calco wrote:

>...
>However, I am a supporter of exploring other paradigms. Ocaml and Haskell,
>mentioned above, are indeed interesting and quite powerful in their domains.
>Another, somewhat more obscure, language that I have a certain affection for
>is Mozart-Oz, which supports not one, not two, but no less than FIVE
>computational paradigms, all in the same very efficient kernel language.
>Like Java, Oz compiles to cross-platform bytecode. But unlike Java, it's
>network concurrency is entirely transparent to the programmer, and Oz
>"fuctors" (or components) are free to use any paradigm internally that gets
>the job done. Is your problem a constraints problem? Use the declarative
>aspects of the kernel language, a la prolog. Is the problem more simply
>modelled after human real-world abstractions? Then use OO, complete with all
>the trappings thereof (inheritance, encapsulation, polymorphism, etc.). Is
>your problem computationally expensive? Then use the functional subset of
>the kernel language, a la Haskell. Its really an amazing feat in computer
>science to have combined the paradigms as cleanly as completely as they (the
>Mozart consortium folks) have.
>
>If it interests you at all, check them out at www.mozart-oz.org.
>
>Now for day-to-day practical problems I find that Ruby more than suffices
>for just about everything, and I'm in love with its extensibility. I'm
>working on some exciting packages for the Ruby community, and I want to see
>this community -- and the language -- grow. In fact, I'd say I'm personally
>committed to that goal.
>
>But there is something to be said for the multiparadigm approach, whether
>you achieve that by blending components written in different languages (and
>.NET doesn't really count here, since all .NET langauges share the same
>fundamental OO semantics, via the CLR), or you use one language that
>supports all of them. For some problem domains, strictly OO methodology is
>not the optimal approach.
>
>So - that's all I have to say about that.
>
>Back to Ruby coding... :)
>
>Sincerely,
>
>Bob Calco
>  
>
The problem that I have with many of those paradigms, is that they don't easily support the idea of data files.  Particularly of data files that may be looked at and changed in some other language.  This seems endemic in the functional languages, though, of course, the object oriented languages have their problems with it also (as you know if you have ever tried to keep a relational database in sync with a object oriented program).  This is why marshalling was invented, and it's far from perfect.  Only the procedural languages seem to have solved this one, and that largely by not directly representing the kind of structures that cause problems.

I assume that there actually are ways to address this in Mozart, but I wasn't able to discover them in the time that I allotted for evaluation.  Other than that it looked quite interesting, but that was such a large "but" that I never tried to implement anything.  Ditto for Haskell.  Eiffel was quite interesting, and I rather like it.  But some unnecessary choices (e.g., no operation redefinitions with altered parameter lists) have rendered it quite inflexible.  I've used it a bit, but you need to be extremely careful to not name operations anything reasonable, e.g. substring, because that will cause grief.  Instead use a name like substring_with_unspec_length.  Operator overriding is quite basic to all other computer languages.  Even Fortran 77 has what Eiffel considers a forbidden amount of operator overriding (+ can be used not only on integers, but also on floats, and between integers and floats, and ...).  So I found Eiffel unreasonably clumsy, and for no good reason (paraphrase" There can exist situations where the meanings of different operations cannot be disabiguated by the type of their parameters, e.g., point(x, y) and point(r, theta), so we must forbid this choice."), and so in the language design the operations are totally specified by the name of the operation.  (Perhaps C++ munges names to do this, but at least the programmer doesn't need to keep track of THAT.)

This is a great pity.  Most of the code that I do really is statically determinable, so it would be nice to be able to compile it to execute with the potential efficiency.  Unfortunately, it usually needs to work with at least some modules that aren't.  Currently the only choice seems to be C (and probably a few C mimics .. I wonder how I would link Ruby with Ada95[gnat]?).




-- 
-- Charles Hixson
Gnu software that is free,
The best is yet to be.