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

21–30 of 179 posts

Re: Programming Languages Have Social Mores Not Idioms

#21

Post by zedshaw »

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.

Re: Programming Languages Have Social Mores Not Idioms

#22

Post by zedshaw »

paulgb wrote: post #4

Programming isn't just about giving instructions to a computer, it's an act of communication to anyone who will read your code down the road. Having a consistent set of rules is an important part of that communication. Just as a style guide for a natural language can help readability, good conventions can make code more readable. Python goes as far as defining an official style guide (PEP-8)

I agree, but that's a totally different topic from what I'm talking about.

Re: Programming Languages Have Social Mores Not Idioms

#23

Post by zedshaw »

why-el wrote: post #17

I don't see the relevance of the style guide mentioned for the debate over how to teach beginners. When you check out a guide, it has to be assumed you are familiar with pretty much most of the syntax of your language.

It's an example of that particular social more and the canonical example of good vs. bad looping over an array. That's why I used it.

Re: Programming Languages Have Social Mores Not Idioms

#24

Post by jasim »

There is an important reason why one would use #each instead of a for loop: encapsulation.

Looping over a collection object requires some knowledge of its internal state (length in the case of a simple linear structure like Array). In most cases where we use for loops, that information isn't really relevant. There is no need to expose it to the outside world and break encapsulation.

Being consistent in using #each helps when you have complex/custom collection objects where iteration can't be done through a simple for loop. The object might not want to expose its underlying collection and hence can't provide a suitable way to use a for loop on it. Or maybe the collection object has dead elements that it wants to skip and so on. There are any number of reasons to hide the implementation details of the iteration from the external world.

Given this and since Ruby has a powerful block syntax, favouring #each fanatically over for loops, IMHO, is a good thing.

EDIT: I'm also guilty of accusing LRTH with the 'not idiomatic enough' charge in a blogpost I recently wrote for Ruby beginners at http://www.jasimabasheer.com/posts/meta_introduction_to_ruby....

Re: Programming Languages Have Social Mores Not Idioms

#25

Post by why-el »

zedshaw wrote: post #23
why-el wrote: post #17

I don't see the relevance of the style guide mentioned for the debate over how to teach beginners. When you check out a guide, it has to be assumed you are familiar with pretty much most of the syntax of your language.

It's an example of that particular social more and the canonical example of good vs. bad looping over an array. That's why I used it.

I see your concern, if I was a beginner and I googled around I might be inclined to learn the supposedly good looping which might be difficult.

Re: Programming Languages Have Social Mores Not Idioms

#26

Post by philwelch »

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…

In Ruby, I always use "map" instead of "collect", partially because it's four fewer letters and partially because its intent is a little more obvious.

Re: Programming Languages Have Social Mores Not Idioms

#27

Post by zedshaw »

tomjakubowski wrote: post #9

Why does the author insist that to teach each to a beginner he has to teach all of those concepts? Sure, to understand it fully you need to know about those things, but you can definitely get a beginner far enough along without explaining every detail. Did K&R explain everything about the preprocessor with their "Hello, world!" example? Or the implications of different return codes from main(), what 'return' from a f…

K&R eventually did, even if they didn't at the very beginning. I also don't teach everything right away. But, if I'm going to teach the concept of looping, I'm going to teach the one that's easiest to grasp and fully know. That's a for-loop, not a .each method dispatch.

Re: Programming Languages Have Social Mores Not Idioms

#29

Post by rsobers »

[deleted] wrote: post #20

[deleted]

The idea behind "The Hard Way" is that it's hard because you have to do all the legwork the book prescribes in order to get much out of it. It really has nothing to do with being hard because the concepts it teaches are difficult to grok.
Post reply on HN