From: James Britt <james.britt@...>
Date: 2006-06-12T12:37:14+09:00
Subject: Re: Ruby for Highschoolers?

Matthew Smillie wrote:


> ...
> 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.
> 

I appreciate the detailed post.  I've only done a limited amount of
teaching, so much of what I believe may be ill-founded; it's certainly
difficult for me to present it as little more than gut feeling and the
results of personal experience.  (And my questions are not directed to 
you, but are the things that I was asking myself.)

If writing arr.sort would have satisfied the requirements of the
exercise, then a student may not quite understand why it is not the 
right answer.  If the requirements are to demonstrate a knowledge of 
algorithm design and analysis, then (purely speculative voice speaking 
here, mind you) the exercise should be designed to enforce that, or at 
least make clear why simply using a built-in function is an insufficient 
solution.

And it may be that for teaching fundamental computer science concepts
that Ruby is a poor choice, precisely because it abstracts away so many
details.  Or that exercises must be more carefully designed so that the 
features of the language do not force students into solutions they would 
never bother with in real life, nor allow  for sloppy design.  (I'm 
wondering if students should have to maintain and debug each others 
code.  They'd get fed up fast.)


> 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.

Why would they?  I don't mean to sound trollish, but, all things being
equal, if they can write code that runs and produces the correct answer,
where is the failing?  How do things get to that point? Are students
allowed to keep coding like that?   What would motivate them to do
things differently?

I have a CS degree, and can safely say that while I learned all sorts of
CompSci things, I didn't really learn to program well until I coded
large projects, after graduation.  Class assignments rarely had enough
of the real-world nastiness that make clear why certain design and
development practices are to be preferred.  For the most part,
lessons were more focused on language syntax or dealing with the linker.
So, while teachers may have commented on poor procedure or function
design, it was not a key point.

It is very hard to come up with really good tutorial examples.
Gratuitous class definitions are likely to give the impression that OO
is all about more lines of code.

Without some clear understanding of what OOP is for, and when to
use it (or not), I think it pretty reasonable that people use globals 
and write long streams of procedural code.  The code runs, and they'll 
never have to maintain it.  It passes the unit tests, so to speak.

It may be difficult for some people to "get" OO, but that may be because
they are asked to apply it without a compelling reason.

(Perhaps exercises should always have multiple stages, with each next 
phase introducing some new requirement that is sure to make life hard 
for students who haven't applied some basic OO design. )

>  ... 
> 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.
> 

Absolutely.  Do the students know this?  (I'm being rhetorical).
Because I can imagine telling a group of students to all go to the top
of the Sears Tower in Chicago, and then complaining that they took the
elevator, not the stairs.



... (much good stuff chopped out)


> 
> 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.
> 

It seems that, in what you've described, there are multiple problems at 
play: Teaching basic programming concepts; teaching the syntax and 
semantics of a particular language; undoing the harm of students who 
have already acquired poor techniques and misconceptions from previous 
classes or personal hacking.

If this is what the OP has to face, I'd argue for Scheme if for no other 
reason that students will not have the false impression that it is "just 
like" what they think they know about Java|PHP|Perl.



-- 
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine