[btown]

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