131–140 of 179 posts
Earlier quoted context omitted.
If your goal is to create programmers, then you should be creating programmers, not good little rubyists/pythonistas/etc
I don't see how learning how to use a language according to its conventions makes one not a programmer.
Earlier quoted context omitted.
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 extr…
> 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…
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.
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…
That's what I personally love about method chaining anyhow.. Functional composition with a structure that's not completely ad hoc is kinda nice.
I think your comparison between for loops and .each is flawed - clearly you don't need to explain all those concepts in detail if at all. A for loop ultimately involves some level of polymorphism on the target collection, at least to the same level as required by the call to .each. I'd say that conceptually they are very similar, with both constructs having specific differentiating features.
Also, .each doesn't eventually become a for-loop in C code. 1/ Neither Ruby nor Python are compiled to C code, and 2/ I wouldn't expect that the respective looping constructs become a typical C for loop, it is more likely they will be implemented in the native op-code (e.g. CPython, Ruby 1.9).
With respect to why .each is fundamental to Ruby, we clearly see some key differences between Python and Ruby in this respect. I think the critical thing is that Ruby tends towards being a functional language while Python tends to be more imperative. We can see this clearly in the types of operations provided by Python, for example, list.reverse() in Ruby returns a copy of the list in reverse order, but in Python it reverses the list in place.
Using .each in Ruby code leads to shorter more concise code in contrast to the corresponding Python code. Whether you feel that you are being judged or not (in a social sense) is probably a matter of who you choose to interact with on that level (e.g. a particular developer community). Have you ever had to use non-idomatic C code? How about non-idomatic Python code? Clearly, a big issue with source code is composition (on a project level) and non-idiomatic code causes many issues in this area.
It is also interesting to note that non-idomatic behaviour plays a role in larger society. For example, choose the GPL and you might receive some complaints from communities that typically use MIT or BSD license. How about real life? If your friend buys you a drink and you don't play the social "ball game" (e.g. behave non-idomatically) you might have social problems in that area too.
I think that ultimately you are confusing a social interaction with a programming language best practice. I don't think either of these things are bad - heck, look at all the company specific coding standards for C or C++ code - but ultimately whether you choose to indoctrinate your students into a particular social circle, or teach them the best practice for a given programming language is simply a matter of perspective; and empowering your students to understand why things are the way they are, rather than simply saying this is the way we've always done things, is ultimately something I think is very important.
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 programmer…
Earlier quoted context omitted.
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 programmer…
How is .each any simpler than a for loop, conceptually they do the same thing.
Earlier quoted context omitted.
He never argued that .each is a horrible looping construct. He calls it a horrible _first_ looping construct, that is to say that its bad for teaching to beginners. Your last paragraph says nothing that contradicts the article in any way. In fact, you beautifully summarized that portion of the article: > Well, sure, if you're teaching someone programming for the first time it's probably better to start with "for". Th…
I just spent the last two weeks learning the Ruby language (but I come from other programming languages). I'd argue that learning .each vs. normal looping has numerous benefits. First, this is the way most people loop most things in Ruby. More importantly, however, teaching .each enabled me to be more openminded towards learning "yield" and blocks. In a way, without having learned about .each first, and coming into R…
Starting to teach languages avoiding what makes the language so special is counter productive. As soon as your students know a basic way to program, they won't be inclined to learn the "good way".
Earlier quoted context omitted.
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.
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?