Ruby and the Opposite of Momentum(kirindave.tumblr.com)
kirindave.tumblr.com
Ruby and the Opposite of Momentum
http://kirindave.tumblr.com/post/60776407/the-opposite-of-momentum
68 comments
Seems like the good and crappy things about Ruby and Java, respectively, complement each other well. Ruby is a high productivity language, Java not so much. The JVM is a very well engineered run time engine, Ruby's MRI not so much. Unicode, threading, fast, reliable, portable, well understood and supported. Pluses for Java, minuses for Ruby.
So in principle it seems JRuby could have the best of both worlds. But for now I'm having more fun with Clojure. :)
So in principle it seems JRuby could have the best of both worlds. But for now I'm having more fun with Clojure. :)
You're absolutely right about Ruby & Java being a great Odd Couple
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.
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.
Not to rub salt into this whole pile of hurt in the Ruby world lately, but I'm shortly going to be promoting (on Ruby Inside) some rather damning news from the Windows camp in relation to how many significant Ruby libraries are either ignoring Windows or not being transparent enough to make it easy to patch the issues.
(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'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.)
That is the primary reason I chose not to use SBCL (Lisp) to implement the game engine I'm building. I really wanted to, but SBCL leaks memory on Windows. When I asked their mailing list about how to fix it, the community was silent. Those two issues make it impractical to use SBCL to develop a product.
How do you prevent unfortunate GC pauses for your game engine? I have two conflicting thoughts lately:
"I want to use Lisp for everything! Oh but what about GC pauses in games?"
"I want to use Lisp for everything! Oh but what about GC pauses in games?"
Lua is used in games often. It does have GC, with an incremental non-compacting generational GC. If you do get pauses then there are various methods of forcing GC on a regular basis, or just generating less garbage. It works well in practice.
Amen. I've settled on Vista as my main OS recently. It's not like I'm some noob. I've used Windows, OS X, and Linux extensively. I understand why others choose differently.
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]
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]
" Not to rub salt into this whole pile of hurt in the Ruby world lately ..."
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.
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.
Your response is to the wrong post. There were no broad claims about the Ruby community in general in mine. But if it's just passive aggression, change the record!
Um , I was referring to the article in question, not your post. Stop being so touchy. It's unbecoming.
[deleted]
I'm sorry. You're awesome really :)
I think it's very unfair of him to be criticizing and writing off Rubinius. "Rubinius looked like the light and hope of the Rubyverse, but their team has been slashed..."
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.
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.
Maybe it is FUD, but that is because I am experiencing Uncertainty, Doubt, and at least a little bit of Fear on the subject of what high-level dynamic language I am going to work with next. I certainly have carried a lot of water for the Ruby team, and I'm worried what I'm going to do with all my free time if I don't have a language to idolize! ;)
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.
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.
[deleted]
Ruby has had huge impact on the way I write software. Whatever programming language or tools I'll use tomorrow, it will be dynamic.
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:
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!
ORM examples that feature single table selects are unconvincing: the true test of an ORM is whether it can do joins (outer + inner), aggregation, and subqueries. Otherwise it is little more than syntax sugar, IMHO.
Honestly, I think the syntax sugar is great because thats what I need the vast majority of the time.
And the scaling aficionados probably prefer single table selects anyway. ;) (Not that it makes a difference given how little traffic my blog gets)
And the scaling aficionados probably prefer single table selects anyway. ;) (Not that it makes a difference given how little traffic my blog gets)
The Ruby Language itself has plenty of warts, but the implementation problems are far worse. The MRI is awful, and 1.9 isn't much of an improvement at all.
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.
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.
cough Parrot! cough
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?
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?
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.
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.
All of the above = a huge bag of hurt that presents some damn near insurmountable problems (leadership, on its own, is a huge issue).
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?
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?
Exactly, Python wins.
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.
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.
What happened the to great potential offer by Maglev and Avi Bryant's presentation a while back about putting Ruby on the smalltalk VM? Was that all just vapour ware? I have not heard a peep about in since!
http://ruby.gemstone.com/
Now that I've closed my eyes the Sun has gone away forever!
Now that I've closed my eyes the Sun has gone away forever!
Interestingly, the ruby on rails podcast just released has a interview with one of the maglev developers.. Sounds like they are making good progress!
Maybe this comment is already here and I just missed it, but languages naturally have life cycles, and thinking in terms of Ruby's life cycle might explain both some of your early enthusiasm and your current discontent. (I'm going to draw in broad strokes here and will probably get some details wrong.)
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.
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.
He's saying Ruby needs a better VM, no? I think the real problem is that there are only 10-50 people in the world that know how to make high quality VM's. We probably just need to get more open source people trained up in this.
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?
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?
There are probably more than 50 "decent" virtual machines in production use, many of them open source. Anyone who completes a graduate-level course in language and compiler design should be able to create a decent bytecode-based VM, and should be able to make a good start on a simple JIT.
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.
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.
I have used a number of languages/tools/technologies in the past. Whenever I felt the existing choices don't meet my needs I have simply moved on. I never had to bash my old choices because they are not good anymore. They have served me pretty well so far. The community has helped me find answers. I didn't find it right to laugh at the current community and tell them you are no good because I am not there.
Move on and embrace the new coolness when you are done with your job.
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.
I think the time is ripe for a server/desktop side Javascript language to come along. Rhino?
It's my humble belief that Javascript will be the most popular language within 10 years.
It's my humble belief that Javascript will be the most popular language within 10 years.
I would like you to be correct but I don't think you are.
Javascript with minor syntactic sugar for making DSLs, and with the stupidity around scoping ironed out, that might win out, though.
Javascript with minor syntactic sugar for making DSLs, and with the stupidity around scoping ironed out, that might win out, though.
Why do you think I'm not correct?
For the reasons lined out here:
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".
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".
Why choose Ruby in the first place?
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:
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).
please watch your line lengths in code blocks... you're making my browser scroll.
You know what really bothers me about ruby? It seems like it's the smaller companies who are behind it - like EngineYard and 37Signals. None of the heavyweights seem to be interested in Ruby.
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.
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.
Microsoft pays John Lam and the DLR team to work on IronRuby full time. Sun pays Charles Nutter and Thomas Enebo to work on JRuby. Thoughtworks pays Ola Bini to work on JRuby as well. So there are some larger companies that are investing in Ruby implementations.
They are paying people to add support for niche languages to their tools. IronRuby sells Visual Studio, JRuby promotes Java. MS and Sun are interested in their tools, not in Ruby.
Of course. They can't make money directly off of Ruby. Neither can EY or 37signals. For that matter, Sun doesn't directly make money off of Java either. And Microsoft doesn't make a lot of money from .Net (it's arguable over whether you'd consider visual studio sales directly attributable to .Net.)
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.
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.
It would be nice to see some progress made on the interpreter but I think it's to Ruby's credit that the language design hasn't changed that much in the last several years. A lot of the activity on the Python side has been fixing things that weren't well thought through in the first place.
You don't seem to understand that "language design hasn't changed" tends to preclude "progress made on the interpreter".
Python's warts have been fixed and will continue to be fixed. I cant really say the same for Ruby, especially for MRI.
Python's warts have been fixed and will continue to be fixed. I cant really say the same for Ruby, especially for MRI.
Honestly, I'd say the opposite is true. The more the language design changes, the more implementor time is going towards servicing the changes and not squeezing the fat out of the implementation.
That being said, the two often occur together because changes are exciting and attract effort.
That being said, the two often occur together because changes are exciting and attract effort.
I don't see how that follows at all. If the biggest issues with Ruby are performance and memory management how does changing the language spec help fix that? If anything a stable language spec should help nail down the bugs in the engine.
So, does this mean you're going to use other languages more often? If so, which?
For me, python, but that's not exactly a change ;).
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.
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.
I find the "there's only one way to do it" philosophy of Python to be really important. That's the main thing that kept Ruby off my radar.
I feel it diverges a little bit, actually. In many cases it provides the "C style" way of doing it and the "functional style" way of doing it. Thankfully, in many cases one of them is much faster than the other, but it's not obvious to the novice and they will probably use the "C style" for years in ignorance of the alternative.
Example:
Example:
mylist = []
for char in "foobar":
if char == "f":
mylist.append(char)
mylist = [ char for char in "foobar" if char == "f" ]
This particular example could be written as follows:
>>> char = 'f'
>>> char * "foobaf".count(char)
'ff' >>> [char] * "foobaf".count(char)
['f', 'f']That's a good point. I'd argue the first way is the wrong way to do it. I guess once you get to multiline statements the philosophy breaks down. I'm just happy there's no string.strip() and string.trim() or something crazy like that which I'm guessing Perl has :-)?
It's pretty hard to believe you've been using Python seriously since 2002/2003 and had never heard of list comprehensions. They are a pretty big staple of most Python programmers.
Then you can call me out for being a noob, if you wish. :)
There's also the fact that the CPython implementation doesn't have any huge warts.
I can't believe I spelled "except" "accept". I need to get some sleep.
ruby is slowly but surely showing itself to be the next PHP - popular for all the wrong reasons, terrible implementation and a foolish philosophy
Please, elaborate. What wrong reasons is Ruby popular for? What is the foolish philosophy around Ruby?
I don't know, but if the secret to PHP's enormous success is its foolish philosophy then the Ruby community needs more fools.
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.
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.
[deleted]
you're right, I shouldn't have said foolish. more like vague. it's the implementations that have been foolish.
What is PHP's philosophy? Getting stuff easily online? I don't find that foolish. On Ruby, is programmer happiness a foolish idea?
programmer happiness is a great idea, it's just that Ruby fails it completely. do memory leaks make you happy?
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.
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.
as a PHP and ruby programmer (these are my two primary languages) I have to say I agree completely with your comments, you express perfectly a nagging thought that's been, well, nagging for quite some time now. I am very interested to know which you think are better languages that a young programmer might learn next that avoids these pitfalls whilst still retaining the 'practicality' of PHP & ruby for 'getting things done'
many thanks in advance
many thanks in advance
seriously, almost anything else.
try python or perl.
try python or perl.
As somebody who did lots of Perl for many years, spare yourself the pain, and do Python.
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.
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.
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.