I agree with the prototyping thing.  In fact, that is what I just did.  I
have written my network simulator in Ruby.  The core is complete; it is
done.  However, the performance is poor for a network simulator.  When I
start to "replace" the most critical parts to C, it gets 10 times faster.

Now, here is where Ruby really shines.  Because Ruby is procedural,
translating (or porting?) from Ruby to C, other than the data structure,
is relatively straighforward.  Furthermore, because the class and module
definitions in Ruby are never closed, I really can mix and match the parts
in Ruby and C.

I doubt that I can do the same thing with Haskell.  When I start to
"port" from Haskell to C, I guess the C port cannot be run until it is
completely finished; no mix and match like Ruby and C.  Also, although I
don't have the experience yet, my feeling is that it will not be easy to
translate from Haskell to C.  Yes, probably there is some great concept or
code construct that we can write in Haskell; but then when we try to write
it in C, my concern is we will encounter barriers.

Regards,

Bill
===========================================================================
Rafael 'Dido' Sevilla <dido / imperium.ph> wrote:
> On Fri, Aug 23, 2002 at 12:54:53AM +0900, Gavin Sinclair wrote:
>> > (My concern is, if I
>> > really write a Haskell code for a project, then I am stuck with Haskell, I
>> > cannot switch parts of it to C.)
>> 
>> You're not stuck with Haskell; you can port it to Ruby.  Or C.

> Right.  The main use I've had for functional programming languages these
> days is for prototyping.  Once I got comfortable with programming in
> OCaml it was ridiculously easy to create baroque data structures and
> elegant algorithms to manipulate them, in a fraction of the time it
> would have taken to do the same thing in a more low-level language like
> C, mainly because I didn't get the headaches that come from pointer
> tracing and other pitfalls.  From there, the ideas obtained from the
> prototype clarified the process of writing the final C code, which was
> far more elegant, maintainable, and understandable, I suspect, than had
> I not tried to make the prototype and jumped straight to C.

> -- 
> Rafael R. Sevilla <dido at imperium dot ph>	+63(2)8123151
> Software Developer, Imperium Technology Inc.	+63(917)4458925