From: "ara.t.howard" <ara.t.howard@...>
Date: 2010-12-19T03:49:30+09:00
Subject: Re: Ruby and science ?

------=_Part_18_2607151.1292698167911
Content-Type: multipart/alternative; 
	boundary="----=_Part_19_29862833.1292698167912"

------=_Part_19_29862833.1292698167912
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


i worked in science using ruby for many years.  it is true that sometimes 
various libs (narray, ruby gsl, netcdf, opendap bindings, etc) require some 
tweaking to compile and get running.  my observation, during the decade or 
so doing this work, is that this issue is not exclusive to ruby at all: if 
one is going to be a serious scientific programmer then one needs to 
understand all sorts of things 'normal' computer scientists don't normally 
consider any more: compiler flags, endianness, huge word sizes, specicalized 
hardware interfaces, dedicated super computer compiler tool chains, and 
generally shoddy source control and distribution mechanisms (here - i wrote 
this for f77 10 years ago...) dominate the scientific programming landscape. 
 my experience has been that this is as true for python as it is for fortran 
as it is for ruby.  understanding the black art of object files, linkers, 
and compiler implementations is just a fact of life when one is pushing the 
boundaries of what machines do commonly.  it is no reason to give up on 
ruby, or any other language for that matter.  if you choose, say, R, then 
maybe you'll solve certain problems more quickly, but hit roadblocks in 
others, like accessing data via some obscure ftp based protocol...  needing 
to understand complier black art to make computers go fast i can live with, 
but hacking makefiles to do common tasks i abhor - pick your poison.

------=_Part_19_29862833.1292698167912
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><div>i worked in science using ruby for many years. &nbsp;it is true th=
at sometimes various libs (narray, ruby gsl, netcdf, opendap bindings, etc)=
 require some tweaking to compile and get running. &nbsp;my observation, du=
ring the decade or so doing this work, is that this issue is not exclusive =
to ruby at all: if one is going to be a serious scientific programmer then =
one needs to understand all sorts of things 'normal' computer scientists do=
n't normally consider any more: compiler flags, endianness, huge word sizes=
, specicalized hardware interfaces, dedicated super computer compiler tool =
chains, and generally shoddy source control and distribution mechanisms (he=
re - i wrote this for f77 10 years ago...) dominate the scientific programm=
ing landscape. &nbsp;my experience has been that this is as true for python=
 as it is for fortran as it is for ruby. &nbsp;understanding the black art =
of object files, linkers, and compiler implementations is just a fact of li=
fe when one is pushing the boundaries of what machines do commonly. &nbsp;i=
t is no reason to give up on ruby, or any other language for that matter. &=
nbsp;if you choose, say, R, then maybe you'll solve certain problems more q=
uickly, but hit roadblocks in others, like accessing data via some obscure =
ftp based protocol... &nbsp;needing to understand complier black art to mak=
e computers go fast i can live with, but hacking makefiles to do common tas=
ks i abhor - pick your poison.</div>
------=_Part_19_29862833.1292698167912--

------=_Part_18_2607151.1292698167911--