Ok, let me explain a bit more what I am aiming for... I'll explain it 
with the work I'm currently doing. The ultimate goal is to have MPEGs 
latest video codec, SVC (Scalable Video Codec), running on a 
multi-processor platform, with heterogenous processors for regular 
kernels, like motion compensation, and dedicated hardware for 
bit-mingling stuff, like the arithmetic coder. We start at the highest 
level, taking the reference software from MPEG. The next step is running 
this software through our in-house developed toolset, which analyses for 
instance the number of accesses (reads, writes) to the arrays in the 
program. This gives you information on where to reduce and reuse data 
access, and hence accesses to memories, and hence the power consumption, 
which enables you to watch video longer on a mobile device. These tools 
also gives you a hint on memory hierarchy in the design, how much L1, L2 
and higher level memory you need, so you can reduce memory accesses to 
big memories, as there are more energy consuming. The idea is that 
production of data and consumption of data should be as close as 
possible, avoiding storage of huge data sets, for instance complete 
frames of a sequence.

This worked out quite well, since all reference software until now was 
written in C, and our toolset only allows C as input. But the reference 
software of SVC is written in C++, so these tools were not usuable 
anymore, so yours truly, and that is where the frustration comes from, 
has to rewrite the complete codec into C, so our tools can support it. 
The problem they have with having C++ as input is the dynamic behaviour 
of the data, they analyses the data statically, not at run-time, so when 
you instantiate an object from a class using new, they cannot analyse 
that. Which sounds strange to me, they can as well do run-time analysis 
in my opinion, but that is a discussion I will have to have with them.

Anyway, so I thought Ruby might pop in here, because of the 
metaprogramming concepts. I think that might solve a lot of their 
problems. But I don't have any proofs yet, so I'm trying to figure these 
things out now, with small examples.

>Do you mean your company write optimized multimedia algorithms (or
>build tools, what the hell is a build tool for an algorithm ????).
>  
>
;-), no, the mail said 'our company builds tools', not we make build 
tools ;-)

>If you develop algorithms then you can use Ruby to prototype a new algorithm
>(if it's not already way to slow even for this) but writting optimized
>algorithm for processing multimedia in ruby is the hugest possible mismatch
>of language and application domain i've seen so far. It's always my
>example that in this cases a ruby program is about 100-200 times
>slower then a c program.
>  
>
I knew there was going to be a decrease in speed, but 100-200 times 
more, that IS a lot... Isn't a plus one for Ruby...

>If you only have a few optimized low level algorithms that are easy to
>interface you could write a c extension and use ruby as a scripting language.
>  
>
I guess that could indeed be the approach to take then, start with a 
high level, full implementation of the algorithm in Ruby, and when the 
algorithm is optimized, rewriting kernels (intra-prediction, motion 
estimation, ...) in C and use them as C extension.

>Maybe you could explain a little bit more what exactly you are looking
>for and what you want to do with a ruby -> c translater (what kinds of
>code should it translate ?).
>  
>
I would not expect that ruby->C translator could translate a full SVC 
application to C with a push of the button. That would be Utopia, but if 
it could handle kernels, which are just a bunch of methods in a class, 
eventually, that would be great.

I will continue writing some test examples, thinking of how I can 
replace some of their tools with a Ruby variant, and try to convince 
them with the simplicity of such tools compared with their C 
implementation. It will be a hard one, but a nice time-spending then 
rewriting C++->C so their tools can support it.