The thing about Ruby
It seems that one of the "hot topics" of late in my corner of blogsphere is Ruby.
I first heard of Ruby in 1997. It was being described as a great language for a number of things, especially web apps. Well, everything was supposed to be good for web apps in those days. I remember I was toying around with languages, trying out REBOL, Ruby, Python and others.
REBOL was (and is) almost a DSL, a nice one, too, but still a DSL.
Python, i never did like, (and still don't). You can only trust this much on a language that uses whitespace as a significant token, and not just as a separator.
Ruby, on the other hand, seemed promising. Smalltalk meets Perl.
Perl was always my baby (and still is).
I've done more different things with Perl than many people have done with all the languages they know, combined. And it never let me down; not in reliability, not in elegance, not in power. I've heard complains about the terse syntax more times than I care to remember. But then I realize that the people that complain about Perl are the same ones that complain about algebra, and I understand.
What I don't understand is why we're starting a language war - on a small scale, still a regional conflict - abut Ruby. James McGovern
on one side, a lot of people on the other, from Blaine
and James Robertson
to David Hansson
of 37signals (to be expected, of course ;) )Robert McIlree sums it up pretty well
, and there's not much I'd rather say that he didn't already cover.
I've lived by IETF practices for too long to consider doing otherwise. "Rough consensus, running code" has served me well for the last 20 years, and I expect it will continue being a sane mantra.
Morten comments on a LoudThinking article
The enterprise (...) customers (...) are severely encumbered by legacy because they maintain home grown frameworks from yesteryear rather than having a strategy for moving on. For some reason, they find that they must "defend" their investment rather than leverage common open source frameworks (which are far superior to their home grown stack).
Yes, and the exact same words can be said about Microsoft. Our past stays with us at all times,; still our past is also the ground we stand to take the next step and reach higher, further.
Most enterprises have to maintain something called production systems (look it up on google, if you need); also, most enterprises focus on something called "their business", where IT is just a tool, not a goal in itself. It's so easy to talk about radical change when we have little to lose, isn't it? Now start carrying the weight of supporting production systems, and all-of-a-sudden you're not feeling so light and nimble anymore, and your butterfly-ish tendency to embrace whatever is bright and new and shiny starts to fade away.
And then you start to realize than you do have to keep those 200.000 lines of COBOL on the mainframe, because you just can't take the time, the money and the risk of redesigning your entire core systems because somebody thinks that Ruby or Python are much better and modern languages.
If you come to think of it, the only languages found on those Fortune 200 companies James McGovernor talks about are the ones that have been around long enough to evolve into core systems - COBOL, C, and a few others. Java has made a few incursions into that field - heck, but so has Visual Basic.
So let's all stop judging languages by whether they have been around long enough to have creeped into the core systems, and start looking at what they can do today, and wether or not they can help us solve our problems, today, and help us have less problems tomorrow.
Me, I'm just an old dog; i'll stick to Perl.