Live data from Hacker News

Ruby and the Opposite of Momentum

kirindave.tumblr.com

41–50 of 69 posts

Re: Ruby and the Opposite of Momentum

#41

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

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.

Re: Ruby and the Opposite of Momentum

#42
post #40

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: require…

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)

Re: Ruby and the Opposite of Momentum

#43
post #28
post #19

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.

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.

Re: Ruby and the Opposite of Momentum

#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 is used in bioinformatics, engineering, GvR works at Google hacking on Python, it is used at NASA, has numpy+scipy+matplotlib).
I just don't see much reason to hang on to Ruby. Switch to Python and let Perl and Ruby die.

Re: Ruby and the Opposite of Momentum

#45
post #20

Earlier quoted context omitted.

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 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 done'

many thanks in advance

Re: Ruby and the Opposite of Momentum

#46
post #4

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

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!

Re: Ruby and the Opposite of Momentum

#47
post #28
post #19

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.

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.

Re: Ruby and the Opposite of Momentum

#48

Earlier quoted context omitted.

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 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 = [ char for char in "foobar" if char == "f" ]
The latter is supposedly much faster, and as you can see, much more succinct, but I hadn't learned about it until about a year ago. I have been programming in Python since about 2002/2003.

Re: Ruby and the Opposite of Momentum

#49
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?

Re: Ruby and the Opposite of Momentum

#50

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.

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.

Why do you think I'm not correct?
Post reply on HN