Live data from Hacker News

Programming Languages Have Social Mores Not Idioms

learncodethehardway.org

1–10 of 179 posts

Re: Programming Languages Have Social Mores Not Idioms

#2
I've never really understood the Ruby community's attitude toward for loops. I learned Ruby as my first language and read many blog posts and instructional books that told me to absolutely avoid the for loop. Of course when I started to learn JavaScript and C, I had to figure out their versions of the for loop then, and it made me start wondering why there had been such opposition to something that seemed to be a normal part of the Ruby language. I can understand "idioms" if they have some benefit over non-idiomatic versions, but in a language like Ruby that supposedly embraces TMTOWDI, I can't, for the life of me, figure out why .each is always best.

Re: Programming Languages Have Social Mores Not Idioms

#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)

Re: Programming Languages Have Social Mores Not Idioms

#5
post #2

I've never really understood the Ruby community's attitude toward for loops. I learned Ruby as my first language and read many blog posts and instructional books that told me to absolutely avoid the for loop. Of course when I started to learn JavaScript and C, I had to figure out their versions of the for loop then, and it made me start wondering why there had been such opposition to something that seemed to be a nor…

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 available, why not take advantage of it?

Re: Programming Languages Have Social Mores Not Idioms

#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 comment on each vs for loops, but in general there's a practical, performance-based advantage to idiomatic coding.

Re: Programming Languages Have Social Mores Not Idioms

#7
The word "idiom" has two different senses. First, there's the sense that the author is discussing. In this sense idioms are expressions whose meanings aren't derivable from the meanings of their parts (linguists call this "non-compositionality"). The other sense of "idiom" simply means "an expression that characterizes idiomatic speech.

Now "idiomatic" also has two senses. First, it can mean "having to do with idioms". Second, it can mean "peculiar to a particular group, individual or style". (See http://www.merriam-webster.com/dictionary/idiomatic)

So, I think when people speak of idioms regarding programming languages they're using the second of the above senses. While this sense might be characterized as having to do with social mores, I don't think it's a misuse of the word "idiom". People don't mean to say that .each statements are non-compositional in the way that "kick the bucket" is. Indeed, given that programming languages have formal grammars/semantics it's hard to imagine what non-compositionality would be at all (though I'm sure any good Perl programmer could probably give some examples!)

Re: Programming Languages Have Social Mores Not Idioms

#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 function even means, etc?

Re: Programming Languages Have Social Mores Not Idioms

#10
post #2

I've never really understood the Ruby community's attitude toward for loops. I learned Ruby as my first language and read many blog posts and instructional books that told me to absolutely avoid the for loop. Of course when I started to learn JavaScript and C, I had to figure out their versions of the for loop then, and it made me start wondering why there had been such opposition to something that seemed to be a nor…

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 commonly used, and how do you do filter in Rails?

Post reply on HN