11 ms·

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 usin

by zedshaw 14y ago

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.

cantankerous 14y ago
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.
- philwelch 14y ago
  If it threw in explicit returns at the end of each method and added back in all the optional parentheses, you'd be close to the average "Ruby code written by people who don't know Ruby that well" codebases you see in the wild so often.
rauljara 14y ago
To clarify, I don't think my original post implied that you were against teaching people how to learn each. Nor do I want to start out teaching beginning rubyists everything all at once. It was more to point out how important the mindset of each is. That's the mindset that you want to reach. And I'm not sure that teaching a construct that you'll never end up using is helpful. I think it just creates a mental construct that you'll have to overcome at a later stage. I don't think .each is so much harder to learn that it justifies getting a beginner in the wrong mindset. Though to be fair I've only ever explained it to people who've already known some programming, so there is a possibility that I'm underestimating the difficulty of teaching it. In any event, I thought the essay was totally worth the read even if I didn't agree with all of it. Thank you for it.
- edwinnathaniel 14y ago
  2 keywords: - First loop programming construct - Beginner Exhale. Inhale. Now back to the blog post and see how many constructs to understand .each correctly vs "just accept it for now that this is how it should work, we'll come back later". Have you ever read such books? the ones with "we'll come back to it later".
- wging 14y ago
  >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.
  - icebraining 14y ago
    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<int> 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 same: names = ["mary", "john"] caps = map(lambda name: name.upper(), names)
    - LeafStorm 14y ago
      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.
      - noblethrasher 14y ago
        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.
warmfuzzykitten 14y ago
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 teaching that imperative programming is natural and functional programming is only for "advanced" students? What are you going to teach the beginner when the goal is calculate the sum of the squares of a list of numbers?
- JulianMorrison 14y ago
  FWIW I learned on BASIC. "GOTO" looks natural to me. It's also much closer to the machine. Structured programming is a prettification of test-and-jump, and you have to be able to see through it, to use it well. Functional programming, on the other hand, is a bit of a conceptual leap away from the metal. If you're mapping two functions over a stream of data how many loops is it? In a dumb language like Ruby, it will be as many as your map() calls. But in Haskell, it will fuse them into one loop doing two operations. And the thing with functional programming is, you're not supposed to care - except, you do have to. Generating an endless unresolved series of thunks in Haskell is a beginner mistake. But if you can't see through the functional list-flipping to the generation and consumption of callable heap objects in a test-and-jump cycle, you're going to be scratching your head. My answer would be to teach both assembler and FP, and step up and down simultaneously. Start on Excel and move to Haskell, while also starting on 6502 or some such toy assembler, and moving to C, and meet in the middle at Scheme.
- thedufer 14y ago
  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?
btilly 14y ago
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.
pacala 14y ago
Right. Also, people should learn to swim by first dipping their tippy toes in a bathtub.
- batista 14y ago
  Well, maybe they should.
logical42 14y ago
I kinda liked it actually. It's a linear sequence of simple operations, and there is an explicit connection between each successive operation (i.e. subsequent operatons are performed on the return value of the last operation). That's what I personally love about method chaining anyhow.. Functional composition with a structure that's not completely ad hoc is kinda nice.
mjwalshe 14y ago
Hear hear - some times clarity of code is far more important than showing of your leetness.

by zedshaw 14y ago

cantankerous 14y ago

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.

philwelch 14y ago
If it threw in explicit returns at the end of each method and added back in all the optional parentheses, you'd be close to the average "Ruby code written by people who don't know Ruby that well" codebases you see in the wild so often.

rauljara 14y ago

To clarify, I don't think my original post implied that you were against teaching people how to learn each. Nor do I want to start out teaching beginning rubyists everything all at once. It was more to point out how important the mindset of each is. That's the mindset that you want to reach. And I'm not sure that teaching a construct that you'll never end up using is helpful. I think it just creates a mental construct that you'll have to overcome at a later stage. I don't think .each is so much harder to learn that it justifies getting a beginner in the wrong mindset. Though to be fair I've only ever explained it to people who've already known some programming, so there is a possibility that I'm underestimating the difficulty of teaching it. In any event, I thought the essay was totally worth the read even if I didn't agree with all of it. Thank you for it.

edwinnathaniel 14y ago
2 keywords: - First loop programming construct - Beginner Exhale. Inhale. Now back to the blog post and see how many constructs to understand .each correctly vs "just accept it for now that this is how it should work, we'll come back later". Have you ever read such books? the ones with "we'll come back to it later".
wging 14y ago
>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.
- icebraining 14y ago
  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<int> 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 same: names = ["mary", "john"] caps = map(lambda name: name.upper(), names)
  - LeafStorm 14y ago
    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.
    - noblethrasher 14y ago
      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.

warmfuzzykitten 14y ago

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 teaching that imperative programming is natural and functional programming is only for "advanced" students? What are you going to teach the beginner when the goal is calculate the sum of the squares of a list of numbers?

JulianMorrison 14y ago
FWIW I learned on BASIC. "GOTO" looks natural to me. It's also much closer to the machine. Structured programming is a prettification of test-and-jump, and you have to be able to see through it, to use it well. Functional programming, on the other hand, is a bit of a conceptual leap away from the metal. If you're mapping two functions over a stream of data how many loops is it? In a dumb language like Ruby, it will be as many as your map() calls. But in Haskell, it will fuse them into one loop doing two operations. And the thing with functional programming is, you're not supposed to care - except, you do have to. Generating an endless unresolved series of thunks in Haskell is a beginner mistake. But if you can't see through the functional list-flipping to the generation and consumption of callable heap objects in a test-and-jump cycle, you're going to be scratching your head. My answer would be to teach both assembler and FP, and step up and down simultaneously. Start on Excel and move to Haskell, while also starting on 6502 or some such toy assembler, and moving to C, and meet in the middle at Scheme.
thedufer 14y ago
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?

btilly 14y ago

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.

pacala 14y ago

Right. Also, people should learn to swim by first dipping their tippy toes in a bathtub.

batista 14y ago
Well, maybe they should.

logical42 14y ago

I kinda liked it actually. It's a linear sequence of simple operations, and there is an explicit connection between each successive operation (i.e. subsequent operatons are performed on the return value of the last operation). That's what I personally love about method chaining anyhow.. Functional composition with a structure that's not completely ad hoc is kinda nice.

mjwalshe 14y ago

Hear hear - some times clarity of code is far more important than showing of your leetness.