Teaching Ruby

[wtd]

One more time!

So, since I started this topic before the roll-back, it's occurred to me that there are effectively two major approaches.

You can either take a step-by-step approach of introducing various capabilities of Ruby, or you can just throw some code out and pick it apart.

Though I'm a fan of the former, I'm beginning to think the former holds promise, since it has the potential to really grab attention, and to simultaneously address the question: "ok, that's great... can I do anything useful with it?"

[Tony]

I'm in favour of step-by-step approach.

Here's a line, here's what you can do with it. Now try something else with what you've learned last week's line.

I think that midway you can then do something like

you - "lets learn Objects"
students - "oh noes! it's too difficult"
you - "you've been using Objects since day one.. here's how"

Bottom line -- control your urges to dive right into the technicalities, let students have their fun. Everything will be taught in due time.

[Cervantes]

Step-by-step approach.

I've no idea if you read what I posted or not, wtd, but it sounds like you did. I'll repost the order of things that I had suggested, in any case:

puts
variables
gets
if structures
(could throw cases in here)
methods (made by the programmer, not pre-made methods of various classes)
(could throw arrays and hashes in here)

Now you are free to teach Object-Orientation, and you need not have used it at all until this point.
[edit] Well, you have used object orientation, as in calling the == method from the, for example, String class. But you don't introduce the == method that way, and it will be easier for the students.[/edit]

wtd wrote:

You can either take a step-by-step approach of introducing various capabilities of Ruby, or you can just throw some code out and pick it apart.

Though I'm a fan of the former, I'm beginning to think the former holds promise, since it has the potential to really grab attention, and to simultaneously address the question: "ok, that's great... can I do anything useful with it?"

I'm guessing that's supposed to say that you're a fan of the former, but beginning to see merit in the latter. Or is it the other way around?

[[Gandalf]]

Both points have their advantages. The problem I see with letting the students have fun before technicalities is that they might later see no use in learning those specifics (objects, etc.) If you go into the hard stuff early on though, they might get discouraged, and they might think that there is no real use to all that. The one reason why Turing was pretty good in that aspect is that it allows you to do the visual, encouraging stuff fairly early on. A learning language should be able to encourage you to program and see the results, showing you how many possibilities there are.

[wtd]

Cervantes wrote:

wtd wrote:

You can either take a step-by-step approach of introducing various capabilities of Ruby, or you can just throw some code out and pick it apart.

Though I'm a fan of the former, I'm beginning to think the former holds promise, since it has the potential to really grab attention, and to simultaneously address the question: "ok, that's great... can I do anything useful with it?"

I'm guessing that's supposed to say that you're a fan of the former, but beginning to see merit in the latter. Or is it the other way around?

Indeed.

I fear going through and doing things the step-by-step way simply be boring. In talking to compsci.ca members privately about other languages, I've noticed that sometimes I can get interest by throwing out some code, getting a "WTF?!" response, then picking it apart so that they can see how, yes, it really does make sense.

Here's a sample. There was a script posted before the rollback which I revised:

code:

require 'rexml/document' document = REXML::Document.new <<END_BASIC_DOCUMENT <?xml version="1.0" encoding="UTF-8"?> <urlset   xmlns="http://www.google.com/schemas/sitemap/0.84"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="http://www.google.com/schemas/sitemap/0.84                       http://www.google.com/schemas/sitemap/0.84/sitemap.xsd"> </urlset> END_BASIC_DOCUMENT puts "What is the site root URL? (http://www.example.com/)" root_url = gets.chomp Dir.new(Dir.pwd).reject { |filename| filename == '.' or filename == '..' }.each do |filename|    lastmod = File.mtime(filename).strftime("%Y-%m-%d")    puts "File:  #{filename}"    puts "Would you like to include this page in the sitemap? (y, n)"    answer = gets.chomp    if answer == "y" or answer =~ /^ \s* $/x       puts "How often is this page changed?"       changefreq = gets.chomp       changefreq = "monthly" if changefreq =~ /^ \s* $/x       puts "How important is this page? (0.1 - 1.0)"       priority = gets.chomp       priority = "0.5" if priority =~ /^ \s* $/x       url_tag = document.root.add_element "url"       loc_tag = url_tag.add_element "loc"       loc_tag.text = "#{root_url}#{filename}"       lastmod_tag = url_tag.add_element "lastmod"       lastmod_tag.text = lastmod             changefreq_tag = url_tag.add_element "changefreq"       changefreq_tag.text = changefreq       priority_tag = url_tag.add_element "priority"       priority_tag.text = priority    end    end File.open("sitemap.xml", "w") do |output_file|    document.write output_file, 1 end

[Cervantes]

wtd wrote:

I fear going through and doing things the step-by-step way simply be boring.

It could be boring to those who understand programming already. Perhaps it would be slightly boring to those who have a natural grasp of programming, even if they have not programmed before (the highly logical type). But to the vast majority of beginner programmers, I believe the pace would not be too slow.

wtd wrote:

In talking to compsci.ca members privately about other languages, I've noticed that sometimes I can get interest by throwing out some code, getting a "WTF?!" response, then picking it apart so that they can see how, yes, it really does make sense.

Indeed, but these are compsci.ca members. There is a big difference between the active compsci.ca members and beginner programmers.

Things would be different if the students had some other programming experience, however...

[Tony]

teaching a programming class is quite challanging as there will always be those few slow kids who just dont get it.. and a few that are bored because you're holding back for the masses..

[[Gandalf]]

Isn't that the case in any class? That's why they should have seperate classes for the 'slow' kids and the faster ones, or else just have a low level somewhere at the beginning which allows the slow ones to learn the basics and find out if they want to continue in that direction.

[wtd]

It's a very complicated subject, to put it mildly, with many schools of thought.

The only thing I can think of to address the issue is to encourage students to dabble outside of class, and to try to identify the students who are really taking initiative and cut them a bit looser than the rest. Though you could perhaps bring those students back into the fold by saying, "ok, you're so far ahead.... why don't you share some of what you've learned with everyone else?"

[codemage]

The standard order things have usually been taught around here (the SW Ontario school of thought AFAIK) is:

puts (& formatting)
variables
gets
selection (if / case)
loops + iteration
arrays / hashes
methods / routines
recursion
OOP

When teaching non-programmers, it's best to work your way up. I'd leave objects until after the basics - there's a good chance that'll really throw off the 1st timers.

If the class grasps the material quickly, you can go through the initial stuff quickly. I find that the advanced students work ahead without the need for additional motivation - but for some assignments I'll include bonus/challenge sections to keep them working at their potential.

I'm not overly familiar with Ruby yet (one of my reasons for joining the board), but from the little I've done, I think the paradigm still fits.

[Cervantes]

The problem is that there's very little one can do in Ruby without seeing Object Orientation at work. Learning about arrays and hashes is almost useless if you don't take advantage of any of the associated methods.

I would tend to teach OOP before getting into arrays and hashes and recursion. Get to OOP as soon as you can, so you can begin learning about the various class/instance methods, and blocks.

Until OOP is taught, students are mostly hanging on by a thread, using a fraction of Ruby's power. That power needs to be unleashed at just the right time: when the students know enough to appreciate it, but not so late that students get bored before experiencing this power.

[Tony]

though that's exactly the question.

when should that power be introduced.

[Cervantes]

After user-defined methods have been taught.

[codemage]

If you're teaching at the University level, then you should be more concerned with the theory of arrays, recursion, etc that their actual implementation in a particular language.

It's quite typical to teach things in a way that make earlier teachings obsolete in practice. (Math teachers do this all the time in high school). It's the theory that sticks.

That $0.02 said, I'm a complete newb at Ruby - so you'd be able to judge a lot better where the best tradeoff is. (You don't want to waste too much time on theory).

[rizzix]

how in the world did you manage to get the title of "supreme newbcake of compsci"