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: * 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…
Ruby and the Opposite of Momentum
51–60 of 69 posts
Re: Ruby and the Opposite of Momentum
#52Earlier quoted context omitted.
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: mylist = [] for char in "foobar": if char == "f": mylist.append(char) vs. mylist…
Re: Ruby and the Opposite of Momentum
#53Earlier quoted context omitted.
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 regardi…
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…
try python or perl.
Re: Ruby and the Opposite of Momentum
#54Earlier quoted context omitted.
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: mylist = [] for char in "foobar": if char == "f": mylist.append(char) vs. mylist…
Re: Ruby and the Opposite of Momentum
#55Earlier quoted context omitted.
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…
seriously, almost anything else. 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.
Re: Ruby and the Opposite of Momentum
#56Earlier quoted context omitted.
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.
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.
Re: Ruby and the Opposite of Momentum
#57Earlier quoted context omitted.
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: mylist = [] for char in "foobar": if char == "f": mylist.append(char) vs. mylist…
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.
Re: Ruby and the Opposite of Momentum
#58He'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 des…
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.
Re: Ruby and the Opposite of Momentum
#59Earlier quoted context omitted.
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 it…
Re: Ruby and the Opposite of Momentum
#60Not 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 g…
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.
"I want to use Lisp for everything! Oh but what about GC pauses in games?"