Re: what could be improved in Ruby for Science?

On Sun, May 17, 2009 at 5:25 PM, Joshua Ballanco <[e-mail]> wrote=
:

> There's an old adage in software development (or, as old as an adage abou=
t a
> 50 year old profession can be) that if the customer does not know about a
> feature of your program, then that feature doesn't exist! I agree that Ru=
by
> has many strengths over Perl and Python for scientific programming. If I
> didn't, I wouldn't be using it. However, the strengths don't quite align
> with how I think most scientists approach computing. That is, Ruby is a
> beautiful language. Call it a Katana, beautifully crafted with patience a=
nd
> care and decorated with ancient symbols of strength and power. Now, the
> average scientific programmer is approaching the problem as if it were me=
at
> to be chopped, so they reach past the Katana in your outstretched hand fo=
r
> the dirty, dull, and nicked meat cleaver.
Hmm I am a very lazy guy and I never could become friends with Python
because it was just standing in my way. ( Perl was not, however :)
> In other words, it's not that scientific programming _can't_ take advanta=
ge
> of Ruby's enhanced abilities, it's that they _don't_. I think an "Annie
> Oakley" blog would be a great idea ("Anything you can do I can do better"=
)!
> Unfortunately, (ironically, even) I don't have the time to run such a blo=
g.
> However, if somebody wanted to set something like that up, I'd be happy t=
o
> participate. Maybe the guys over at the "Ruby Best Practices" blog would =
be
> interested?
This is truly a great idea, however I somehow tend to disagree with
your assessment about the needs to see Ruby's full powers to
appreciate it.
To put it constructive: Whatever you can do, I can do "simpler"!
This is a challenge I really would like to take :)
>
> As for my suggestions about prototype inheritance and first-class functio=
ns
> (and I believe that I'm probably the only one making much noise about thi=
s
> recently)
it is almost sure now, *nobody* reads my blog, but let us see...
>, let me explain quickly: I'm doing evolutionary modeling. The
> basic idea is to represent cells, and what those cells can do, in Ruby co=
de.
> Now, I could (and very well might) write a DSL for the problem space. If
> Ruby had prototype based inheritance and first-class functions, on the ot=
her
> hand, a DSL wouldn't be needed as objects could sub in for evolving cells=
.
>
> So, it's not just the classic compositional patterns that would be easier=
 to
> implement, but fun new paradigms that could be approached using Ruby in n=
ew
> ways too...
>
> ...just thoughts...use them as you see fit
Oh I will ;) I find them fascinating, maybe we need something like a
very high level bytecode, I have already registered a Rubyforge
project for this but lost speed. My idea was to serialize methods and
send them to a remote vm to be executed there (potentially with URL
based closures and maybe even a network based local variable lookup ).
I always wondered what might happen if a "send :+" mutates to a "send :-" ;=
).
Seriously I will try to give this some more thought about how lambdas
could be "modified", I guess composition is the first idea that comes
into mind.

Cheers
Robert
--=20
Toutes les grandes personnes ont d=92abord =E9t=E9 des enfants, mais peu
d=92entre elles s=92en souviennent.

All adults have been children first, but not many remember.

[Antoine de Saint-Exup=E9ry]