Ruby 2.0.0 Released • Hacker News Board

Re: Ruby 2.0.0 Released

#241

Post by jbrechtel » Sun, Feb 24, 2013, 9:58 PM UTC

army wrote: post #153

vidarh wrote: post #111

Earlier quoted context omitted.

As a Ruby user that finds Rails annoying and not something I like working with, I don't think that's all that relevant. A lot of people have come to Ruby because of Rails, but a lot of Ruby people dislike Rails too. There's a plethora of web frameworks for Ruby that have sprung up exactly because of people who want to use Ruby but don't like Rails. In terms for barrier to entry with Python, the issue is that a lot of…

You seriously would turn down a good job or other opportunity if the only downside was having to write in a whitespace-sensitive language? Most of the good developers I know have their preferences for sure, but can be productive in all sorts of languages.

The gp said "I'm not touching it." and you seem to have read "I can't be productive in it."

Re: Ruby 2.0.0 Released

#242

Post by mixonic » Sun, Feb 24, 2013, 10:16 PM UTC

ScotterC wrote: post #235

Basic Ruby 2.0 benchmarks calculating pi from gist [1] $ ruby --version ruby 1.9.3p385 (2013-02-06 revision 39114) [x86_64-darwin12.2.1] $ time ruby pidigits.rb 10000 2>&1 > /dev/null 17.51s user 0.11s system 99% cpu 17.639 total $ ruby --version ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.1] $ time ruby pidigits.rb 10000 2>&1 > /dev/null 4.64s user 0.27s system 99% cpu 4.927 total That's a significan…

I've also seen a speedup in Rails app boot time (the require optimizations):

1.9.3-p194: 11.8s

1.9.3-p385: 9.9s

2.0.0-rc2: 6.1s!

Tests were done with `time bundle exec rake environment` 5 times, dropping the highest and lowest and getting the mean of the rest (lazy snow day benchmarking). Very exciting!

Re: Ruby 2.0.0 Released

#243

Post by damoncali » Sun, Feb 24, 2013, 10:20 PM UTC

army wrote: post #155

smnrchrds wrote: post #85

Earlier quoted context omitted.

> I just think it will slowly become less relevant. That's true for virtually anything. Do you think C/C++ or Java or JS will be mainstream 30 years from now. They will be in the same situation FORTRAN is today: important because of lots of legacy code, but not a viable choice when starting a new project. Of course some of them will never die. LISP comes to my mind. :-)

The rumours of Fortran's death are greatly exaggerated. People still write new code these days in Fortran for scientific computation. Fortran compilers are still markedly better at optimizing numerics, multi-dimensional arrays, etc, partially because of the effort invested in the compilers and partially because the language is easier to optimize. It's definitely a niche language.

I used FORTRAN at NASA as late as 2003. Id be surprised if they were not still using it. It was painful, though.

Re: Ruby 2.0.0 Released

#244

Post by VeejayRampay » Sun, Feb 24, 2013, 10:24 PM UTC

tykko wrote: post #81

tferris wrote: post #10

Today, I'll lose at least 50 karma points, but it's worth: Why people still use Ruby? 1. Because they get dream day rates for maintaining rusty slow legacy systems 2. Because they do not want to learn new languages and can stay in their comfort zone 3. Because they think it's still 2005 and nobody cares about slow server response times And now Ruby lovers, click on downvote or give your reasons why you still use Ruby…

Ruby lovers are all about "feelings" and "style", they don't care if their language of choice is objectively worse than, say, Python or Lua. Ruby truly is the Apple of the programming world.

I really love the use of the word "objectively" in your sentence. It's totally irrelevant and has no ground in reality or the realm of logical reasoning. As such, it is in fact quite revealing of your true intent with this comment: riling people up and trolling.

Maybe you should think long and hard about why exactly Ruby (and Apple for that matter) makes you so mad that even though you don't use it or program with it, you have to come here on an article about a new release just to spit some venom even though the language itself doesn't impact your personal life in the slightest.

Re: Ruby 2.0.0 Released

#245

Post by aardvark179 » Sun, Feb 24, 2013, 10:41 PM UTC

tsewlliw wrote: post #130

aphexairlines wrote: post #121

Earlier quoted context omitted.

After reading that article, I'm wondering: what's the value of Ruby refinements over dynamically-scoped monkey-patching? Taking the String.camelize example from the article, you could write in Perl: sub withCamelize (&) { my ($thunk) = @_; local *{'String::camelize'} = sub { ... }; $thunk->() } sub camelize_and_join { my ($str_ary) = @_; withCamelize { join ', ', map { $_->camelize } @$str_ary } } So you can probably…

Wow, that reminds me of the classloader magic Eclipse/OSGi does so that plugins that depend on different versions of the same library can work together in the same JVM.

That kind of local class alteration is very different from the kind of tricks done in OSGi. In OSGi a class is the same no matter what context you're in, it's just that the context you're in affects the look up from class name to class. So all the caching or optimisations you might do against classes are still valid.

Refinements mean things like method lookup are sensitive to the context and become much more fun.

Re: Ruby 2.0.0 Released

#246

Post by michaelwww » Sun, Feb 24, 2013, 10:51 PM UTC

naner wrote: post #224

vidarh wrote: post #111

Earlier quoted context omitted.

As a Ruby user that finds Rails annoying and not something I like working with, I don't think that's all that relevant. A lot of people have come to Ruby because of Rails, but a lot of Ruby people dislike Rails too. There's a plethora of web frameworks for Ruby that have sprung up exactly because of people who want to use Ruby but don't like Rails. In terms for barrier to entry with Python, the issue is that a lot of…

Pythons whitespace usage, for example, makes it DOA for me. I'm not touching it. If it works for you, great. It doesn't work for me. This has to be up there with people claiming they don't like Lua because array indexing starts at 1 instead of 0. Of all the weaknesses of Python, focusing on something so superficial just seems lazy. Perhaps in the future just say that you're experienced and comfortable with Ruby and h…

I prefer my white space to not mean anything because I normally can't see it. If I show white space then I see meaningful and non-meaningful white space. I find this aggravating and figure the designer of such a language is a control freak who will likely continue to aggravate me in other stupid ways. I don't need this in my life. I don't know how this disagreement between myself and the language designer seems 'superficial and lazy' to you.

Re: Ruby 2.0.0 Released

#247

Post by technomancy » Sun, Feb 24, 2013, 11:03 PM UTC

TazeTSchnitzel wrote: post #230

technomancy wrote: post #227

Earlier quoted context omitted.

There is no reason to include statements in a language other than inexperience.

I can't agree with that. "break", "exit", "return", variable declarations, etc. should never be expressions.

The choice of whether to implement language constructs whose very semantics require that their return value be un-observable is completely arbitrary. Why make your language more complicated in order to support something that by definition has no effect?

Of course things like crippled lambdas can be worked around by using a named function, but the fact that you have to do that in the first place tells you that the person implementing lambdas did so without at the time understanding what they were for.

Anyway, it's fine for some kinds of imperative programs, but calling it a functional language is misleading.

Re: Ruby 2.0.0 Released

#248

Post by technomancy » Sun, Feb 24, 2013, 11:07 PM UTC

Ingaz wrote: post #231

philwelch wrote: post #222

Earlier quoted context omitted.

> Perl: sigils, regexp everywhere (when it not needed), parameters passing, "use strict", strange OOP - all those features makes it impossible for prototyping. > Ruby: it's the same as for perl Nothing you said about Perl can be applied to Ruby.

"The same" means "ruby as pseudocode is the same as perl". You need to explain that 0 is True. You need to explain blocks, (int_number).times and other cute things. And I heard a lot of complains for whitespace, but begin-end is more irritable for many.

> You need to explain that 0 is True.

Easy: it's not C.

The idea that zero is false only makes sense if you're trying to code very close to the metal. To everyone else it's baffling.

Re: Ruby 2.0.0 Released

#249

Post by gamache » Sun, Feb 24, 2013, 11:09 PM UTC

aphexairlines wrote: post #121

ch0wn wrote: post #103

Earlier quoted context omitted.

There's a really in-depth article on them that also covers concerns about the implementation: http://blog.headius.com/2012/11/refining-ruby.html

After reading that article, I'm wondering: what's the value of Ruby refinements over dynamically-scoped monkey-patching? Taking the String.camelize example from the article, you could write in Perl: sub withCamelize (&) { my ($thunk) = @_; local *{'String::camelize'} = sub { ... }; $thunk->() } sub camelize_and_join { my ($str_ary) = @_; withCamelize { join ', ', map { $_->camelize } @$str_ary } } So you can probably…

First, Ruby has no built-in way to accomplish dynamic scoping. Perl is Very Powerful.

Second, refinements apply lexically. Consider a class A where refinements have been declared, and a class B where they have not. Class A code calls Class B code. Class B code will not see class A's refinements. In the case of dynamic scope, the refinements in use by class A would be visible to class B code, when called from code within class A.

Re: Ruby 2.0.0 Released

#250

Post by grey-area » Sun, Feb 24, 2013, 11:33 PM UTC

erikpukinskis wrote: post #209

grey-area wrote: post #116

There are some nice features here: Keyword arguments, which give flexibility to API design This looks good to replace all those options hashes in rails for example, though I wish they'd made it an all or nothing thing, apparently you can still do this: def foo(x, str: "foo", num: 424242) i.e. use some named and some unnamed in the same method which looks ugly. Module#prepend, which is a new way to extend a class Comp…

I like the idiom of mixed named and not named parameters in Ruby. You don't really need names for implied, required parameters. Consider: protagonist.throw(potato, :force => 3, :at => zombie) In this case a call to :throw without an object to throw is nonsense. Throw is a transitive verb, and the parameter is implied. On a throw method, the parameter is obviously the thing being throw'ed. On the other hand, the optio…

yes I see your point, it just feels inconsistent somehow, as named parameters are nicely self-documenting, could be used to generate docs etc, but that's probably just a foolish consistency. In your example you could be cute and have something like:

     protagonist.throw(a: => potato, :at => zombie, :force => 3)

which would be just as nice. But I'm sure there are places where this will be useful/necessary, in your chained example with single args it feels forced to have to name them.