Live data from Hacker News

Programming Languages Have Social Mores Not Idioms

learncodethehardway.org

171–179 of 179 posts

Re: Programming Languages Have Social Mores Not Idioms

#171
post #158

Earlier quoted context omitted.

You can teach .each { | | } exactly as you would teach for in do end. The .each variant allows the student to discover a rich palette of correlations as he progresses, the for do end variant is a dead end he needs to forget sooner or later. As a student, I know precisely which variant I'd chose. Do you?

So, define a closure in terms that someone who has just learned what a variable is can understand. "Just memorize this syntax and do it" is not allowed.

I already did:

> There is a function "each" that applies to arrays. "Each", for each element in the array, binds "elem" to the element value, then executes the body of the code block. The code applies "each" to array "arr" and executes "puts elem" for each element.

Re: Programming Languages Have Social Mores Not Idioms

#172
post #158

Earlier quoted context omitted.

You can teach .each { | | } exactly as you would teach for in do end. The .each variant allows the student to discover a rich palette of correlations as he progresses, the for do end variant is a dead end he needs to forget sooner or later. As a student, I know precisely which variant I'd chose. Do you?

So, define a closure in terms that someone who has just learned what a variable is can understand. "Just memorize this syntax and do it" is not allowed.

My issue here is that the for version is pretty much exactly "Just memorize this syntax and do it"

Re: Programming Languages Have Social Mores Not Idioms

#173

I'm sorry, but this post is absolutely ridiculous in every way. I think most programmers understand what is meant when people say a programming "idiom", just like most people understand that it's OK to call small representative computer graphics "icons" even though they're not physical religious symbols. Words gain new meanings in new contexts, that's how language evolves. Complaining about it after-the-fact is just…

We call people that interact with our software 'users' despite the drug connotation. Hardware stores don't say that, heck even pharma companies don't.

Re: Programming Languages Have Social Mores Not Idioms

#174

Earlier quoted context omitted.

> I don't know where on earth he got "By definition an idiom is something you remove from good clean writing," which is obviously not true Maybe from all those classic books on writing, like the "Chicago Manual of Style", "On Writing Well" and "The Elements of Style", which all agree on the point. Where you got this bizarro impression that idioms are NOT to be avoided in writing? Idioms are cliches, and they needless…

I suppose it's foolish to belabor the point, but (a) is it just me or are you sounding a bit of a bully? and (b) everything you wrote is untrue. My impression comes from observing language: it is saturated with idioms. You can't throw them all out (without a lot of unnatural effort) nor is there any need to. You might as well say that a musician should use only notes and not chords, or avoid standard chord progressio…

>Style manuals have their place but are hardly scripture, and there are countless examples of great writers breaking every rule in the book. Indeed, Strunk & White breaks its own rules, sometimes when describing the very rule it's breaking (which is part of its charm [1]). So even if your claim were correct, it wouldn't prove anything.

Breaking a rule ocassionally is not the same as not having the rule on the first place. For one, they can "break their own rule" precisely because the rule exists. They break the rules they set with caution and only when the feel it is needed. That's the way it is with most rules, about writing or anything else. The rule provide a guideline for the 90% of times.

Re: Programming Languages Have Social Mores Not Idioms

#175

Earlier quoted context omitted.

How did .each have weird scoping pre-1.9? I've run across problems with for-loops, but .each has always behaved predictably, even in 1.8. Could you perhaps provide an example of code using .each that does the wrong thing in 1.8, but the right thing in 1.9?

a = 0 [1, 2, 3].each { |a| } a # => 3

Ah, thanks for the clarification. I guess that means there are at least two odd things about scoping in 1.8 loops.

Re: Programming Languages Have Social Mores Not Idioms

#176

Earlier quoted context omitted.

I suppose it's foolish to belabor the point, but (a) is it just me or are you sounding a bit of a bully? and (b) everything you wrote is untrue. My impression comes from observing language: it is saturated with idioms. You can't throw them all out (without a lot of unnatural effort) nor is there any need to. You might as well say that a musician should use only notes and not chords, or avoid standard chord progressio…

> Style manuals have their place but are hardly scripture, and there are countless examples of great writers breaking every rule in the book. Indeed, Strunk & White breaks its own rules, sometimes when describing the very rule it's breaking (which is part of its charm [1]). So even if your claim were correct, it wouldn't prove anything. Breaking a rule ocassionally is not the same as not having the rule on the first…

(Edited to be less irritable.) You haven't replied to the main point, which is to give examples of your alleged rule from the three style guides you cited. As far as I can tell, it's not in any of them.

Re: Programming Languages Have Social Mores Not Idioms

#177

Earlier quoted context omitted.

“for” is the raw loopy stuff out of which other looping constructs are made—it’s fairly arbitrary. If you’re implementing an iteration construct, then by all means “for” is the thing to use. But in normal use it’s best to express your intent through more common, composable constructs such as maps, folds, and zips. There’s certainly less overhead in reading a non-trivial loop written as a composition than one written…

I have no dog in this fight, I was just calling out the hyperbole on the ancestor comment.

If you didn't get my intent, the last part of the article which you recommended was highly biased and after reading it I was left questioning the author's motive.

Re: Programming Languages Have Social Mores Not Idioms

#178

Earlier quoted context omitted.

> each creates a new scope, while for does not Yes. Its a bit of a side issue and the OP hardly mentioned it, so I thought I'd ignore it. I can see how in this way you then might see 'each' as more 'abstract', but this difference doesn't back up the OP's main points (eg. the "piece of cake"/"easy" analogy). > On the other hand, I agree with Zed that for is a better abstraction than each, and I disagree that each and…

>Firstly, how one abstraction can implicitly be a 'better abstraction' than another I am not sure. Only perhaps because you (individually) understand it better or have used it before it is more useful to you. That was clumsy of me. I meant to say that it was a better abstraction for teaching iterative programming, which is a good tool for getting people productive with a minimum of training. > Secondly, how is 'each'…

Yeah. But isn't the whole point of high level constructs that you can use and conceptualize them more easily than, and without prior understanding of, what happens at a lower-level? Just like you don't have to learn exactly how CPU registers work to learn C, you also don't have to learn all the principles of computer science behind 'each' before you can use it....

also - maybe you mean 'imperative' rather than 'iterative'?

In terms of 'abstract', I can see where you are coming from that there are more underlying principles and its more abstract from this point of view. From the point of view I was at, they are both referencing the same variables doing the same thing so its the same abstraction from a programmatic(?) point of view. Probably a poor/confusing choice of words on my part...

Re: Programming Languages Have Social Mores Not Idioms

#179

Earlier quoted context omitted.

I have no dog in this fight, I was just calling out the hyperbole on the ancestor comment.

If you didn't get my intent, the last part of the article which you recommended was highly biased and after reading it I was left questioning the author's motive.

I don't see the bias or any reason to question his motive, so no, your intent was not clear. I think you'll need to spell this one out for me.
Post reply on HN