------art_22_17257931.1292698825090
Content-Type: multipart/alternative; 
	boundary---art_23_1830328.1292698825091"

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



> Apart from perhaps MacRuby calling ObjC and IronRuby calling .NET,
> JRuby calling Java is *by far* the easiest way to pull in external
> libraries. C extensions and FFI are nowhere near as easy, and never
> 

> will be.

> I always recommend using JRuby to take advantage of Java/JVM libraries
> over C extensions and FFI, but of course I'm a bit biased :)


of course JRuby is a fantastic tool for many use cases, but i've personally 
found science to be perhaps the worst possible application of it.  these 
reasons are quite simple:


- speed.  when you need something to be big or fast in science, generally 
even c won't cut it.  fortran is still used in maybe 80% of big weather 
systems for a reason: the compilers are generally doing faster floating 
point ops than the equiv c compilers.  one can bridge fortran -> c -> ruby 
quite easily (narray does this, gsl does this, etc) and it's  place where 
JRuby actually makes the job much harder.  Java, of course, isn't even in 
the ballpark.


- OS integration: the general approach to making ruby faster is to use 
parallelism.  the best way is to run lot's of processes.  JRuby's interface 
to the operating system level primitives for this (fork, et all) make this 
really really hard, close to impossible, to deal with simply.  Mmap is 
another great example of something you want at your finger tips in 
science...  Interfaces to hardware boards connected to a research device, 
etc.  I think any research based science makes getter close to the metal a 
requirement.


- start up time.  related to the above is the fact that science tends to 
lead to many small programs running very often.  map reduce jobs, cron jobs, 
process pipe lines of related algorithims, toolkits made extensible via file 
based processing, tons of processing of stdin/stdout tend to be facts of 
life when algorithm writers produce systems as a side effect.  it's not 
pretty, but it is a fact i've seen repeated over and over.


i am definitely aware of some projects which make really heavy use of java 
and there, JRuby sure would be an awesome tool but my personal experience is 
that anything related to the JVM is a total non-starter.  YMMV.



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

<meta charset="utf-8"><span class="Apple-style-span" style="color: rgb(34, 34, 34); "><p>&gt; Apart from perhaps MacRuby calling ObjC and IronRuby calling .NET,<br>&gt; JRuby calling Java is *by far* the easiest way to pull in external<br>&gt; libraries. C extensions and FFI are nowhere near as easy, and never<br>&gt;&nbsp;</p><p>&gt; will be.<br></p><p>&gt; I alwaysecommend using JRuby to take advantage of Java/JVM libraries<br>&gt; overxtensions and FFI, but of course I'm a bit biased :)</p><p><br></p><p>of course JRuby is a fantastic tool for many use cases, but i've personally found science to be perhaps the worst possible application of it. &nbsp;these reasons are quite simple:</p><p><br></p><p>- speed. &nbsp;when you need something to be big or fast in science, generally even c won't cut it. &nbsp;fortran is still used in maybe 80% of big weather systems for a reason: the compilers are generally doing faster floating point ops than the equiv compilers. &nbsp;one can bridge fortran -&gt; c -&gt; ruby quite easily (narray does this, gsl does this, etc) and it's &nbsp;place where JRuby actually makes the job much harder. &nbsp;Java, of course, isn't even in the ballpark.</p><p><br></p><p>- OS integration: the general approach to making ruby faster is to use parallelism. &nbsp;the best way is to run lot's of processes. &nbsp;JRuby's interface to the operating system level primitives forhis (fork, et all) make this really really hard, close to impossible, to deal with simply. &nbsp;Mmap is another great example of something you wantt your finger tips in science... &nbsp;Interfaces to hardware boards connected to a research device, etc. &nbsp;I think any research based science makes getter close to the metal a requirement.</p><p><br></p><p>- start up time. &nbsp;related to the above is the fact that science tends to lead to many small programs running very often. &nbsp;map reduce jobs, cron jobs, process pipe lines of related algorithims, toolkits made extensible via file based processing, tons of processing of stdin/stdout tend to be facts of life when algorithm writers produce systems as a side effect. &nbsp;it's not pretty, but it is a fact i've seen repeated over and over.</p><p><br></p><p>i am definitely aware of some projects which make really heavy use of javand there, JRuby sure would be an awesome tool but my personal experience is that anything related to the JVM is a total non-starter. &nbsp;YMMV.</p><p><br></p></span>
------art_23_1830328.1292698825091--

------art_22_17257931.1292698825090--