61–63 of 63 posts
God forbid you use existing mature tools appropriate to your task.
And while we're at it, may he forbid the co-existence of emacs, vim, and textmate; java, C++, C#; javascript and dart; KDE, gnome, enlightenment, fluxbox, fvwm, icewm, metacity, compiz, wmii, monad; ubuntu, debian, gentoo, redhat, and arch; bash, csh, and zsh ... nothing good ever comes out of approaching a problem from a new angle.
Earlier quoted context omitted.
The resurrection of SciRuby is great news, but the use of the GPL was one of the first things I noticed, and I strongly recommend using a more permissive license. The MIT license would be a good choice. In addition to avoiding the fears associated with the viral nature of the GPL, using the MIT license would be more in line with the culture of the Ruby community. Most Ruby software I know of (though not, strangely en…
The main reason we initially chose GPL, I think, was because while we had strong respect and appreciation for the MIT-license-like Ruby culture, we were more concerned about the science culture. In other words, what could we do to provide another arm-twisting mechanism to force publishing authors to release their source code? We wanted to facilitate openness among people who might join the Ruby community by way of Sc…
Earlier quoted context omitted.
The same arguments could have been used when scipy was starting up: * Why did folks build scipy when there was PDL? Just to avoid a few sigils? * Why build scipy when R had been released just before? * Why didn't they just support matlab/octave? (scipy and matlab are so close in syntax anyway) * If syntactical differences are not enough to justify a new scientific library, why not just stick to Fortran, or C/C++? One…
SciPy is not currently starting up. There were other open-source alternatives to Matlab in 1995, but certainly none with the scope and community of SciPy in 2011. That full-spectrum alternative is not Octave, not now or then. R is a very nice statistics dsl with prevalence in publications and thus a trove of code (arguments much weaker at that time) - but there is no PyMol or MayaVi in R for good reasons. For the rec…
You seem to be saying that ruby is python, just with perl's inconsistency and unreadableness. The syntax differences between python and ruby (more than 2% IMHO) amount to very large differences in code organization. The ruby community places a high premium on brevity and clarity, and ruby's flexible syntax facilitates this. Part of the reason monolithic code bases are more rare in ruby is because we tend to do more with less code. We are talking about two very different forests.
We weren't going to be working on Theano or SAGE anyway, just doing basic science computation to solve real problems in our fields. That's really the problem, we find ourselves quite productive doing science in ruby at the moment, despite its relative immaturity in this area. It's hard not to imagine what we could do with a few more foundational tools. It really is a small cost to enable us to be able to do science in ruby. Plus, building scientific computing libraries is good fun. Every community should have the chance. As Abe Lincoln suggested, 'Let not him who is houseless pull down the house of another; but let him labor diligently and build one for himself.'
Is it so terrible to want to do science in the language you most enjoy and are most comfortable with? To continue with the maladroit quoting of Abe Lincoln, "it's best to not swap horses when crossing streams."
I made the point further down, but will restate it: if ruby hadn't persisted in existing (the nerve!), would django exist today? I find it hard to believe that this is a zero-sum game, and I wish python and scipy every success. Perhaps the most valuable scipy contribution we could make will come by making sciruby something worth borrowing ideas from?