I’ve been building up bits & pieces of Ruby news for weeks and weeks, so this is a pretty sizable bright-red glob.
Sun · Starting with my employer; Check out developers.sun.com/ruby. Our Ruby work has been a low-overhead guerrilla effort so far, and while it’s been going well, it’s nice to see a little bit of corporate organization setting in.
On the less-corporate side, there’s the work we’re doing with the University of Tokyo. Charles Nutter summarizes in University of Tokyo and JRuby Team to Collaborate on MVM. The potential benefits of having multiple virtual machines in one image—and I’m talking about all the Rubies including the J and .NET flavors—are pretty obvious. It’s a nontrivial problem, which is why we’re doing it on a research basis; so don’t hold your breath.
Oh, and then there’s Andrew Binstock’s latest IDE shootout, Eclipse 3.3 or NetBeans 6.0? If you care about the overall verdict go read the article, it’s good, but what I wanted to quote was this: “These features make NetBeans the best IDE currently available for Ruby development.” Mind you, I don’t expect either Eclipse or TextMate to stand still.
Finally, I observed back during the Wide Finder work that Ruby wasn’t running that well on the T2. I’m glad someone’s addressing that: see Darryl Gove’s Ruby performance gains on SPARC.
Duby · No, this isn’t an even shorter name for the That President, nor can you smoke it to get high, it’s evidence that Charles Nutter ought to be paying us, he’s having altogether too much fun.
Gemstone · Avi Bryant’s Ruby and other gems describes a fascinating framework built by Gemstone, a New York outfit you probably never heard of. I personally think that something like this might be huge in terms of making Rails scale effortlessly to really big problems.
The Other Side · Not everyone is on the Ruby bandwagon, you know. Karsten Wagner, in Static vs ‘dynamic typing’, part 2: The personality-factor, offers about as reasoned a presentation of the virtues of static typing, particularly in the large-project context, as you’re going to find anywhere. Example: “Static types create global constraints which describes your program in a non-local way.” I’m still on my Ruby honeymoon and remain unconvinced. Perhaps the following quote is central: “And that's is my problem with real TDD: It's again my laziness. Writing and maintaining those lots of tests is essential for this method to succeed - and I'm simply to lazy to do this.” Well, I’d argue that you shouldn’t do any kind of a large project these days without TDD, but obviously, some people do, and maybe for them, static typing has a positive ROI.
While we’re visiting nay-sayers, I’ve certainly enjoyed the ferocious monkeypatching debate that’s been swirling about Ruby-land. It’s obvious that as long as Ruby remains Ruby, monkeys will continue to be patched. But it’s also obvious that it’s reasonable to worry about this. The reason-to-worry position is best outlined by Gilad Bracha in Monkey Patching; he admits that “So far, I have no firm conclusions about how to best address the problems monkey patching is trying to solve” but concludes “The problems it induces far outweigh its benefits. If you feel tempted, think hard about design alternatives. One can do better.” I particularly enjoyed his educated snottiness about the JCP.
In Conclusion · Obie Fernandez writes about Big Name Companies Using Ruby on Rails. Ah, Ruby, I’m reminded of the Beatles’ Honey Pie: “She was a working girl, East of Japan way/Now she’s hit the big time, in the USA”.
Contributions
Comment feed for ongoing:
From: Masklinn (Mar 27 2008, at 01:13)
> I’m still on my Ruby honeymoon and remain unconvinced
I think that's because of a simple and single fact: the cost of static typing in "popular" languages is too high when balanced with the earnings.
Everything has a cost, and the language's choice of typing is no different. Dynamic typing's costs include, for example, that nearly all errors are late bound and can only be detected by executing the program (not completely true of course, there are fairly good/useful static analyzers for dynamically typed languages e.g. Erlang's Dialyzer). In a statically typed languages, one of the costs is obviously that you can spend some time before having your code compile, let alone run.
But the "popular" statically typed languages (C++, Java, C#, ...) add the (unnecessary) cost of having to specify nearly every single type in the system, keeping the compiler as dumb as possible and offloading all the (grunt) work on the programmers.
All that while not even having a type system worth the bother (when will popular languages finally allow me to specify and be able to enforce at compile time non-nullity constraints?)
The result is that programmers in popular statically typed languages have to do a lot of work for very few rewards, and in the end have to rely on runtime-checking of behaviour (unit tests) for nearly everything.
I consider (from a practical point of view) that a static type system really is a compile-time (early and eager) set of constraints, or tests, that can be easily expressed and written and are checked without my direct influence. The problem is that e.g. Java's type system is so worthless I end up having to write as many tests as in e.g. Python (so the static type system gets me nothing) and not only that but Java's type system, syntax and static typing makes tests more annoying to write (there is more boilerplate, I can't start with tests alone as it won't even compile, ...)
The result is that while Java's static type system and typing syntax make the cost of writing Java much higher than that of writing Python (not to mention the rest of the language), it doesn't lower my testing workload and only makes the system minutely more resilient.
And this is why static type systems in popular languages have abysmally low ROIs, in the deep negatives, for many people (you and me included)
[link]
From: Norm Green (Mar 27 2008, at 06:31)
Tim,
Although we have a sales office in NYC, GemStone world HQ is in Portland, OR.
Norm Green
GemStone Systems Inc.
[link]