Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming Languages Have Social Mores Not Idioms

learncodethehardway.org

Post reply on HN
Print view View original

41–50 of 179 posts

Re: Programming Languages Have Social Mores Not Idioms

#41

Post by monkeyfacebag »

zedshaw wrote: post #21
monkeyfacebag wrote: post #6

I always interpret "idiomatic" as "avoiding performance issues". In Python, for example, using the join method on strings is not only idiomatic, it's performant. Even if a particular idiom has no effect on performance, the worst that happens is I write idiomatic code. Not only that, but idiomatic coding allows me to write performant code without having to understand why it performs well. I don't know Ruby, so I can't…

> I always interpret "idiomatic" as "avoiding performance issues". Huh? That is definitely not what it means. That may be a byproduct if the language implementers then make the social mores they admire the ones that perform the best, but otherwise that's not what makes something an idiom or a social more.

> That may be a byproduct if the language implementers then make the social mores they admire the ones that perform the best

I understand the definition of the word idiom. I'm saying that the quoted scenario is, in fact, not just hypothetical, but likely. Thus, following idiomatic style can help one avoid performance issues.

Re: Programming Languages Have Social Mores Not Idioms

#42

Post by masklinn »

losvedir wrote: post #10
tomjakubowski wrote: post #5

Earlier quoted context omitted.

I don't think using a for loop is "taboo" among Rubyists in general, just for iterating over each element of an array, where Array#each, Array#collect, and Array#inject are preferred. This probably comes from the influence of Lisp and its emphasis on writing code as a series of list operations. To my mind, anyway, using each/collect/inject expresses intent much more clearly than a for loop. If a clearer approach is a…

I, too, think like that, although Ruby's nomenclature frequently confuses me. Coming from Scheme/Haskell I'm quite at home with 'map', 'filter', and 'fold'. However, Ruby uses the methods you mention, "collect" and "inject", and these in turn have a few synonyms. And as best I can tell, Ruby's 'filter' variant, 'find' collides with ActiveRecord. What's the general community take on these functions? Which name is comm…

> I, too, think like that, although Ruby's nomenclature frequently confuses me.

Most of them come from Smalltalk's Iterable protocol[0]: that's the source for `select:aBlock`, `collect:aBlock`, `inject:thisValue into:binaryBlock` (Smalltalk uses `fold` when there's no starting value, and `inject` as "fold by injecting initial value"), `detect:aBlock` and `reject:aBlock`.

Smalltalk also uses `do:aBlock` where Ruby uses `each`, likely due to `do` being a keyword in Ruby.

Also, `find` is not `filter` (that's `select`, aliased to `find_all`). `find` is also `find` in Haskell[1] (and maps to Smalltalk's `detect`, also useable in Ruby).

> 'find' collides with ActiveRecord

Uh... no, ActiveRecord collides with Enumerable, I'm pretty damn sure Enumerable came first.

> how do you do filter in Rails?

What's wrong with #find? Or #where? Or #find_by_*? Same name, different namespace, different meaning. Kind-of the point.

[0] http://www.gnu.org/software/smalltalk/manual-base/html_node/...

[1] http://hackage.haskell.org/packages/archive/base/latest/doc/...

Re: Programming Languages Have Social Mores Not Idioms

#43

Post by weavejester »

zedshaw wrote: post #32
twk wrote: post #19

not following the standard idiom of a particular programming language causes people to balk because it shows how unfamiliar the author is and how little code the author has read or been exposed to in that language. Its a huge sign that even though the author may be smart there probably beginner level bugs in the code.

It's only a sign because the community adopted it as an arbitrary social norm. There's not really any technical reason to choose one over the other. In fact, don't take my word for it, here's Dave Thomas questioning the .each requirement: http://video2012.scotlandonrails.com/D2_ML_07-Ruby1280_b.mp4

Ruby for-loops have unusual scoping of loop variables, and if you're not familiar with this it can prove to be a source of bugs. I was bitten by this some years ago when I was first learning Ruby, and it took me a while to track down the problem.

An "each" block has the scoping you'd expect, and is more consistent with the rest of the Ruby looping constructs (like select/filter or collect/map). It's not a huge deal, but there definitely are technical reasons not to use it.

Re: Programming Languages Have Social Mores Not Idioms

#45

Post by jballanc »

zedshaw wrote: post #37
jballanc wrote: post #31

Before I learned Ruby, I knew C, Obj-C, C++, Java...all languages that have and use "for" extensively. Coming to Ruby and learning "each" was an eye opening experience for me. Suddenly, the whole notion of iterators become clear to me. (While I had used them in the past, I had only marginally understood them.) After using "each" for a while, I came to realize that I was programming in a functional style without even…

Well remember, I'm not against .each at all. I'm against it as a first looping construct for beginners. I even start people off in my book by sneaking in functional programming, again because it's easier to teach. They even write a game that is basically one giant sequence of mostly tail calls without knowing it.

Right, I think where people have to get over themselves is that teaching something is often very different from using something. When I was being trained as a chemist, I was started with techniques that were over 150 years old, and that no one in their right mind would use in a professional lab (you really think chemists do tedious titrations when you can buy a pH meter that's 10x more accurate?).

In other words: programmers don't understand pedagogy. Nothing really new there.

I've very much enjoyed the books though...went back and did "Learn C the Hard Way" even though I've been using C for almost 18 years. Can't wait to read "Learn Clojure the Hard Way"... ;-)

Re: Programming Languages Have Social Mores Not Idioms

#47

Post by monkeyfacebag »

dsrguru wrote: post #13
monkeyfacebag wrote: post #6

I always interpret "idiomatic" as "avoiding performance issues". In Python, for example, using the join method on strings is not only idiomatic, it's performant. Even if a particular idiom has no effect on performance, the worst that happens is I write idiomatic code. Not only that, but idiomatic coding allows me to write performant code without having to understand why it performs well. I don't know Ruby, so I can't…

Not always though. I don't know if this is still the case, but "while true" used to be more idiomatic in Python than "while 1" even though the latter had better performance due to the state of the cpython implementation at the time.

As far as I know, this has been changed in Python 3. See: http://stackoverflow.com/questions/3815359/while-1-vs-for-wh...

It may be the case that at any given point, the idiomatic way is not the fastest. However, if idioms are widely adopted, the language implementers have good reason to optimize them. I'm not saying that's what happened in this case, but I think it's reasonable claim to make in general.

Re: Programming Languages Have Social Mores Not Idioms

#48

Post by rauljara »

Zed is making a number of points, so I don't want to sound like I'm arguing against all of them. But particularly on the matter of each... if all we were talking about were each I think Zed would have an excellent point. But wrapped up with each are all of the other fantastic enumerable methods like map/collect, select/find, inject/reduce, as well as each_cons, each.with_index, map.with_index, etc. These are where the power and expressiveness of ruby really come into play. For example:

  users.select(&:meets_some_critera?).each(&:update!)
You could totally do that in a for each loop if you wanted. But it isn't really composable. While this works for the basic update...

  for user in users do
    user.update! if user.meets_criteria?
  end
... what if you wanted to then sum up the new account balances? In the first example, you'd just chain on a couple more enumerable methods:

  users.select(&:meets_some_critera?).each(&:update!)
    .map(&:account_balance).inject(&:+)
With the for each construct you'd have to pass in an accumulator variable and keep track of whether to sum or not. While you certainly can do it in a for each construct, I'd argue that you'd be missing out on what makes ruby, ruby. And getting beginners in that more functional(ish) frame of mind sooner rather than later is a very good thing.

--edited a few times for formatting/clarity

Re: Programming Languages Have Social Mores Not Idioms

#49

Post by zedshaw »

monkeyfacebag wrote: post #41
zedshaw wrote: post #21

Earlier quoted context omitted.

> I always interpret "idiomatic" as "avoiding performance issues". Huh? That is definitely not what it means. That may be a byproduct if the language implementers then make the social mores they admire the ones that perform the best, but otherwise that's not what makes something an idiom or a social more.

> That may be a byproduct if the language implementers then make the social mores they admire the ones that perform the best I understand the definition of the word idiom. I'm saying that the quoted scenario is, in fact, not just hypothetical, but likely. Thus, following idiomatic style can help one avoid performance issues.

Not at all likely, and in fact if you believe this without first investigating its validity then you may be bit by bad performance. A very real scenario is that you use something blindly because everyone else does, thinking it performs well, and then you find out it actually doesn't.
Post reply on HN