Live data from Hacker News

Ruby and the Opposite of Momentum

kirindave.tumblr.com

51–60 of 69 posts

Re: Ruby and the Opposite of Momentum

#51
post #44

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…

please watch your line lengths in code blocks... you're making my browser scroll.

Re: Ruby and the Opposite of Momentum

#52

Earlier 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…

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 :-)?

Re: Ruby and the Opposite of Momentum

#53

Earlier 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…

seriously, almost anything else.

try python or perl.

Re: Ruby and the Opposite of Momentum

#54

Earlier 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…

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

#55

Earlier 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.

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.

Re: Ruby and the Opposite of Momentum

#56

Earlier 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.

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.

Re: Ruby and the Opposite of Momentum

#57
post #54

Earlier 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.

Then you can call me out for being a noob, if you wish. :)

Re: Ruby and the Opposite of Momentum

#58

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 des…

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.

Re: Ruby and the Opposite of Momentum

#59
post #17

Earlier 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…

[deleted]

Re: Ruby and the Opposite of Momentum

#60
post #9

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 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.

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?"

Post reply on HN