Hacker News new | ask | show | jobs
by ryanto 4454 days ago
I think it is unfair to single Ruby out here and call it a "flaw". What you are describing is just bad code/design that can exist in any language.

Also, as far as Ruby is concerned your class's external API is only made up of methods. There are no attributes, model.foo is always a method. Because of this your long running or resource intensive methods need to be documented or have clear names if you are exposing them as public API. In other words: Model.foo shouldn't take 30seconds, but maybe Model.download_foo will.
1 comments
rtpg 4454 days ago
>What you are describing is just bad code/design that can exist in any language.

Actually the problem he is describing is a consequence of language design, not of architecture design.

In Javascript, if I write foo.bar, I know that it is accessing some field of the foo object, and that's it. Unfortunately we're going to get a bunch of stuff in ES6 that's going to change this, but the fact that we can have some invariants (especially in a dynamic language like Ruby) on property accessors is pretty important when trying to reason about performance.

The fact that Ruby only exposes methods is a language design decision that can enable some pretty bad architectural decisions.

Language features are about tradeoffs .For example, among other things, the calling syntax for ruby means that point-free functional programming is pretty much impossible (though there are possible language-level solutions for this). Depending on what you're looking for, that can be considered a flaw , because it deviates from your personal definition of the ideal programming environment.

link
btown 4454 days ago
It's interesting that you mention Javascript. There was recently a post on CoffeeScript that hit the frontpage, and one reference it linked was to a point of contention between CoffeeScript's developers and a library creator over whether CoffeeScript should introduce a nontrivial amount of wrapper code to support attribute setters and getters [1]. The library author made the following argument:

    For CoffeeKit specifically, the getters for all accessor 
    properties are totally without side effects. They are getters 
    because they have to wrap access through objective-c selectors. 
    I can't make them fields. I also can't in good conscience 
    make them all functions, requiring people to write:
    
    uikit.UIScreen.getMainScreen().getBounds()
    
    instead of:
    
    uikit.UIScreen.mainScreen.bounds
    
    yuck.
This, however, speaks directly to the point at hand: one could argue that a library creator in good conscience should make them all functions, since it would force library users to "reason about performance." It's tempting to remove extra syntax whenever possible, but sometimes verbosity can reduce technical debt insofar as it encourages developers to think about performance.

Ruby on Rails definitely leans towards reducing verbosity, but it has such a good ecosystem that even though I'd like a platform that makes things a bit more apparent about what things have/don't have side effects, it's still the best option for many projects that need to be created fast and maintained into the future. I'm looking forward to ES6 generators in Node.js, since they promise to create an ecosystem that avoids "callback hell" but still make it explicit where, in each level of code, expensive operations might occur [2].

[1] https://blog.toshokelectric.com/why-im-ditching-coffeescript... [2] http://zef.me/6096/callback-free-harmonious-node-js

link