now a zip file at the bottom of the directory, can also be downloaded as a zip file here

I haven't listened to them all yet, but the Ishizaka's recordings sound really good. I think the Goldberg Variations can tolerate a range of styles.

I few years back I wanted to know what the Goldberg Variations might sound like "uninterpreted", at least as far as that is practically possible. I downloaded Dave Grossman's midi files and the Blanchet 1720 Harpsichord soundfont. I played a little with the registers and cleaned up the midi files a touch. Then I recorded them with timidity using a dash of reverb and used lame to turn out some mp3s (so all done with open source tools on linux).

Download: The Goldberg Variations realized on the Blanchet 1720

I'm biased, but I *really* like them, far better than any of my other recordings. Case in point, compare the 13th variation with Ishizaka's. While I enjoy different interpretations (I like her version, too), I also think the uninterpreted version keeps any one melody from being emphasized too much, thus preserving a balanced polyphony a little more.

They are also CC0 license, so copy them or sell them, or whatever. If you like them, drop me an email (in the license).

I haven't done the calculations, but I'm guessing that there have been more lines of code committed to sciruby in the past few months than to scipy.

OT: It's one of the great little pieces he wrote when he was younger and a little more reckless with his style. When we stumbled on it a while back it inspired my brothers and I to write a string of compositions with a little of the same panache.

Unfortunately it ignores the alternative of just using Python

The option of using python is implicitly rejected. Why would the contributors spend time on sciruby when they clearly know scipy exists? Speaking for myself, I've used python and scipy (both numpy and matplotlib) for several projects, but I much prefer coding in ruby to python. All the functionality of scipy isn't going to be duplicated with sciruby, but if the most common use cases are implemented, then I can use ruby for most projects.

this is a misguided waste of time

why? It's easier to re-implement (i.e., borrow from scipy) than implement in the first place, so it doesn't take all that much time. And, as pointed out, this is currently a minor project compared to scipy, so if it is a waste of time then it's not a lot of it.

Python has a "there is only one true way" mentality, so there isn't a lot of room to try and innovate within scipy. Perhaps sciruby will innovate in significant ways and scipy will draw a little from it one day.

and it's nearly inactive anyway

The fellowship and nmatrix commit history would suggest otherwise.

The slowdown in commits to sciruby proper is due to the recent efforts on nmatrix (the subject of the story). The github commit history is easily accessible and shows a flurry of activity. Many projects associated with sciruby are also not housed directly under the sciruby name (e.g., rubyvis)

There are a million minor projects like this that similarly aren't newsworthy enough to discuss

... yet here we are...

The lack of comparable scientific libraries is the primary reason many folks choose python over ruby. It's true that sciruby is young and doesn't yet compete with scipy/numpy, but the point is that it continues to pick up steam. A lot of folks who would rather code in ruby think this matters.

I recently switched to i3: loads instantly; easily manages multiple workspaces and windows; and is very configurable. It even has a system tray taskbar to load the network manager applet (important if you weren't one of the folks that wrote iwconfig) and the gnome-sound-applet. I've used gnome for a long time, and I can tolerate linux mint's version (my wife thinks it's pretty usable). But if you are going to use multiple programs to code or whatever a tiling manager is really the only way to go...

I teach programming to beginners using ruby.

Consistent object model: list.length vs. len(list)

Enumeration is just another method of objects that are enumerable. list.each {|item| .... } simple.

[beginners don't really need speed or to write C extensions, but when they eventually get to that point it's trivial to embed C/C++ in ruby with FFI::Inliner, and my intermediate students have great success with this approach]

Method calls that return a boolean should have a question mark: any? all? include? block_given? Consistent and readable. The intent is obvious.

Everything returns an object including if/else statements.

Concerning the previous statements regarding "magic" and ruby: ruby has no "magic". A consistent object model from top to bottom, closures, and open classes make it easy to do complex things in just a few lines of code. This just means the language scales well.