Live data from Hacker News

Programming Languages Have Social Mores Not Idioms

learncodethehardway.org

101–110 of 179 posts

Re: Programming Languages Have Social Mores Not Idioms

#101
post #80

Earlier quoted context omitted.

> I'm not sure that teaching a construct that you'll never end up using is helpful. But that was precisely Zed's point! You will certainly end up using it, though you may never use it in Ruby . .each is not transferable, and for-loops are. Zed's teaching Ruby as an introduction to programming , not just to Ruby in itself.

each is definitively transferable for many languages. Javascript has Array.map(), which is almost the same: var numbers = [1, 4, 9]; var roots = numbers.map(Math.sqrt); /* roots is now [1, 2, 3], numbers is still [1, 4, 9] */ C# has IEnumerable.Select(): IEnumerable squares = Enumerable.Range(1, 10).Select(x => x * x); /* squares is [1, 4, 9, 16, ...] */ Python has map(), which isn't OOP but accomplishes mostly the s…

The examples you give are equivalents to Enumerable#map, not Enumerable#each. In JavaScript, the closest equivalent to #each is Array.forEach(). In C# and Python, while methods equivalent to #each may exist (I'd have to double-check the docs to be sure), the recommended way to accomplish the same functionality as #each is...a for loop.

Re: Programming Languages Have Social Mores Not Idioms

#102

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…

When I was teaching myself how to program in VBA, I remember thinking "there's got to be some syntax to take a list of things and iterate over each of them." I was of course looking for a for loop (or for each). Without knowing to even google "for loop in VBA", it was a pretty big deal to finally discover, "Hey, programming languages have loops!" Later, after coding for a couple of years and picking up .NET, I eventu…

this is not a dig at you specifically, but more a lament about the basics of computing, and what's been lost.

30 years ago, I got a computer, and it came with this: http://www.worldofspectrum.org/ZX81BasicProgramming/

Chapter 12 was 'looping'. I'm not claiming I was some programming genius, but to have been given a computer with a manual that, in I know we've all got the google at our fingertips today, but I suspect that many people don't even know how to express what they want to do in basic enough terms to search - thedailywtf has examples of that (sadly). I don't know if there's a way to reverse this, but it struck me that we've definitely lost something (or perhaps 'we' never all had it) when you state: 'Without knowing to even google "for loop in VBA"'.

:/

Re: Programming Languages Have Social Mores Not Idioms

#103

Earlier quoted context omitted.

each is definitively transferable for many languages. Javascript has Array.map(), which is almost the same: var numbers = [1, 4, 9]; var roots = numbers.map(Math.sqrt); /* roots is now [1, 2, 3], numbers is still [1, 4, 9] */ C# has IEnumerable.Select(): IEnumerable squares = Enumerable.Range(1, 10).Select(x => x * x); /* squares is [1, 4, 9, 16, ...] */ Python has map(), which isn't OOP but accomplishes mostly the s…

The examples you give are equivalents to Enumerable#map, not Enumerable#each. In JavaScript, the closest equivalent to #each is Array.forEach(). In C# and Python, while methods equivalent to #each may exist (I'd have to double-check the docs to be sure), the recommended way to accomplish the same functionality as #each is...a for loop.

C# doesn't have an Enumerable.ForEach (but it does have a List.ForEach).

More significantly, it has a Parallel.ForEach which is recommended for iterations that can be done in parallel.

Re: Programming Languages Have Social Mores Not Idioms

#104
post #80

Earlier quoted context omitted.

> I'm not sure that teaching a construct that you'll never end up using is helpful. But that was precisely Zed's point! You will certainly end up using it, though you may never use it in Ruby . .each is not transferable, and for-loops are. Zed's teaching Ruby as an introduction to programming , not just to Ruby in itself.

each is definitively transferable for many languages. Javascript has Array.map(), which is almost the same: var numbers = [1, 4, 9]; var roots = numbers.map(Math.sqrt); /* roots is now [1, 2, 3], numbers is still [1, 4, 9] */ C# has IEnumerable.Select(): IEnumerable squares = Enumerable.Range(1, 10).Select(x => x * x); /* squares is [1, 4, 9, 16, ...] */ Python has map(), which isn't OOP but accomplishes mostly the s…

#each and #map are not meant to be the same thing. #each in any language is meant only for side-effects. If you only care about the return value, #map is a much better choice. (Similarly, if you only care about the return value but want many items condensed into one "reduced" item, you want #reduce.)

Re: Programming Languages Have Social Mores Not Idioms

#105

I disagree about the 'each' being a 'social more' as opposed to 'for'. The most important thing you will ever learn about conditional loops is that effectively they are all shorthand for combinations of compare statements and conditional jumps in assembly. Past that really, none are more conceptually simple than any other... So the analogy of 'each' being "piece of cake" to 'for' being "easy" doesn't really hold to m…

Well, at least in Ruby, there's one way in which each is more abstracted than for; each creates a new scope, while for does not. This actually is a reason I'd prefer to teach each. On the other hand, I agree with Zed that for is a better abstraction than each, and I disagree that each and for are at the same level of abstraction. If you're approaching it in the abstract, sure, they're both pretty high-level. But each…

> 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 for are at the same level of abstraction. If you're approaching it in the abstract, sure, they're both pretty high-level. But each is as close to pure functional as you get and for is plain iterative.

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.

Secondly, how is 'each' any less 'plain iterative' than 'for...' when they both do exactly the same thing (iterate)? Also, how is it more 'functional'? To me its more object-oriented in that the object is stated first, but this isn't to say it is less plain or more abstract.

> And assembly is iterative, so I'd call for better for giving people a sense of how the metal works. Which, I think, is important for newbies.

I agree that Assembly is good to learn, but not sure what you mean by calling it 'iterative'.

Re: Programming Languages Have Social Mores Not Idioms

#106
post #52

Earlier quoted context omitted.

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…

I'm guessing Zed first learned to program using for loops so they look "natural" and easier for beginners to learn than functional callbacks. That seems like a testable proposition, but I'm guessing it isn't so. There aren't too many situations in life outside programming and racing where people go around in circles to get something done. Furthermore, the choice of print in the example begs the question. Are you teac…

In a very real sense, imperative programming _is_ natural. Its much closer to how computers work. Whether this means that its an easier way to learn is up for debate. (For the record, I think it is easier for a majority of people, but that functional would be easier for a significant minority.) Your phrasing of that part just kind of bothered me.

I think we already teach beginners that you calculate the sum of the squares of a list of numbers with a for loop. Actually, its a fairly common type of problem when you're learning about for loops. Maybe I'm missing your point?

Re: Programming Languages Have Social Mores Not Idioms

#107
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…

If you hate that last line, you must hate Unix pipelines as well. Because both accomplish similar things and are surprising to newcomers in a similar way.

Re: Programming Languages Have Social Mores Not Idioms

#108
post #40
post #15

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 (edit: and itself contains an idiom, "good clean", which you can recognize as an idiom simply by reversing the two words), but I think he's right about the important thing, programming language mores. It's crazy odd how what appear as purely technical constructs become nuclei for al…

Yes, you avoid idioms in writing if you want it to be clear. If you're going for style, as in fiction writing or for artistic purposes, then do whatever you want.

I'd like to see an example of a good writer, or even one sufficiently long piece of clear writing, that doesn't use idioms. Language is saturated with them.

You'd be on more solid ground (and closer to your point about loops) to say that, when teaching foreign languages to beginners, idioms are best avoided because the student is struggling just to know the individual words. Even then, though, I doubt I ever took an introductory language class that didn't teach at least some idioms; you can't get a feel for a language (or fully understand any real-world text) without them.

Re: Programming Languages Have Social Mores Not Idioms

#109

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…

Your comment is hyperbole in every way. The post made 2 points:

- we should be calling "idioms" "social mores"

- we should teach beginners simpler constructs instead of idiomatic ones, especially `for` instead of `.each` in ruby.

Note that you agreed with his second point.

He has no responsibility to address the upsides of `.each`, since that's not the point of his article. He wasn't talking about advanced programmers, he was specifically addressing why he didn't teach `.each` in his book, and why it shouldn't be taught to other beginner programmers.

Re: Programming Languages Have Social Mores Not Idioms

#110

If you're coming in as a programming novice, "each" and "for" constructs should look equally as foreign, so you may as well teach the standard conventions. It takes longer to unlearn something, than it is to learn. >You aren't creating programmers, you're creating good little Rubyists. You should be creating good Rubyists, if you're using Ruby to teach programming.

If your goal is to create programmers, then you should be creating programmers, not good little rubyists/pythonistas/etc
Post reply on HN