Tuesday, November 1, 2011

Exercise 2: Comments And Pound Characters: Learn Ruby The Hard Way

So the last exercise had us typing in characters to help us understand what lines would be printed to the screen and which ones wouldn't. The character used is the 'octothorpe', aka 'pound', 'hash', 'number key', hey, whatever works for you. The important thing is that wherever it appears, any character that follows on after it doesn't get run in the program. It's used for commenting your code and for disabling lines in your code.

So here's the exeercises as dispayed in the book and what I see when I run them.

1 # A comment, this is so you can read your program later.
2 # Anything after the # is ignored by Ruby.
4 puts "I could have code like this." # and the comment after is ignored
6 # You can also use a comment to "disable" or comment out a piece of code:
7 # print "This won't run."
9 puts "This will run."

[And here it is]

What You Should See

$ ruby ex2.rb

I could have code like this.

This will run.


[so far so good]

Extra Credit

- Find out if you were right about what the # character does and make sure you know what it's called (octothorpe or pound character).

[Well, yeah, the pound character, when it is by itself and with a space next to it, acts as a "comment" character. Here's the thing, it doesn't always do that. there are examples where when combined with other characters it means something else, but that's jumping ahead in the exercises]

- Take your ex2.rb file and review each line going backwards. Start at the last line, and check each word in reverse against what you should have typed.

[done, looks clean under the circumstances]

- Did you find more mistakes? Fix them.

[this time, no, I think we are clean]

- Read what you typed above out loud, including saying each character by its name. Did you find more mistakes? Fix them.

[I had some spacing issues and cleaned them up, but otherwise, looks clean from what I can see]


OK, seriously, did Zed really make me just do that? Does he think I'm really that stupid? Well, no... and yes. You see, in reality, we are that stupid, if we are inexperienced or we are not really good typists. We think we have typed our information well. We think we have done everything right, until we actually run the program and it gives us output that we don't expect, or we get an error. By reading the code backwards, we can see if, indeed, we did write what we believe we wrote. Remember, the human brain can make sense out of a lot of static, and it's very helpful when it comes to filling in the blanks and letting us see what we think we mean.

I see this all the time with my own blog posts. I proofread them, sometimes two or three times, only to have another reader spot a glaringly obvious error that I overlooked. Why? Because my brain knows what I mean, and it is more than happy to fill in the blanks. Computers can't do that; they have to be told explicitly what to do, and even elegant layers of abstraction, of which Ruby is, cannot overcome that. If you tell the computer to do something, it will do it, whether you meant to tell it that or not. It doesn't understand intent. So yeah, Zed wants you to proofread even these simple starter programs. You may be surprised how many flaky things you do and do not realize at all that you are doing them.


gMasnica said...

Going through all of this is awesome. Thanks for going through all the effort to parse the book's words into bite size chunks. The added element of simpler explanations helps a ton too :)

I think one of the most important things for someone learning to program is stated in the last paragraph of the post. As much as what computers do is seen as "magic", computers are ultimately really stupid and have to be told VERY explicitly what you want them to do. Chris Pine, in his "Learn to Program (with Ruby)" book, gave one of my favorite examples of this that has the reader walk through building a peanut butter and jelly sandwich.

Great posts Michael!

Michael Larsen said...

Thanks, ~G :).

I think that we to often just passively read many of these books, even if we do go through the exercises. Most of the time, we copy and paste the examples in, run them, and we say to ourselves "OK, I've got it." and then unless we are really diligent about doing it day after day, it ends up being like Geometry proofs, something we know for a little while to pass a test, and then we forget about them. My goal with outlining the entire book and walking through everything is to see for myself how effective the method is, and to show others that the method, if applied, can yield the results promised. In a way, I am publicly testing Zed's hypothesis :).

Thanks for following along, I hope my approach is helpful to others as well as myself.