Shot,

So far the discussion has been very rational and focused on technical  
merits. It's also worth considering enlightened self-interest:

If you are planning on working in quantitative finance then you  
should use C++ because that is the language of choice for  
quantitative finance. If you expect to work in non-telecoms IT then  
you should use Java because that will be more valuable.

If neither are issue you should certainly use Ruby because it will be  
more productive - the time you spend tuning Ruby is probably less  
than the time you would spend waiting around for C++ builds to finish  
and chasing down pointer bugs and mysterious crashes. And if the time  
isn't less it will at the very least be more fun!

-Peter

On Jan 19, 2007, at 1:17 PM, Shot (Piotr Szotkowski) wrote:

> Thanks a lot for your reply, Ryan!
>
> // Also, as to not pollute the list with separate mails: thanks to
> // everybody else who commented in this thread! I learned more in the
> // past two days than I hoped to learn 'till the end of January!
> // Unfortunately, it might mean I'll come back with more  
> questions... ;)
>
> Ryan Davis:
>
>> On Jan 17, 2007, at 2:00 AM, Shot (Piotr Szotkowski) wrote:
>
>>> symbolic functional decomposition of FSMs for FPGA implementation
>
>> Some work has been done in this area to some extent. Check
>> out RHDL from Phil Tomson. I believe it is pure ruby only.
>
> Thanks, again! I'm already eager to drill into his Ruby-interpretation
> of an FSM, and it's not even weekend here yet... :)
>
>>> my gut feeling is that pure Ruby will end up
>>> being *way* too slow and memory-inefficient.
>
>> Gut feelings are often wrong. Especially in this arena.
>
> I hope this one is. Still, my supervisor's C++ classes are quite
> optimised, and it's not rare for a decomposition to run for two days
> straight; hopefully the benchmarks needed to prove the scientific  
> value
> of my thesis are of the less-time-consuming kind.
>
>> You can also take advantage of very easy
>> parallelism available through systems like rinda.
>
> Thanks for pointing out Rinda, I'll definitely take a closer look.
> Unfortunately, decomposition is a highly iterative process, so I doubt
> it's at all paralellable (some parts of a single iteration might be,
> though).
>
>>> 2. Ruby with C extensions.
>
>> This is the approach I choose most of the time. Just Do It.
>
> I talked with my supervisor, and he said that if going with Ruby means
> I'll show up with anything that actually works even just a bit sooner,
> then he's all for it. :)
>
> Thanks a lot for pointers to rubyprof and zenprofiler!
>
> -- Shot, currently in the 'Ruby or Lua? Ruby or Lua?' mode...
> -- 
> I'm not much of a kernel hacker, but a quick (and not very efficient,
> granted) fix could be to make the offset an extern variable, yes?
> That would force the compiler to fall back on the basic "your gun,
> your foot, your choice" memory model.                    -- jtv, LKML
>

Peter Booth
peter_booth / mac.com
917 445 5663