From: Joshua Ballanco Date: 2009-05-18T00:25:56+09:00 Subject: Re: what could be improved in Ruby for Science? On May 16, 2009, at 8:26 AM, Robert Dober wrote: > On Wed, May 13, 2009 at 9:52 PM, Joshua Ballanco > wrote: >> Now, there's another problem in that, as has been mentioned, >> Python and Perl are technically no better than Ruby for this sort >> of work. >> Of course, the flip side of that is that Ruby is no better than >> they are, > you must be kidding here ;) No it is me who's kidding, let me try to > explain please: > > Ruby has qualities Perl and Python can only dream of, and Perl and > Python have some that elude me, I admit. > However I guess that most people on this list share the view that Ruby > just is better for most jobs. > > I guess that, and you see I do take your statement very seriously that > it would be "our" job to pass this message on. Hmm maybe we need, > "What Ruby (and only Ruby) can do for you" blog :). There's an old adage in software development (or, as old as an adage about 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 Ruby 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 and care and decorated with ancient symbols of strength and power. Now, the average scientific programmer is approaching the problem as if it were meat to be chopped, so they reach past the Katana in your outstretched hand for the dirty, dull, and nicked meat cleaver. In other words, it's not that scientific programming _can't_ take advantage 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 blog. However, if somebody wanted to set something like that up, I'd be happy to participate. Maybe the guys over at the "Ruby Best Practices" blog would be interested? As for my suggestions about prototype inheritance and first-class functions (and I believe that I'm probably the only one making much noise about this recently), let me explain quickly: I'm doing evolutionary modeling. The basic idea is to represent cells, and what those cells can do, in Ruby code. 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 other 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 new ways too... ...just thoughts...use them as you see fit - Josh