7 ms·

This is a troll, or the author completely lacks any pedagogical skills. The offending (sic) code: arr.each { |elem| puts elem } Explanation: There is a f

by pacala 14y ago

This is a troll, or the author completely lacks any pedagogical skills. The offending (sic) code: arr.each { |elem| puts elem } Explanation: 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. Concepts: variable, binding, function, block, array. Done. The prosecution charges: > Variables Basic elementary concept, if you don't get this, you should not be coding yet. > Arrays Basic elementary concept, if you don't get this, you should not be coding yet. > Enumerable I have no idea what enumerable is, but I can read the code just fine. > Inheritance I have no idea what inheritance means in this context, but I can read the code just fine. > Mixins vs. Multiple Inheritance For lack of better words, wtf is the author talking about? > Message passing and dispatch. Ditto wtf. > Function calls. Basic elementary concept, if you don't get this, you should not be coding yet. > Blocks passed to function calls. Arguably basic elementary concept, in spite of the long tradition of Basic teaching us otherwise. But then Basic taught us GOTO is a good idea, fortunately we've got past that idea eons ago. > Yielding variables to blocks. I have no idea what yielding is or how it helps in this context. Still I can understand the code just fine. > Scope, specifically for blocks. Scope is a subcategory of variables, if you don't get scoping then you don't get variables, see blurb on "Variables" section.

sp4rki 14y ago
For starters, you do realize that the author/troll of the article is Zed Shaw right? The fact that you can read a piece of code doesn't mean that you understand it. The whole point of teaching how to program is to actually get the student to learn what is actually going on, not just get them to a point where they can give a half assed explanation that really doesn't teach a thing. Repeating the line of code with extra words to convey meaning most certainly does not make it a valid explanation. And then you come along with a list of "responses" to the concepts outlined in the article, out of which you don't even actually understand half of, and completely destroy your initial argument because of it. You complain that Zed is a troll because you can actually read the code easily, when the whole topic of his is actually wether you can understand it. It's a completely different game. You basically just proved Zed right. The problem with teaching .each first according to Zed is that since you don't understand even half of what is going on, you just do things blindly because you've grown to predict the behavior you expect from a specific piece of code. For dessert I'm gonna "troll" a little bit. 1) If I should know variables, arrays, function calls, blocks passed to function calls (which includes an arbitrary comment about BASIC and goto statements), and scope, before I start coding then how the hell am I supposed to learn those very basic concepts? I mean according to you I shouldn't be coding right? 2) If you really don't grasp the concepts you say you don't understand in the list, you probably don't program for a living and/or have not had to actually teach any programming concepts besides the very basics. If this is the case, I'd argue that you still have a long way to go before actually having the experience to compare both "teaching orders" being compared here. 3) You give me the impression of a guy that has only done a bunch of jQuery and perhaps a Rails tutorial or two... AMIRITE? I'm sorry if this comes off like a lengthy angry diatribe (rest assured it's not my intention), but you tried to sound knowledgeable and ended up putting your own foot in your mouth. My mother once told me to only open my mouth if I know what I'm talking about. That my friend is my advice for you.
- pacala 14y ago
  > The fact that you can read a piece of code doesn't mean that you understand it. Therein lies the troll. Understanding is not figuring out how to derive the code from first principles. If that were true, you shouldn't drive a car because you can't explain the carburator mix ratio on top of your head. Understanding means being able to copy a pattern and adapt it to a new situation. I never wrote a line of Ruby in my life, but I can take the quoted example and tweak it to do something else without ever worrying what mixins are supposed to mean within the Ruby landscape. Proof: arr = [1, 2, 3] sum = 0 arr.each { |elem| sum += elem } puts sum 6 http://codepad.org/x5roEPvS http://codepad.org/x5roEPvS Isn't it nice that I just invented reduce semantics out of something that ostensibly is only a map?
  - sp4rki 14y ago
    Understanding how to drive vs building a car is the same thing as understanding how to use a program vs building the program. Once again the point is that if you want to learn how to program in a specific language, you need to understand it's concepts and patterns. It's akin to the fact that if you want to learn how to build a car, you need to understand it's mechanics. You can easily take whatever you find in the internet and build a program. Or you could tweak an example to do something else without another care in the world. Guess what? You still don't understand what's happening or why, and because of that the end product will most probably be defective in some way. You still don't know what the point is, you only know that it works. That's OK if you need a quick solution for a small problem, but it's not when your goal in itself is to learn how to program (in Ruby)... Go ahead and read Zed's article again, only this time do so slowly and with care. Come back and realize two very important things you seem to be missing: A) This is Zed's opinion about TEACHING a programming language. TEACHING being the keyword. If you want to learn a programming language, you inherently need to understand it. As a small aside, he did write "Learn Python The Hard Way" which was pretty much a success, but don't believe me... he's probably a troll as you say. B) The discussion is basically that a form of writing a specific block of code is easier to explain than another, although the latter is more widely used and considered the correct. Readability, though important, has little to do with choosing the correct construct to teach as to provide a good balance of the time and effort you need to put into learning. You want to keep going with the analogies? You shouldn't drive a manual transmission car if you've only driven automatics, the same way you shouldn't deploy code to your clients that you've figured out will give you the results you want when you've never understood what the program is doing on the first place because you made assumptions when you started.
ebiester 14y ago
"Basic elementary concept, if you don't get this, you should not be coding yet." The target audience of his book has just learned what a variable and an array is. Since the book as advertized as learning "the hard way," it seems to explicitly attempt to give an insight to what the computer is doing when you tell it to do something. That is, I sure as hell could translate a for loop to psuedo-assembly, and I could probably teach a newbie how to do the same for their mental model. I don't even begin to think how I would teach them what the computer is doing conceptually. The target audience of his book is not coding yet. What, should we require a comprehension and vocabulary test before they test something out in a REPL? As such, I would say Zed's pedagogy is sound.
- pacala 14y ago
  You can teach <array>.each { |<elem>| <code> } exactly as you would teach for <elem> in <array> do <code> 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?
  - ebiester 14y ago
    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.
    - pacala 14y ago
      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.
    - qu4z-2 14y ago
      My issue here is that the for version is pretty much exactly "Just memorize this syntax and do it"

by pacala 14y ago

sp4rki 14y ago

For starters, you do realize that the author/troll of the article is Zed Shaw right? The fact that you can read a piece of code doesn't mean that you understand it. The whole point of teaching how to program is to actually get the student to learn what is actually going on, not just get them to a point where they can give a half assed explanation that really doesn't teach a thing. Repeating the line of code with extra words to convey meaning most certainly does not make it a valid explanation. And then you come along with a list of "responses" to the concepts outlined in the article, out of which you don't even actually understand half of, and completely destroy your initial argument because of it. You complain that Zed is a troll because you can actually read the code easily, when the whole topic of his is actually wether you can understand it. It's a completely different game. You basically just proved Zed right. The problem with teaching .each first according to Zed is that since you don't understand even half of what is going on, you just do things blindly because you've grown to predict the behavior you expect from a specific piece of code. For dessert I'm gonna "troll" a little bit. 1) If I should know variables, arrays, function calls, blocks passed to function calls (which includes an arbitrary comment about BASIC and goto statements), and scope, before I start coding then how the hell am I supposed to learn those very basic concepts? I mean according to you I shouldn't be coding right? 2) If you really don't grasp the concepts you say you don't understand in the list, you probably don't program for a living and/or have not had to actually teach any programming concepts besides the very basics. If this is the case, I'd argue that you still have a long way to go before actually having the experience to compare both "teaching orders" being compared here. 3) You give me the impression of a guy that has only done a bunch of jQuery and perhaps a Rails tutorial or two... AMIRITE? I'm sorry if this comes off like a lengthy angry diatribe (rest assured it's not my intention), but you tried to sound knowledgeable and ended up putting your own foot in your mouth. My mother once told me to only open my mouth if I know what I'm talking about. That my friend is my advice for you.

pacala 14y ago
> The fact that you can read a piece of code doesn't mean that you understand it. Therein lies the troll. Understanding is not figuring out how to derive the code from first principles. If that were true, you shouldn't drive a car because you can't explain the carburator mix ratio on top of your head. Understanding means being able to copy a pattern and adapt it to a new situation. I never wrote a line of Ruby in my life, but I can take the quoted example and tweak it to do something else without ever worrying what mixins are supposed to mean within the Ruby landscape. Proof: arr = [1, 2, 3] sum = 0 arr.each { |elem| sum += elem } puts sum 6 http://codepad.org/x5roEPvS http://codepad.org/x5roEPvS Isn't it nice that I just invented reduce semantics out of something that ostensibly is only a map?
- sp4rki 14y ago
  Understanding how to drive vs building a car is the same thing as understanding how to use a program vs building the program. Once again the point is that if you want to learn how to program in a specific language, you need to understand it's concepts and patterns. It's akin to the fact that if you want to learn how to build a car, you need to understand it's mechanics. You can easily take whatever you find in the internet and build a program. Or you could tweak an example to do something else without another care in the world. Guess what? You still don't understand what's happening or why, and because of that the end product will most probably be defective in some way. You still don't know what the point is, you only know that it works. That's OK if you need a quick solution for a small problem, but it's not when your goal in itself is to learn how to program (in Ruby)... Go ahead and read Zed's article again, only this time do so slowly and with care. Come back and realize two very important things you seem to be missing: A) This is Zed's opinion about TEACHING a programming language. TEACHING being the keyword. If you want to learn a programming language, you inherently need to understand it. As a small aside, he did write "Learn Python The Hard Way" which was pretty much a success, but don't believe me... he's probably a troll as you say. B) The discussion is basically that a form of writing a specific block of code is easier to explain than another, although the latter is more widely used and considered the correct. Readability, though important, has little to do with choosing the correct construct to teach as to provide a good balance of the time and effort you need to put into learning. You want to keep going with the analogies? You shouldn't drive a manual transmission car if you've only driven automatics, the same way you shouldn't deploy code to your clients that you've figured out will give you the results you want when you've never understood what the program is doing on the first place because you made assumptions when you started.

ebiester 14y ago

"Basic elementary concept, if you don't get this, you should not be coding yet." The target audience of his book has just learned what a variable and an array is. Since the book as advertized as learning "the hard way," it seems to explicitly attempt to give an insight to what the computer is doing when you tell it to do something. That is, I sure as hell could translate a for loop to psuedo-assembly, and I could probably teach a newbie how to do the same for their mental model. I don't even begin to think how I would teach them what the computer is doing conceptually. The target audience of his book is not coding yet. What, should we require a comprehension and vocabulary test before they test something out in a REPL? As such, I would say Zed's pedagogy is sound.

pacala 14y ago
You can teach <array>.each { |<elem>| <code> } exactly as you would teach for <elem> in <array> do <code> 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?
- ebiester 14y ago
  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.
  - pacala 14y ago
    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.
  - qu4z-2 14y ago
    My issue here is that the for version is pretty much exactly "Just memorize this syntax and do it"