------ 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>> Apart from perhaps MacRuby calling ObjC and IronRuby calling .NET,<br>> JRuby calling Java is *by far* the easiest way to pull in external<br>> libraries. C extensions and FFI are nowhere near as easy, and never<br>> </p><p>> will be.<br></p><p>> I alwaysecommend using JRuby to take advantage of Java/JVM libraries<br>> 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. these reasons are quite simple:</p><p><br></p><p>- 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 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.</p><p><br></p><p>- 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 forhis (fork, et all) make this really really hard, close to impossible, to deal with simply. Mmap is another great example of something you wantt 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.</p><p><br></p><p>- 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.</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. YMMV.</p><p><br></p></span> ------ art_23_1830328.1292698825091-- ------ art_22_17257931.1292698825090--