Prev: Code review of n00b code and unit tests if you dare ...
Next: bond 0.2.0 - Improving Irb's Autocompletion
From: bwv549 on 7 May 2010 12:16
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!
From: MrZombie on 10 May 2010 09:09
On 2010-05-07 15:50:11 -0400, Seebs said:

> On 2010-05-07, bwv549 <jtprince(a)gmail.com> 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.

From: Charles Calvert on 13 May 2010 11:44
On Fri, 7 May 2010 09:16:36 -0700 (PDT), bwv549 <jtprince(a)gmail.com>
wrote in
<3aac7538-b703-4604-8280-79f1d98d5260(a)j36g2000prj.googlegroups.com>:

>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 Seebach 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]
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
(703) 580-0210 | Research
From: bwv549 on 26 May 2010 14:28
Thanks to all for their thoughtful responses! I'll pass it along.
 | 
Pages: 1
Prev: Code review of n00b code and unit tests if you dare ...
Next: bond 0.2.0 - Improving Irb's Autocompletion