Live data from Hacker News

Ruby 2.0.0 Released

ruby-lang.org

131–140 of 303 posts

Re: Ruby 2.0.0 Released

#131
post #88

Earlier quoted context omitted.

I am a pythonista by hobby... and I've seen many times in these too many ruby / python comparison, that only in ruby "Everything is an object, without exception." but... I cannot find a "thing" that isn't an object, in python neither... care to tell me, or point to a link regarding to, what is the difference in this context between the two languages? Just an example or something like that. Thanks.

Trying to guess how Python works is quite hard if you're used to Ruby and other languages closer to Java. As I don't know much Python myself, it's hard to tell where Python fails the "everything is an Object" check. But in Python some legacy calls were more procedural than OO, like "len(o)" rather than "o.len". I think eventually Python got to support both approaches. I think Ruby is all objects even in its C abstrac…

Just as note: I don't really would call "len(o)" a "legacy call", as in "something it's here just for backward compatibility, but it's ugly and please don't use it".

It's more "the good way to do it" :D

len() is a perfect example of the duck typing and the "protocol-based" philosophy of python: its implementation it's something like

    def len(object):
        return object.__len__()
as in "just return the result of invoking the object method called __len__".

this lets you just call len() on every "len-able" object. They can be list, dict, custom objects... instead of the need to, I don't know, implements an explicit interface, or define a "getLength()", "size()", "length()", "length" (just an attribute, not a function to call), you can just define a "magic" (as in "normally you don't need to call this directly") method called __len__.

you can create your "not really a container, but it has a length!" object as something like

    >>> class C:
    ...     def __len__(self):
    ...         return 42
    ...
    >>> len(C())
    42

As indirect effect, it enables you to go on the functional-style approach... a simple

   map(len, list_of_lists)
it's more readable than

   map(lambda l: l.__len__(), list_of_lists)
(probably [len(l) for l in list_of_lists] it's more readable, but bear with me...)

I'm not really sure about the "ruby C abstractions": do you refer to the use of "object-like" structs used in the C sources of the "ruby MRI" implementation of "ruby-the-language"?

regarding the GC... I don't know, but why is the kind of the GC used by an implementation of the language (or the complete lack of a GC) relevant to the "everything is an object"?

just to be clear, I don't dislike ruby :) it's just that I don't find the "everything is an object" a way to discriminate between ruby and python.

Re: Ruby 2.0.0 Released

#132
post #126

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…

Module#prepend doesn't look too bad from me from a complexity perspective - inheritance in Ruby boils down to two parallel trees: One of the inheritance chains, and one of the method lookups. Really we're dealing with a single tree of "actual" inheritance, with some of them being "hidden" in some contexts. It gets a bit complex if you want to do meta-programming or do something that depends on the inheritance hierarc…

Yes it's not hugely complex, but it does complicate the composition side of code inheritance a little more as you have to think about how a module might be included as well as which modules and which superclasses you have. Contrast this with go which has no inheritance and only simple composition and is vastly simpler to comprehend re the reuse of code due to those limits.

Re refinements I agree and find it worrying that it was added given the widespread objections.

Re: Ruby 2.0.0 Released

#134
post #16
post #8

I guess, Rubinius is no longer relevant? I remember it was a very promising project back in 2008.

Evan Phoenix (the creator) left in 2012 to work for LivingSocial. EngineYard, his former employer, had been funding work on it last I heard, but there haven't been any releases since 2011. http://blog.fallingsnow.net/2012/03/28/a-new-door-opens/

Only in the same sense that there haven't been any Arch releases...

EDIT: Just checked. If you `rvm install rbx`, you get code written today.

Re: Ruby 2.0.0 Released

#135
post #131

Earlier quoted context omitted.

Trying to guess how Python works is quite hard if you're used to Ruby and other languages closer to Java. As I don't know much Python myself, it's hard to tell where Python fails the "everything is an Object" check. But in Python some legacy calls were more procedural than OO, like "len(o)" rather than "o.len". I think eventually Python got to support both approaches. I think Ruby is all objects even in its C abstrac…

Just as note: I don't really would call "len(o)" a "legacy call", as in "something it's here just for backward compatibility, but it's ugly and please don't use it". It's more "the good way to do it" :D len() is a perfect example of the duck typing and the "protocol-based" philosophy of python: its implementation it's something like def len(object): return object.__len__() as in "just return the result of invoking th…

You see, you wrote a bunch about how len is so cool in Python. But in the face of dynamic typing and polymorphism I didn't expect it to be any different really. Languages like Go that are statically typed make more of an issue about interfaces. Even in Dart they dropped explicit Interface usage in favor of implicit interfaces, considering that Dart is more explicit about matters than Ruby is.

Switching those function calls around reminds me of Delphi. When I first learned about Python, those calls reminded me of Delphi which I had used more. But once I learned Java, my frame of mind went from function(object) to object.function. With Ruby I found it quite intuitive. Now all languages work better if they approach things the way Java and Ruby do because of familiarity. That's why I like Dart for what it's worth.

Regarding C extensions of Ruby, they are like OO in C. Not sure how Python does it by default. But in Ruby all C extensions have a OO flavor. The first major book about Ruby writes about them: http://www.ruby-doc.org/docs/ProgrammingRuby/html/ext_ruby.h...

I think if you're counting references in the GC perhaps your C extensions are not very OO yet. In Ruby as in Java, the GC is an abstraction over reference counting. I think reference counting is often said to lead to more predictable performance at the cost of increasing the maintenance burden.

So again, not sure where Python is not "Objects all the way down." But Ruby has had the OO philosophy from early on. I think the Ruby OO approach started with the OO of the C extensions and went from there. Unlike Python that had a stronger procedural influence. The gap has closed since, but in Python a class is not written like this yet:

  class InRuby
  def aMethod
  end
  end

  class InDart {
  aMethod() {}
  }

Re: Ruby 2.0.0 Released

#136
post #71

Earlier quoted context omitted.

Agreed regarding refinements. I will personally stay away from them until some braver souls find best practices for them in long-term projects. Even then it will take some convincing. I have been awaiting Ruby keyword arguments for a very long time, but the first time I heard them brought up (relating to 2.0), the person explaining had some qualms with how they were implemented. For the life of me I cannot remember w…

The complaints I recall about Ruby keyword arguments were on Twitter: https://twitter.com/brixen/status/281180931950264320 https://twitter.com/garybernhardt/status/281181122736582656 . Not sure if that's what you're thinking of. @ch0wn: I'm pretty sure that chao- was talking about the implementation of keyword arguments , not refinements.

That was indeed the complaint: That the keyword arguments are actually implemented as a hash underneath. Still useful for loads of reasons, but hopefully will transition to a more optimized implementation one day.

Re: Ruby 2.0.0 Released

#137
post #58
post #46

Earlier quoted context omitted.

And then then the fast lanugage implements caching.. Your first point is valid

The language does not implement caching. Your application architecture needs to take server caching into account. And in my experience, devs who focus so much on the "fast language" part, do so, because they don't actually know much about caching. And no, this statement is not universally qualified.

With a proper runtime, you don't bolt caching on, but rather implement it throughout the code base using both local cache state and shared network cache state. The end result is something simpler to implement, maintain, and deploy.

However, thanks to using faster systems, the bar at which you must pay the implementation and deployment costs for caching is much higher than that of someone that needs it just to achieve acceptable speeds at all.

Re: Ruby 2.0.0 Released

#138
post #87

Earlier quoted context omitted.

Well you should use a framework not because you are lazy but because there are a million other actually important things you should be doing than implementing state for HTTP for the billionth time.

Potato potato. You are a 'glass-half-empty' interpreter of the word 'lazy'. Easy syntax, DRY, etc. are things that are good because they limit you to waste time on trivial things, like you said. They stop you from reinventing the wheel. I call that (positive) laziness. You can call it whatever you want of course. It still boils down to the same thing. I have worked at places where programmers were willing to write th…

Do you mean PHP languague ?

Re: Ruby 2.0.0 Released

#139

Anyone have any thoughts on why python and ruby are so similar, yet so far apart? They are obviously very close, because people switch between them all the time. And they are compared on everything (languages features, libraries, tooling...). I think it's a healthy competitive environment.

The biggest difference is the communities surrounding each, and the impression each leaves on people. When I think of "Python", I think of a mature, helpful, experienced, talented, well-educated community. I can generally trust their advice, I can trust their code, and I can trust their technical decisions. It feels like collaboration is important and encouraged. The Ruby community, whether this is deserved or not, l…

I think this is a little unfair - you do prefix your thoughts on the Ruby community with 'whether this is deserved or not', but then treat your perception of the community as fact.

I'm a Rubyist, and I've found that the vast majority of the community, events, interactions, etc are smart and civil. Yes, the Ruby community does have a bit of a publicity problem, but that's just the noisy/stupid minority.

Perhaps this is a common issue more broadly. (Are all PHP developers stupid? Are all lawyers money-hungry scum? Do politicians have no regard for intelligent discourse?) Our media (whether that be mainstream or Twitter and HN) is great at highlighting the controversy, but not a good source for a deeper understanding of the lay of the land.

Post reply on HN