Ease of porting (translating) ruby to C (vs. python)?

In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can “easily be ported to C because of its strictness.”

How easy is it to port (translate) ruby code into C? Anyone with
experience in doing this? I’ve done a little and it seemed very easy,
but I’ve never translated python into C so I can’t compare.

Discussion on alternatives (Inline, using C extensions, NArray,
#include ruby, etc.) is welcome, but I’d like to keep the main focus
on translating to C for this thread.

Thanks in advance!

On 2010-05-07, bwv549 [email protected] wrote:

In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can “easily be ported to C because of its strictness.”

Let me be as polite as possible:

That’s a bunch of bullshit.

I would find it reasonably difficult to port code from ANY scripting
language to C – and I’m pretty good at C. “Strictness” does not make
it
easier to port python to C. Nor does it make it easy to port shell to
C,
or perl to C, or anything else. I am afraid the lead is full of crap.
Sometimes this happens.

Furthermore, porting stuff from an OO language to C is almost certainly
absolutely the wrong thing to do. The correct solution might be to
write
a plugin module for the language which translates specific functionality
into
raw C calls for performance reasons, but if you have a design that makes
any
sense at all in an OO language, translating it to C is stupid.

In any event, what you have here is a social problem, not a technical
problem – you have someone in charge who doesn’t know what’s going on.

-s

On Fri, May 7, 2010 at 11:20 AM, bwv549 [email protected] wrote:

on translating to C for this thread.

Thanks in advance!

Hi. I don’t know about “translating” Ruby into C, I would probably write
in
C to begin with so that you don’t get side tracked using some nice
functionality that Ruby provides that C does not.

However, Ruby does support a procedural paradigm, and you can write it
exactly like your C code (this is how I started, but I don’t think it
provides any real benefits, I only used it b/c Ruby doesn’t care how
large
your numbers are, and I needed to work with enormously large numbers)

I don’t know your reasons for wanting to use C, I assume for optimizing
certain parts of your algorithm, or dealing with certian low level
functionalities. In this case, if you are using the default Ruby (Matz’s
Ruby Interpreter, which is written in C), then you might consider
Ruby-Inline, which is an elegant and powerful library written by Ryan
Davis.
You can see a few examples here
rubyinline | software projects | by ryan davis It allows you to write
your C code directly inside of your Ruby code. Then you can have a nice
amalgamate of both Ruby and C, depending on what the situation requires.

Discussion on alternatives (Inline, using C extensions, NArray,
#include ruby, etc.) is welcome, but I’d like to keep the main focus
on translating to C for this thread.

Rubinius is pretty fast these days…

-rp

On Fri, May 7, 2010 at 16:02, Roger P. [email protected]
wrote:

Discussion on alternatives (Inline, using C extensions, NArray,
#include ruby, etc.) is welcome, but I’d like to keep the main focus
on translating to C for this thread.

Rubinius is pretty fast these days…

and if you’re familiar with C, inline or C extensions are really easy
once the bottlenecks are identified.

in my code, I’ve found that the number crunching can often be handled
by a function or two written as an extension, and then the beauty of
ruby can be used for main logic.

finally, I must admit that I agree with Seebs. Porting code written
in either Python or Ruby to C is far from trivial if there is any
complexity to the code. The only way to make it easy is to use a
subset of the language capabilities and write procedurally.

Cameron

On Fri, May 7, 2010 at 10:20 AM, bwv549 [email protected] wrote:

In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can “easily be ported to C because of its strictness.”

There’s lots of good reasons to use Python for scientific computing,
such as
the excellent SciPy and NumPy libraries. However, the reason you stated
is
not one of them.

There is the Psyco compiler which lets you use a subset of Python syntax
to
optimize performance critical portions of your code, however Python
itself
certainly cannot “easily be ported to C”. There was the Starkiller
Python
compiler which compiled to C++, however it was never released.

The main reason to use Python over Ruby for scientific computing is the
community of scientific computing users of Python is larger and there
are
better libraries available.

What is the nature of the project? If it is solely intended for research
then I cannot see the benefit of even questioning translatability to C.

If it is an issue of speed, it has been stated already that time
critical
components of the application can be written in C and integrated into
the
application.

As another point, solving problems with C can be a problem to solve in
itself. Often times the “automatic” nature of higher level languages
frees
up the developer to spend more brain power on the actual problem and
less on
language semantics.

2010/5/7 Tony A. [email protected]

On Fri, May 7, 2010 at 4:35 PM, Cameron McBride
[email protected]wrote:

I do not agree, but this is becoming the typical rant and somewhat
off-topic. :wink: Anyhow, there are some libraries that are better
developed for python (e.g. plotting in something like matplotlib), but
functionally there are a lot of equivalent libraries available for
ruby as well (GSL, NArray, etc).

What’s a Ruby equivalent of SciPy?

And if you re-read what I said, I don’t see how you’re disagreeing with
me.

On Fri, May 7, 2010 at 16:43, Tony A. [email protected]
wrote:

The main reason to use Python over Ruby for scientific computing is the
community of scientific computing users of Python is larger and there are
better libraries available.

I do not agree, but this is becoming the typical rant and somewhat
off-topic. :wink: Anyhow, there are some libraries that are better
developed for python (e.g. plotting in something like matplotlib), but
functionally there are a lot of equivalent libraries available for
ruby as well (GSL, NArray, etc).

I have to make this point since I’ve been using ruby for many years to
do science (since ~2002) without much pain at all.

Cameron

On 2010-05-07 15:50:11 -0400, Seebs said:

On 2010-05-07, bwv549 [email protected] wrote:

In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can “easily be ported to C because of its strictness.”

Furthermore, porting stuff from an OO language to C is almost certainly
absolutely the wrong thing to do. The correct solution might be to write
a plugin module for the language which translates specific functionality into
raw C calls for performance reasons, but if you have a design that makes any
sense at all in an OO language, translating it to C is stupid.

From my understanding, both Python and Ruby are able to use native
C extensions. It means you could use C for any speed-critical
number-crunching
function. For the sake of clarity, I’d suggest sticking to the least
amount of C
you can manage, and use either Python or Ruby to glue the rest together.

The rest is a matter of choice and comfort. While I prefer Ruby for its
flexibility,
others might prefer Python for clarity. Now, understand that Python
code doesn’t
magically make sense for those who read the source, it just enforces
significant
formatting that will ensure the source is uniform (at least to some
extent).

As the significant number-crunching could be done using C, I doubt the
speed
would be greatly impaired by using any of the other two languages. So
yeah,
that’s that.

I took this offline since I feel it’s off-topic to the OP.

What’s a Ruby equivalent of SciPy?

I have found NArray + GSL quite capable. There are several others that
subscribe to a more “complete” picture, but I don’t like such a large
bundle so I don’t agree that SciPy is “better”.

But it’s a matter of taste and workflow – so it’ll vary by person.
Luckily we have several good choices in both languages.

Cameron

On Fri, 7 May 2010 09:16:36 -0700 (PDT), bwv549 [email protected]
wrote in
[email protected]:

In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. The lead knows that python
can “easily be ported to C because of its strictness.”

First, I agree with Peter S. that this is nonsense.

Second, why would you port code from either language to C? Is it to
gain performance in areas of the code where Ruby/Python isn’t
sufficiently performant? If so, then you’re putting the cart before
the horse. Here is the correct order:

  1. Write the code.
  2. Test performance.
  3. If performance is not acceptable, profile the code and identify the
    bottlenecks.
  4. Examine the bottlenecks to see if the performance can be improved
    in the current language, e.g. by switching algorithms or tweaking
    generic algorithms to work better with your specific data.
  5. Make those changes and retest. You might need to experiment with a
    few versions.
  6. If the changes result in insufficient improvement, then look at
    implementing them in C, compiling to a library and calling into that
    from Ruby/Python.

Note that this assumes that you do not have a current code base
written in C. If you do, and it is well tested and performant, then
do this instead:

  1. Write the code that you need and that does not exist in C, using
    Ruby/Python.
  2. Write the wrappers for the C code and integrate.
  3. Follow steps 1 … 6 above, applying step 6 to the code written in
    Ruby/Python.

[snip rest]

On 5/13/10, Charles C. [email protected] wrote:

few versions.
6. If the changes result in insufficient improvement, then look at
implementing them in C, compiling to a library and calling into that
from Ruby/Python.

While one should not get overwrought about performance ahead of time,
it is something that should be considered at design time. I am not a
subscriber to the notion that many seem to promote that performance
should not be considered at all until you prove with benchmarks that
something is too slow. I don’t need to run a bubble-sort to know that
it’s slow.

On Thu, May 13, 2010 at 11:11 PM, Caleb C. [email protected]
wrote:

While one should not get overwrought about performance ahead of time,
it is something that should be considered at design time. I am not a
subscriber to the notion that many seem to promote that performance
should not be considered at all until you prove with benchmarks that
something is too slow. I don’t need to run a bubble-sort to know that
it’s slow.
Seconded!
Some time in the 1920s a famous British aeronautical engineer/theorist
(so famous I can’t remember his name!) gave a lecture pointing out
that whilst individual parts of an aeroplane gave rise to perhaps an
extra 3% to 5% drag, the overall effect of the sub-optimal design of
the parts was a serious increase in drag over what it could be reduced
to. (I made the numbers up, but the gist is true.)

On Thu, May 13, 2010 at 9:07 PM, Colin B.
[email protected]wrote:

that whilst individual parts of an aeroplane gave rise to perhaps an
extra 3% to 5% drag, the overall effect of the sub-optimal design of
the parts was a serious increase in drag over what it could be reduced
to. (I made the numbers up, but the gist is true.)

Which kind of brings this full circle:

Good design will always beat the pants off of hasty premature
optimization,
no matter what language you use, and is an important lesson the guy the
OP
is dealing with has yet to learn.

Jason

Thanks to all for their thoughtful responses! I’ll pass it along.

On Fri, May 7, 2010 at 10:20 AM, bwv549 [email protected] wrote:

In a very small bioinformatics group I know of, they are deciding
whether to code mostly in python or ruby. […] I’d like to keep the main
focus

on translating to C for this thread.

So just one question here: why C? Is your group familiar with other
numerical computing-focused languages, such as Fortran? While Fortran
isn’t
exactly a good language, in my opinion it’s a lot more accessible to
scientists and for numerical computing purposes as fast (or sometimes
even
faster) than C.

Is there some cultural reason why your group would prefer C to Fortran
or
other as-fast-as-C languages?