Ruby and the Opposite of Momentum
kirindave.tumblr.com
kirindave.tumblr.com
With invoke dynamic around the corner (Java 7), it seems that JRuby is Ruby's best hope for a decent runtime.
What I don't get is why all there is such a strong anti-java sentiment in the ruby community. Everyone wants to speed things up by writing native C code. I for one would much rather write java code than C code. It's just as fast and much less shitty. And it runs pretty much anywhere.
So in principle it seems JRuby could have the best of both worlds. But for now I'm having more fun with Clojure. :)
What I find interesting is that most of the JRuby users are first and foremost Rubyists. The JVM users seem to gravitate more to Scala, Groovy, Clojure, Rhino, etc.
(I'm not a Windows user, but if Windows is treated like a third world country by Ruby users, it's going to bite us all in the ass.)
"I want to use Lisp for everything! Oh but what about GC pauses in games?"
I've tried to do RoR on Windows, and it runs like ass. Running poorly and productivity simply don't go together.
Moreover, the .NET platform is anything but stagnant. For Web work, you've got an ORM with LINQ to SQL, and ASP.NET MVC in development. I know some people wouldn't touch it at all, but if you're not scared to drink the flavor-aid there's a lot to do and look forward to.
[Edit: Grammar]
Any reason not to think that the vast majority of Rubyists really don't give a crap about this drama and are quietly, and happily, just going about hacking Ruby?
In my little corner of the Rubyverse people seem quite happy, loving Ruby, and glad to be making a living from it. Those I know not paid to do Ruby look forward to their free time when they can work on their cool Ruby side projects.
I'm sure there are unhappy Ruby hackers, but I'm deeply skeptical that anyone is in a position to be making broad claims about The Ruby Community.
Just because it was financially responsible for Engine Yard to cut back from 6 to 2 fulltime developers does not mean that Rubinius is dead. Rubinius has as and always will be a community project.
Furthermore, the author states "But the problem is that [ruby is] essentially stagnant." Because of Rubinius, Ruby finally as a proper spec. This means we will see an "arms race" as he calls it, and it's because of Rubinius. PLUS, 4 implementations under active development (Rubinius, 1.9, MacRuby, JRuby) hardly seems stagnant to me.
Bottom line: this is FUD.
I don't want to have to write off Rubinius, and I have a lot of respect for Evan and the members of his team that I know. But can we be brutally honest for a second? The only independent Ruby implementation to have delivered goods, of any sort, is JRuby. I will trust Rubinius when it is publicly released. Until then, it's just another one of several projects claiming that Christmas will bring me a new, faster Ruby. And I've been hearing that same promise before, again and again.
And saying that the Ruby spec is somehow unbroken Ruby stasis? We damn well better have a spec! Ruby has been essentially unchanged for at least 2 years. Saying, "Well at least we have a spec now!" seems like the lowest possible bar for success.
P.S. MacRuby is fascinating, but let's see it on more than 1 of the Big Three before we start saying it's a serious competitor.
Without Ruby on Rails there would have been no Groovy on Grails web application framework. But rubyist keep pushing limits, creating new kinds of database orm libraries like sequel and new web frameworks like sinatra.
Sinatra makes me write web applications that looks like haiku:
require 'rubygems'
require 'sinatra'
get '/' do
"This is a web application!"
end
dataset = DB[:managers].where(:salary => 5000..10000).order(:name, :department)
%h1 Markup
%p
.my_id Look ma, no end tags!
And the scaling aficionados probably prefer single table selects anyway. ;) (Not that it makes a difference given how little traffic my blog gets)
The best hope I see for Ruby's future is embodied in re-implementations like MacRuby, JRuby, and Rubinius. MacRuby could totally become the popular way to write new Cocoa applications.
If MRI can be effectively displaced, Ruby can really break out of the "Perl that people write better code in" ghetto.
But seriously, anyone know if Parrot is a realistic vehicle for this?
It's just puzzling to me that with all the demand for a better interpreter, there really aren't any available options that are going to satisfy the community at large, and there's no visible light at the end of the tunnel. Is this because Ruby is a particularly difficult language to implement? Is it because there is no formal spec? Lack of leadership (compare with Guido and Larry)? All of the above?
Parrot is never going to be viable -- 'flexible' platforms are only so when there are piles of diverse users. Specifications do not make reality.
Ruby has a huge advantage over Perl in that there are a number of groups successfully working to reimplement, specify, and reform it. There are visible lights at the end of the tunnel, they're just for specific communities -- JRuby and MacRuby. Hopefully Rubinius (or a successor project) succeeds in replacing MRI, but it's a pretty damn hard problem.
To be honest, I don't know how one would get past those things without first deciding, with a clear conscience, to hijack Ruby from Matz. I know that sounds malicious, but even Dave Thomas is calling for a fork of the language. Seems to me that forking is not quite what we need, as it keeps the language rooted in the past, bringing the performance baggage with it (you're still having to re-implement the loose idea of the Ruby spec, which as you pointed out, presents some really hard problems).
No, maybe we need someone smart, loud, and with balls big enough to arbitrate their way through whatever gray areas are left with Ruby's loose idea of a spec, perhaps make some tough calls on what language features can reasonably be supported, decide what needs to be cut, and break compatibility with existing Ruby code if necessary. To top it off? This person forms a foundation around it, a la Python.org, to ensure that the language is left in good hands, gets proper funding for new development, patches, etc (hell, I would love to donate to Ruby development if I knew the money would be put to good use. I don't have that confidence now).
Of course, what I'm talking about now is not Ruby, but a new thing. This new thing could be quite awesome. Whatever this new thing would be is still years out, even if someone decided today that they would do it.
Python in the meantime?
There's a massive gulf between Matz and Guido as far as decision making, even when you only look at the Languages and not their imperfect Implementations. Just for example, look at how executable objects work:
* Guido made a hard+pragmatic decision that there are only Functions. Methods and Class Methods are functions that take their binding as an explicit argument (which is inferenced when called with the . selector). Lambdas cannot contain statements and simply yield to a Function. Functions are recursively defined as objects with a __call__ method.
* Matz tried to make everything hugs all around and the result is that there's no straightforward Function type -- there are Methods, Blocks, Procs, Lambdas (1); which yield into one another bafflingly and retain scope in untoward ways. This makes some simple use cases very straightforward, but at a terrible cost.
(1). Are there more? The lack of certainty with which I can answer this question is alarming.
Now that I've closed my eyes the Sun has gone away forever!
In 2002 Ruby was young: half-formed and exciting. It's problems didn't really look like problems: they looked like things Matz hadn't gotten to yet (and, even better, opportunities for other programmers to get to first). In late 2008 Ruby is established; the problems come with a set of reasons why they aren't likely to be solved. (The other problems were solved.)
This is natural and normal for any multi-year group endeavor, be it a company or a rock band: it starts with a world of potential. If it is one of the lucky few to survive for any length of time, it becomes mostly a specific reality, with a humdrum future. (More often it goes from having a world of potential to not having any future at all in short order.)
You cite as counter-examples Javascript and Scheme. Javascript is benefitting from the HUGE externality of being the client-side language for the single most important application category going. As for Scheme ... there's a paraphrase of "Brazil is the country of the future, and always will be" that's escaping me, but suffice to say that if the 73d time is the charm for Lisp's taking over the world, I won't be too embarrassed to have bet against it.
Ruby's momentum 2002-2007 was like Python's momentum 1999-2004 was like Perl's momentum 1993-1998: the momentum of a firework or a homerun. It was glorious to watch them rise; it shouldn't be sad to see them return to earth.
For my part, I tried reading that Dragon book recently but it just didn't click for me. It seemed way too low level, without teaching me the high level first. Or maybe compiler/interpreter design just isn't an easy thing to teach yourself?
What are your thoughts, HN?
Here, in no particular order, are the ones I can think of off the top of my head:
* Tamarin * OpenJDK * Squeak * Parrot * Python * Self * SpiderMonkey * PLT Scheme * CLisp * V8
(...etc., etc.)
The problem is not a lack of VM designs, implementers, or experience. It comes down to two factors:
* Ruby is a weird language, compared to most -- it wasn't so much designed as composed (in the sense of art/music). Normal compilation, optimization, and type-safety rules just don't apply, so even clever VM hackers are sort of left scratching their head when it comes time to optimize or deal with harder problems like serializing closures.
* The Ruby community is deeply bifurcated into two mutually-suspicious subgroups: the Rails users, and everyone else. Rail people hate (or at least mistrust) backwards-incompatible innovation in the language itself, because it breaks Rails, and (at least some of) the other group resents the Rails guys for holding the language back.
If you don't believe me on this second point, look at Ruby 1.9. If 1/10th the energy went into testing and patching new Ruby releases as goes into a minor point-release of Rails, we'd all be running nice, fast, bytecode-compiled Ruby scripts with full Unicode and fiber support. Instead, we're stuck and 1.8.6 for anything "serious", because it's the last release Rails supports well.
Move on and embrace the new coolness when you are done with your job.
Perhaps the most frustrating part about Ruby, to me,
is the outrageously outdated state of the current Ruby interpreter.
<snip>
I wish we could change all that. I wish that we had a new,
exciting Ruby engine that began to rapidly iterate, was extensible in Ruby itself,
and really started to live the dream that Smalltalk failed to achieve in the enterprise:
being both cutting edge and mainstream.
This is where i think Rubinius holds great promise. When Engine Yard started supporting it officially, it started looking like we would finally have a good VM 'soon', eliminating the single biggest issue with Ruby at this point. With the recent cut-down in the size of that team, we are kind of at an infection point. Either this project would flicker out (i really hope it doesn't happen) or the community kicks in a big way to help it pick up pace.
It's my humble belief that Javascript will be the most popular language within 10 years.
Javascript with minor syntactic sugar for making DSLs, and with the stupidity around scoping ironed out, that might win out, though.
http://javascript.crockford.com/javascript.html
Don't get me wrong, it's my favorite language. I don't want to bash on Javascript. Most of the coding I do for fun is in Dashcode, which I never understood why isn't pore popular. But JS has big problems in public perception.
Stories on new things done in Ruby tend to elicit "cool, I can use that", but new things done in JS tend to elicit "what a waste, why use such a crappy language".
I tried both at the same time and granted haven't coded anyhting real in Ruby but Python just won handsdown on every point that mattered for such a language:
* Readability
* Libraries
* Rapid protoyping
* Integration and support with other platforms, bindings to libraries n other languages
* Documentation
* Support form industry(while Ruby is pretty much only used in webapps Python is used in bioinformatics, engineering, GvR works at Google hacking on Python, it is used at NASA, has numpy+scipy+matplotlib).
This seems to me to be a bad thing for the long term prospects for the language. Big companies think long term, small companies tend to change their focus often. If I'm going to invest my time in a language, I want it to stick around for long.
The point here is that for EY, Sun, and MS their platforms are loss leaders for very profitable goods and services. And if those companies are paying people to work on Ruby for their platforms, that means they're betting that Ruby support will lead to greater platform adoption, which then leads to greater server sales.
Python's warts have been fixed and will continue to be fixed. I cant really say the same for Ruby, especially for MRI.
That being said, the two often occur together because changes are exciting and attract effort.
I've always felt that python offered the same benefits as ruby accept with a simpler syntax, better cross platform support, better performance, and a more organized community.
Example:
mylist = []
for char in "foobar":
if char == "f":
mylist.append(char)
mylist = [ char for char in "foobar" if char == "f" ]
>>> char = 'f'
>>> char * "foobaf".count(char)
'ff' >>> [char] * "foobaf".count(char)
['f', 'f']There is one thing to observe here: Ruby will not become as widespread or as popular as Perl, PHP, or Java without also becoming as unfashionable as Perl, PHP, and Java. When an invention becomes successful and established, eventually everyone comes to take its good parts for granted, while its flaws become famous and are an eternal topic of discussion.
the biggest thing that ruby and php have in common is that they're both hamstrung by their terrible interpreters.
the second biggest thing is that the languages were conceived and championed by amateurs whose proposed philosophies are just fine (though vague), but the execution is horrendous.
example regarding php's philosophy: about all php has going for it is how easy it is to get started. that's it, and it hasn't even done that right. php has a rich history of horrible decisions made in the name of being easy - register globals, magic quotes.
two failed implementations of a vague philosophy - ease of use & programmer happiness. brought to you by php and ruby.
many thanks in advance
try python or perl.
That said, Ruby is still my 'favorite' language -- it's just so much fun to code. But the libraries, and frankly horrible interpreter, have caused me to chuck it out the window for my company. The speed actually isn't the big problem -- it's the long-term maintainability and flexibility.