I'm a highschool student with a very high chance of ending up
student-teaching the Programming I course during the 07-08 schoolyear.

This year was the first year for the course, and Scheme was used.
However, I've been talking to the teacher about Ruby, suggesting that
she should try it for one of the programming courses next year.
(Unfortunately, there's no ready-made curriculum for Ruby available to
her, and she is not really a techie, so that idea was shot down.)

If I end up teaching it, I think it would be cool to cover Ruby instead
of Scheme. I'd have to develop my own curriculum, but whatever.

The goal of the course is to teach programming concepts in half of a
school year. The things that were covered during this year's course were
writing functions to do a simple calculation, using variables, and using
cond/booleans. Many students struggled during the beginning of the year
with writing basic functions. Our teacher kind of blamed herself for
that, because this was her first year teaching programming, and she had
never been trained on Scheme.

I think that teaching students Ruby might be a bit less...arcane. It
looks friendlier, for one. It would also open the course up to more
concepts than Scheme offers, like automagic testing, manipulating files,
object orientation, etc. Teaching OO during this course would probably
also benefit the kids later on for Java during Programming II...

So, given all of that, I have two questions for ya, list. One, do you
think there's any merit from teaching pretty non-technical sophomores in
highschool Ruby over Scheme? And two - Is there a DrScheme-eqsue
environment available for Ruby (screencap:
http://www.plt-scheme.org/software/drscheme/tour/images/editor-repl.g...

The DrScheme-esque thing is a big deal. The computer labs are *all*
Windows labs, and nothing will change this. The program serves as a sort
of incredibly simple IDE. In the top pane, you can put in your code, and
the bottom pane displays results and lets you use an irb-for-scheme type
thinggy.

I appreciate any comments you can give me, list.

Of course, teaching this is not that easy.  Did you ever read SICP?
Have a look into it and rethink your choice.

(Despite all of this, I prefer Ruby for *coding*, of course.  But
Scheme is the better choice for teaching.  YMMV.)

The IDE could be a problem, but if anything, it could probably be coded in Ruby using one of the toolkits in a couple days/weeks (using Fox, Tk, etc.).

This is not a bad idea IMO. Start with simple things, of course.
Introduce OO fairly early.

Are these people who have programmed before at all? Or not?

Look up whatever Ruby tutorials you can. I don't have links
handy, but there are some good ones out there.

Good luck...

I also like Ruby better than Scheme.

def do_something(n)
   if n < 10
     true
   else
     false
   end
end

As opposed to:

(define (do_something n)
  (cond
   [(< n 10) true]
   [else false]
  )
)

(Sorry for parse errors, if there are any.)

DrScheme worked out really well. I guess what I'm after is a nice
frontend to irb, and if I have to, I'll write it myself (and release it
to the world, of course!).

method arg1, arg2, arg3
method(arg1, arg2, arg3)

var = if true then '1' else '0'
        # or the case equivalent...

etc...

I personally love it, but when you are a complete beginner this sort of
thing just makes your head hurt and I haven't even hit the ones that make
my head hurt...

Might be just be, but when I've tried to teach people languages they all
seem to want a very rigid syntax.... for example, they liked for(;;) but
didn't want to deal with do/while because they had their "one true looping
construct".

Not saying scheme is any better in this regard though, but something to
think about...

There is nothing spooky about the command line, even in Windows.

Don't treat people like children, or they'll start acting like children.

Assume the best, and let them show you otherwise.

--
James Britt

A command line is simple and intuitive in a different way from how a
GUI is simple and intuitive. It still has its place, and will for years
to come. Although I won't be sad if we come up with something better.

Still, if you've never used the command line, you can learn
most of what you need in half an afternoon.

On Jun 11, 2006, at 12:55 PM, Nicholas Evans wrote:

The reason for this is that there are many, many different ways to  
accomplish things in Ruby, and this can actually be detrimental to  
the students' fully understanding the basic concepts involved.  They  
tend to get hung up in trying to sort out the minor differences  
between, say,  all the different ways of doing a conditional.  When  
this happens, I've noticed students tend to drift towards "string  
substitution" - basically just fiddling with the order of what  
they've written, hoping to hit the right combination by chance; they  
get the assignment done, but they've learned essentially nothing.

Basically, there are many ways to accomplish a given task, which  
makes it comparatively easy to write a program that - while it  
produces the desired output - completely misses the point of the  
learning exercise.

Another difficulty is that while the syntax might *look* straight-
forward, but in part that's because a lot of Ruby relies on  
programmers having an understanding of how programming works in  
general, and a lot of the generic terms can be elided or condensed.  
When you're learning programming, you need to know about those  
implicit bits, and having to write them out explicitly helps with that.

To give a concrete example, think of the 'return' statement - it's  
*required* in Java for the method to return anything, and is optional  
(but generally not used) in Ruby.  For someone learning Ruby, this  
means they have to remember that the last statement evaluated is the  
return value, which is just one more thing to put on their stack of  
not-quite-understood concepts (and they have LOTS of those concepts  
when they're learning).

I'm skeptical that Tim Toady is the culprit here.  If you, as the
teacher, don't want students diddling arounf with every syntax for a
conditional, then tell them the one form they are allowed to use for the
exercise and leave it at that.

The "must remember to type a gratuitous 'return'" seems like the extra work.

Students will learn the Ruby you teach them.  Don't throw a lot of
syntax at them before explaining basic principles.    Otherwise the
syntax just seems arbitrary (or more arbitrary than it is), and the
principles will not make much sense after they've been blindly coding
with random expressions in search of code that simply runs without errors.

It may be useful to watch the SICP videos from MIT (and they may be the
best argument for teaching Scheme over Ruby :) )

http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/

--
James Britt

It's far easier to go from strict(statically) to free(dynamic).

I come with 20 years of C/C++ experience.

It took me no time to understand that variables don't have types,
classes can be changed midway through the script, Arrays can hold
anything.

If you start with this knowledge and try to go to C++, you will commit
suicide.

I think Ruby would be an excellent choice for a first programming
language.  You don't need to know a lot of concepts to get started
programming in it, but it's also a very rich language.  I'm tempted to
say that Ruby will grow with you, meaning not that Ruby will gather
more and more syntax with age, but that as you become a better
programmer, you'll discover other areas or ideas in that language that
you have yet to explore.

However, as you know Ruby but not Scheme, I'd recommend that you
advantage of the opportunity to learn Scheme.  You'll probably find
that it will make you a better programmer in Ruby, as well.

Jeff

On 6/11/06, Nicholas Evans <OwlMan...@owlmanatt.com> wrote:

--
James Britt

Machine code or bust.

--
James Britt

This is the same in most forms of introductory-level teaching; the  
precise nature of your opinions about feminist imagery in Margaret  
Atwood's work aren't the point of writing a paper for English 101.  
The point of writing that paper is to learn the process of writing  
any English paper: develop and describe a particular thesis.

As a trivial (and somewhat absurd) example, let's say the exercise is  
to write an array-sorting routine.  In teaching terms, this has the  
practical value of getting them familiar with arrays and fundamental  
operations (setting, accessing, comparing), and demonstrates  
theoretical points about efficiency (bubble sort, anyone?),  
algorithms, and depending on exactly what the algorithm is, recursion  
or notions of combining small local operations to effect a global  
result.  On the other hand, a student could write "arr.sort" and have  
accomplished the same task having learned nothing more than how the  
docs are organised.

There are two less-trivial examples that I've seen a few times that  
are worth mentioning in this context.

Some of the students in the course I taught had only ever programmed  
in Prolog before - and a couple of them were extremely proficient at  
it.  They tended (in Java) to end up finding ways to make everything  
effectively global.  They accomplished the task, more or less, but  
did they learn anything valuable about encapsulation or OO design?  
Not really.

Similarly, a few students have come in having done some shell  
scripting or website PHP or Perl hacking, and the fundamental mistake  
they made was to do everything statically (in Java, so as class  
methods).  So, they had classes, which were pretty decent, but missed  
out objects and had to do some really odd fiddling to manage state at  
the class level.  Again accomplishing the task, but missing out on  
some pretty fundamental aspects of object orientation.

So no, the point of a programming exercise is not simply for a  
student to produce the desired output, but rather to teach students  
something more fundamental about programming in a practical way.  
Philosophically, it's not just where you end up, it's how you get there.

In any case, conditionals are just one example, and the larger  
problem boils down to the fact that the students must learn, and  
learn on their own (in the sense that they might work together, but  
noone can copy understanding of their lab partners).  Specifying the  
style or allowed syntax for an assignment specifically enough that  
noone gets side-tracked is a fruitless task: you end up just giving  
them pseudo-code and a set of formatting guidelines.

That's pretty obviously undesirable, for one thing, you want students  
to get side-tracked every so often.  What you don't want them to do  
is get so caught up in the subtleties of the *syntax* that they miss  
the larger point of the assignment - not seeing the forest for the  
trees.

Think of it as similar to why we advise people not to optimise  
prematurely, because premature optimisation amounts to almost the  
same thing: a programmer becoming too focused on the specific  
implementation of one small piece of code, ignoring the larger task.  
For experienced people, this might be "how can I cache my search  
results?", but for beginning programmers, this very often is "what's  
the smallest number of lines I can use to write this conditional" or  
"that ternary operator looks clever, how can I use it to do this?".

I will admit, though, that it is a tricky argument, because the best  
students are the ones who experiment on their own and are smart  
enough to read their textbook or look up online docs, and  
discouraging them from this does them an enormous disservice.  But  
equally, you want to make sure that you're not setting traps for  
them; it's just as much a disservice if they spend all their time  
working on a one-line #inject implementation of a method, and don't  
learn how inheritance works.

Again, a practical example: the 'expressions return values' thing is  
pretty simple at first glance, a = 3 + 2 seems pretty easy to  
understand.  For some reason, though, the majority seem to consider  
variable assignment as some sort of a special case.  Of course, it's  
what lets you do things like "a = b = c = 1" and "if (a = a + 5)".  
The latter example never fails to draw slightly confused looks from  
people the first time they see it.

So, it *is* extra work, but it's valuable extra work because it helps  
students internalise that particular concept.  It makes it absolutely  
explicit to the student that methods return values.  If they're  
reading code, it gives them an anchor for their analysis and  
understanding.

Again, though, 'return' is just an example of a more general idea:  
Ruby syntax is concise, which is great for when I'm using it.  But  
that same property can make it a headache (literally) for beginners -  
there's just more that they have to actively think about and remember  
in order to grasp what's going on.

So, while "don't throw a lot of syntax at them before explaining  
basic principles" is correct advice, it's not very useful advice,  
since all it does is rephrase the problem.  In fact, it's about the  
biggest problem in teaching programming, and it has no correct  
answer; some students will do better if you just give them a link to  
the language docs and turn them loose, some do better with formal  
definitions of the syntax, some need a simple, plain-english  
explanation, and some always need some hand-holding.

A more subtle point is that the instructor isn't teaching you Ruby, s/
he's teaching you how to program.  Ruby does have a lot going for it  
in this regard: first-order functions, object-orientation, and so  
on.  But my point is that Ruby's concise nature is an argument  
against using it to teach general principles, because the syntax  
takes many of those general principles as already understood, and  
tucks them out of the way.

Now, unlike Hal Fulton, when *I* was in high school, high schools didn't
have computers. For that matter, major universities didn't have computer
science programs and minor universities, if they had a computer at all,
it was a punched card thingie used to do accounting. :) Of the 300 or so
people in my senior class, perhaps 10, among them of course myself,
ended up learning how to program. I think I'm the only one still doing
it, mostly because I love it too much to retire.

In any event, that was a long time ago. For teaching programming to
today's high school students, I think there are really four choices for
Programming I, given that Programming II is in Java.

1. Stay with Scheme. It's a "known quantity", it's a perfect vehicle for
learning about recursion, lists, selectors, constructors and predicates,
functional programming styles, etc. If they're going to be computer
scientists, this would be my choice.

2. Start with Java. Hey, why not? They'll be learning Java anyhow in
Programming II, and there are world-class free IDEs for it. Why make
them switch languages in mid-stream?

3. Hold on now ... I am serious. How about C? Darn near everything under
the hood in today's computers -- the Ruby interpreters, Java (and
Scheme) virtual machines, the Linux kernel, the GCC compilers -- is
written in C. It's close to the metal.

Actually those are the only choices I would have picked, since I don't
know Ruby very well yet. But hey, this is a Ruby list, so I'll say

4. Ruby. I don't think the IDEs are a problem, it is a good introduction
to programming and unlike Java and C, there's no "compiler" to wait for.
In fact, if Programming II was not in Java, Ruby would have been number
2 and there would have only been three items in the list. :)