Live data from Hacker News

Programming Languages Have Social Mores Not Idioms

learncodethehardway.org

51–60 of 179 posts

Re: Programming Languages Have Social Mores Not Idioms

#51
post #32

Earlier quoted context omitted.

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,…

for-loops and .each had weird scoping rules until Ruby 1.9. In Ruby 1.9 for some weird reason they fixed .each but not for-loops. No idea why. So, if you're saying use .each for technical solution to a problem in Ruby, then your proposed solution only works in some versions of Ruby.

Re: Programming Languages Have Social Mores Not Idioms

#52

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 th…

You are right, and once again I am not against using functional programming, OOP, message passing, or any of the things I mention about .each.

I'm against using .each as a first looping construct. In fact, go look at your supposedly better last line of code and tell me if you think a newbie would even begin to comprehend that? Hell I'm a programming veteran and Ruby veteran and I want to metaphorically punch you in the gonads for that line of code.

Re: Programming Languages Have Social Mores Not Idioms

#54
post #27

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.

The concept of a jump is not one you want to ever teach, and I think you've chosen to go into more detail in one list than the other. In terms of "what does it do", both bits of code call "puts elem" on each element of the array. In terms of "what it's actually doing", the .each example is forming a block and passing it to a method, while the for example is a special syntax with its own scope implications. So the complicated parts of the .each version (blocks and method calls) are general concepts used throughout the language, that you would always want to teach to learners sooner or later. Whereas the complicated parts of the for example - the scoping and the for syntax itself - are dead ends that don't help you learn the rest of the language at all.

Re: Programming Languages Have Social Mores Not Idioms

#55
> In the process I've stumbled on what Rubyists call an "idiom", the use of .each to do loops instead of a for-loop. To them this is one of the most important signs that you are a real Ruby programmer. They look at this usage of one looping construct over another as some sign that you are incompetent, and haven't been properly indoctrinated into the Ruby community's ways.

As a Smalltalker, I think select/find/collect/each to be wonderful things, as they are of the same spirit as the do: collect: select: reject: methods in the Smalltalk Collection methods. That said, I find the notion of stigma attached to certain constructs to be counter-productive. In my experience, such attitudes are more about socially scoring points and vying for social dominance than they are actually about improving the community's code. However you get the functionality done is fine, so long as it's short and understandable.

(Such stigma attached to situations where people could use inject:into: but didn't was often counterproductive to readaibility in the Smalltalk community.)

Re: Programming Languages Have Social Mores Not Idioms

#56

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…

Just to be pedantic, it is actually the Smalltalk "do:". :)

Re: Programming Languages Have Social Mores Not Idioms

#57
post #25
post #23

Earlier quoted context omitted.

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.

Oh, no concern at all about the ruby style guide. I even point people at it in the book so they can start grasping and writing code with other people. My mention of the guide is not intended as a knock on the guide at all.

Re: Programming Languages Have Social Mores Not Idioms

#58
post #54
post #27

Earlier quoted context omitted.

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.

The concept of a jump is not one you want to ever teach, and I think you've chosen to go into more detail in one list than the other. In terms of "what does it do", both bits of code call "puts elem" on each element of the array. In terms of "what it's actually doing", the .each example is forming a block and passing it to a method, while the for example is a special syntax with its own scope implications. So the com…

>The concept of a jump is not one you want to ever teach,

That is again another arbitrary social more invented by a rant written by Dijkstra. Learning that a computer processes code by using jumps is an important concept to learn, and it's actually a useful technique in many languages. Saying someone should never learn them is just stupid.

Re: Programming Languages Have Social Mores Not Idioms

#60
post #52

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 th…

You are right, and once again I am not against using functional programming, OOP, message passing, or any of the things I mention about .each. I'm against using .each as a first looping construct. In fact, go look at your supposedly better last line of code and tell me if you think a newbie would even begin to comprehend that? Hell I'm a programming veteran and Ruby veteran and I want to metaphorically punch you in t…

This is a good point. To play a little off your blog post, a person new to Ruby could view the second line of code more as an idiomatic expression (which it's not really, but it can have the appearance of being one) in that it doesn't make obvious logical sense and is harder to translate to a more familiar language...giving a "raising ravens" (Spanish) vs. "can of worms" (English) scenario.

I think it'd be kinda cool if one could develop sort of a "ruby-normal-form" that could take some ruby expressions and translate them into a more normalized form using things like for-loops, etc....granted normalizing a lot of ruby code might be hard, intractable, or maybe even impossible.

Post reply on HN