Forum: Ruby Ruby for Highschoolers?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
38c94343d160b921ee22e9f0fb4c18b4?d=identicon&s=25 Nicholas Evans (Guest)
on 2006-06-11 18:58
(Received via mailing list)
Howdy list,

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/i...)?

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.

Regards,
Nick Evans
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-11 19:29
(Received via mailing list)
Nicholas Evans <OwlManAtt@OwlManAtt.com> writes:

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

I know this sounds heretic and probably is not what you expect from
this list, *but why*?

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

Do you think an untrained teacher better teaches Ruby instead of Scheme?

> I think that teaching students Ruby might be a bit less...arcane. It
> looks friendlier, for one.

That's a matter of taste; people that never saw code didn't yet
develop a taste for it.

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

I'd say, due to the small core of Scheme, it's even easier to explain
these topics.  You have everything: write a few macros for
unit-testing, files can be done with ports (they are in the spec),
object orientation can be done with closures.  Once they did all this,
they know what they are talking about.

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.)
E6e7044134d12b3f4194e8a387259c1a?d=identicon&s=25 Steven Davidovitz (Guest)
on 2006-06-11 19:32
(Received via mailing list)
On Mon, 12 Jun 2006 01:55:39 +0900
Nicholas Evans <OwlManAtt@OwlManAtt.com> wrote:

>
>
> http://www.plt-scheme.org/software/drscheme/tour/i...)?
> Nick Evans
>
>

I think non-technical High Schoolers would definitely benefit from
learning Ruby before moving on to other statically-typed languages. I am
a junior next year and we only have one Computer Science course that
teaches Java. I have a couple friends who took it this year and some of
the code they have written this year could have benefited from prior
knowledge of any basic programming. I taught myself Ruby using the
Pickaxe book among others and I would have to say it is just absolutely
fun to program in Ruby.

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

-Steven Davidovitz
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-06-11 19:38
(Received via mailing list)
Nicholas Evans wrote:
> Howdy list,
>
> I'm a highschool student with a very high chance of ending up
> student-teaching the Programming I course during the 07-08 schoolyear.

Boy, do I envy you guys. When I was in high school, I learned
BASIC and Fortran.

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


Hal
38c94343d160b921ee22e9f0fb4c18b4?d=identicon&s=25 Nicholas Evans (Guest)
on 2006-06-11 19:57
(Received via mailing list)
Christian Neukirchen wrote:
> Nicholas Evans <OwlManAtt@OwlManAtt.com> writes:
>
>
>>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.
>
>
> I know this sounds heretic and probably is not what you expect from
> this list, *but why*?
I figured I'd be killing a few birds with one stone. I think Ruby is
simple enough to teach basic programming concepts with (although my
opinion on the matter probably isn't worth much, because I don't know
Scheme, really). It's also practical and a hellava lot closer to Java
than Scheme is. And we are kids are compelled to take the Java course
senior year if we take the Scheme one sophomore year.

I also like Ruby better than Scheme.

>>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.
>
>
> Do you think an untrained teacher better teaches Ruby instead of Scheme?
I think I've underexplained the situation. If I end up as the teacher's
assistant and I can sell Ruby, I'm going to be the one teaching it to
the class AND the teacher.

>>I think that teaching students Ruby might be a bit less...arcane. It
>>looks friendlier, for one.
>
>
> That's a matter of taste; people that never saw code didn't yet
> develop a taste for it.
That said, I saw people getting incredibly confused by the idea of
matching the curly braces up. Ruby looks a lot more natural, so I think
it would be easier for people to relate something like this:

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

> they know what they are talking about.
I was unaware that Scheme had OO. I don't really *know* Scheme, so I
guess I'm not being terribly fair.

> Of course, teaching this is not that easy.  Did you ever read SICP?
> Have a look into it and rethink your choice.
I haven't even heard of that. I'll look into it. =)

> (Despite all of this, I prefer Ruby for *coding*, of course.  But
> Scheme is the better choice for teaching.  YMMV.)
Thank you for the feedback!
3afd3e5e05dc9310c89aa5762cc8dd1d?d=identicon&s=25 Timothy Hunter (Guest)
on 2006-06-11 19:57
(Received via mailing list)
Steven Davidovitz wrote:
> I think non-technical High Schoolers would definitely benefit from learning Ruby before 
moving on to other statically-typed languages. I am a junior next year and we only have 
one Computer Science course that teaches Java. I have a couple friends who took it this 
year and some of the code they have written this year could have benefited from prior 
knowledge of any basic programming. I taught myself Ruby using the Pickaxe book among 
others and I would have to say it is just absolutely fun to program in Ruby.
>
> 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.).
>

I know this will be controversial, but...IDE? Why do you need an IDE?
They're learning programming, not clicking on things. They can write
their Ruby programs using whatever text editor is convenient, vim,
emacs, Scite, whatever.

"IDE? We don't need no stinkin' IDE!"
38c94343d160b921ee22e9f0fb4c18b4?d=identicon&s=25 Nicholas Evans (Guest)
on 2006-06-11 20:00
(Received via mailing list)
Hal Fulton wrote:
>
> This is not a bad idea IMO. Start with simple things, of course.
> Introduce OO fairly early.
I'd find it difficult to not talk about it from the very start.

> Are these people who have programmed before at all? Or not?
For the most part, no. The assumption that the course makes is that the
students are complete beginners.

> Look up whatever Ruby tutorials you can. I don't have links
> handy, but there are some good ones out there.
Aye. Another benefit is having the first edition of the pickaxe
available online. We used How To Design Programs a lot during the class.

> Good luck...
Thank you!
38c94343d160b921ee22e9f0fb4c18b4?d=identicon&s=25 Nicholas Evans (Guest)
on 2006-06-11 20:04
(Received via mailing list)
I'm not after a full-blown IDE. They'd be working under Windows, and I'm
(perhaps wrongly) reluctant to open up the command prompt. I want to
focus on programming, and not have to bother with Windows shell commands
too.

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!).
666d5f3cb1de79a29e8c2f3bce6c2435?d=identicon&s=25 Kenneth Johnsen (Guest)
on 2006-06-11 20:39
(Received via mailing list)
Hi Nick,

I recently landed a job teaching math and IT at a school here. I have
just
finished my first 6 months, where we have mostly been focusing on HTML
and
relational databases.

However, there's still programming and OO left in the curriculum (as
well as
ERP and other things).

I initially had the idea that I would teach PHP, because it ties in
nicely
with what my students know about html and the web, and I could do the OO
part with PHP, too.

But I think that Ruby would be better as a teaching language.

I'd be very interested in seeing what you come up with, if you decide to
teach Ruby. Maybe we can bounce some ideas off of eachother.

Regards,

Kenneth.


2006/6/11, Nicholas Evans <OwlManAtt@owlmanatt.com>:
> her, and she is not really a techie, so that idea was shot down.)
> never been trained on Scheme.
> environment available for Ruby (screencap:
> Regards,
> Nick Evans
>
>


--
Med venlig hilsen / Best regards

Kenneth Johnsen
48124635945b45221ba12a26371f9e3e?d=identicon&s=25 Philip Hallstrom (Guest)
on 2006-06-11 20:53
(Received via mailing list)
>    false
> )
I wouldn't be too worried about the ()'s, I'd be more worried that Ruby
has a lot of various syntax...

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

anyway, more to chew on.
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-11 20:59
(Received via mailing list)
Nicholas Evans wrote:
> I'm not after a full-blown IDE. They'd be working under Windows, and I'm
> (perhaps wrongly) reluctant to open up the command prompt. I want to
> focus on programming, and not have to bother with Windows shell commands
> too.

A big part of programming is understanding the world you live in.

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

"The greatest obstacle to discovery is not ignorance, but the illusion
of knowledge."
  - D. Boorstin
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-06-11 21:15
(Received via mailing list)
James Britt wrote:
> There is nothing spooky about the command line, even in Windows.
Agreed. Even in win32, I spend a lot of time at the command line. It's
certainly better than it used to be years ago, now that it understands
the up/down arrows and filename completion.

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.

> Don't treat people like children, or they'll start acting like children.
>
> Assume the best, and let them show you otherwise.

True enough. They *are* high school students, though. Cut them
a little slack.

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


Hal
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-06-11 21:31
(Received via mailing list)
On Jun 11, 2006, at 12:55 PM, Nicholas Evans wrote:

> 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.
>
Maybe you could base the curiculum/text on Chris Pine's Learn to
Program. (Either that or Cartoon Foxes).
>
> 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.gif)?
>
Hmm, Ruby or Scheme for non-technical students? That's tough,
Scheme's sysntax makes your eyes bleed, but it has very very simple
semantics(short of callcc). OTOH the subset of Ruby I'd imagine you'd
be using for this class would have pretty simple semantics to.

> 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 don't know of any DrScheme-ish environment for ruby. You could try
using FreeRIDE or Scite (both come with the one-click installer). Or
possibly FXIrb [1]

> I appreciate any comments you can give me, list.
>
> Regards,
> Nick Evans
>

Good luck

[1] http://rubyforge.org/projects/fxirb/
31af45939fec7e3c4ed8a798c0bd9b1a?d=identicon&s=25 Matthew Smillie (notmatt)
on 2006-06-11 21:50
(Received via mailing list)
On Jun 11, 2006, at 17:55, Nicholas Evans wrote:

> Howdy list,

Howdy Nicholas.

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

When it comes to teaching programming, I'm not certain Ruby is a good
fit.  There are definitely some points in its favour, which have been
pretty much covered it seems to me, so I'll point out a couple of
reasons I think it's not an appropriate fit.  For a bit of context,
I'm a PhD student at the moment, and have been a tutor/TA on
introductory programming courses for a couple of years now (they were
in Java).

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

matthew smillie.
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-11 23:27
(Received via mailing list)
Matthew Smillie wrote:

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

If accomplishing a given task is *not* the point of the  learning
exercise, then what is, and why might students be unclear on what is
expected of them?

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.


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

Actually, this is fundamental to understanding Ruby; expressions return
values; methods are a series of expressions.

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



--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-06-12 00:22
(Received via mailing list)
You're asking for views on teaching a particular programming language to
high-schoolers. This may sound like the dumbest imaginable question, but
have you decided exactly why your students need to be studying a
programming
language?

Are you trying to impart some early training to young people who are
thinking about pursuing careers as professional programmers? Are you
thinking of it as an adjunct to a math or science courses? Are you
thinking
about orienting future businesspeople who will spend a lifetime
programming
Word and Excel macros (aarrgh, where's my razor... I can't face that
future)? Are you thinking about people destined for technical careers
for
whom some mild familiarity with scripting can be useful? Or have you
smply
taken a personal interest in imparting some of your own joy of
programming?

If you know your goals and your audience's goals, then the choice of
language(s) may be self-evident.
Ba2582cd50a59359ac3f7305ad2a0429?d=identicon&s=25 ReggW (Guest)
on 2006-06-12 00:33
Steven Davidovitz wrote:
> I think non-technical High Schoolers would definitely benefit from
> learning Ruby before moving on to other statically-typed languages.

I disagree.
I think that learning a stricter/statically-typed languages first would
benefit people better.

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.
Ba2582cd50a59359ac3f7305ad2a0429?d=identicon&s=25 ReggW (Guest)
on 2006-06-12 00:36
Timothy Hunter wrote:

> I know this will be controversial, but...IDE? Why do you need an IDE?
> They're learning programming, not clicking on things. They can write
> their Ruby programs using whatever text editor is convenient, vim,
> emacs, Scite, whatever.
>

For student just starting to learn a language, a good IDE would help
greatly.
7e7241ab3c18ae623b750cd548324377?d=identicon&s=25 Jeff Dik (s450r1)
on 2006-06-12 00:40
(Received via mailing list)
Ruby and Scheme are both beautiful languages.

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
Fe6acefaa01b60e06fd137a15fcf56e1?d=identicon&s=25 wenas agusetiawan (Guest)
on 2006-06-12 00:56
(Received via mailing list)
Hi,

I do not think that teaching ruby is a good idea because they will get
used
to built-in function and built-in function without even be able to
understand how something is built ( design patterns and etc ), IMHO
learning
what is programming better than what is programming language
3afd3e5e05dc9310c89aa5762cc8dd1d?d=identicon&s=25 Timothy Hunter (Guest)
on 2006-06-12 01:36
(Received via mailing list)
ReggW wrote:
> For student just starting to learn a language, a good IDE would help
> greatly.
>
>
>
All right, I'm listening. How would an IDE help?
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-12 03:03
(Received via mailing list)
ReggW wrote:

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

A compelling argument against using C++.



--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-12 03:03
(Received via mailing list)
wenas agusetiawan wrote:
> Hi,
>
> I do not think that teaching ruby is a good idea because they will get used
> to built-in function and built-in function without even be able to
> understand how something is built ( design patterns and etc ), IMHO
> learning
> what is programming better than what is programming language


Hear hear!

Machine code or bust.



--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine
31af45939fec7e3c4ed8a798c0bd9b1a?d=identicon&s=25 Matthew Smillie (notmatt)
on 2006-06-12 03:43
(Received via mailing list)
On Jun 11, 2006, at 22:24, James Britt wrote:

> Matthew Smillie wrote:
>
>> 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.
>
> If accomplishing a given task is *not* the point of the  learning
> exercise, then what is, and why might students be unclear on what
> is expected of them?

For introductory assignments, the results of the assignment are
invariably already known, because otherwise how will the students
know they're on the right track?  So how could the results be the
point of the exercise?  The instructor knows them, the students know
them, everyone knows them.  What the students don't know is how to
get from the input to the output, and it's *that* process that you're
trying to teach, not as a recipe, but as a skill.

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.

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

Well, isn't that equivalent to giving them a language in which the
expression of conditionals is more restricted?  What's the effective
difference of the instructor saying "always write your conditionals
this way" and the language requiring it, from the student's perspective?

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.


>> 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).
>
> Actually, this is fundamental to understanding Ruby; expressions
> return values; methods are a series of expressions.
>
> The "must remember to type a gratuitous 'return'" seems like the
> extra work.

You're assuming that they're completely understood and internalised
the concept of 'all expressions return values', which I will
guarantee that not all of them have.  When you're learning
programming, that is still something that you have to *think* about.

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.

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

Striking the balance between introducing concepts and introducing
syntax is difficult, since they have a somewhat circular relation:
this syntax expresses this concept, which is implemented using this
syntax.

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.

matthew smillie
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-06-12 03:52
(Received via mailing list)
Francis Cianfrocca wrote:
> about orienting future businesspeople who will spend a lifetime
> programming
> Word and Excel macros (aarrgh, where's my razor... I can't face that
> future)? Are you thinking about people destined for technical careers for
> whom some mild familiarity with scripting can be useful? Or have you
> smply
> taken a personal interest in imparting some of your own joy of
> programming?
>
> If you know your goals and your audience's goals, then the choice of
> language(s) may be self-evident.
I believe the goals are stated in the original post. The first half of
the course, Programming I, is to teach programming concepts. The second
half, presumably by someone else, called Programming II, is in Java.

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. :)
>> she should try it for one of the programming courses next year.
>> with writing basic functions. Our teacher kind of blamed herself for
>> think there's any merit from teaching pretty non-technical sophomores in
>>
>> I appreciate any comments you can give me, list.
>>
>> Regards,
>> Nick Evans
>>
>>
>

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-12 05:38
(Received via mailing list)
Matthew Smillie wrote:


>
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
C593616df752de0f5c037ab3465db898?d=identicon&s=25 Brian Guthrie (Guest)
on 2006-06-12 06:53
(Received via mailing list)
Nicholas Evans wrote:

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

Hi Nicholas,

For what it's worth, I took an introductory CS course taught by one of
the authors of How to Design Programs as a freshman, and we used that
book as the class text.  I found both the curriculum and the instructor
to be immensely annoying, and I won't go into it, but suffice it to say
that I think there's a lot to recommend other approaches, including the
reasons you gave.

That having been said, developing a curriculum for any subject is
difficult.  Computer science is a harder subject than most, and a lot of
very smart people have used up a great deal of ink trying.  Moreover,
Scheme is a powerful language that's well worth knowing, even if it
takes several years before you realize what you've learned.  If you do
start to develop your own set of lesson plans, please post them online
as you write them.  I'm sure you can find people, myself among them, who
would be happy to read them and make (completely uninformed)
suggestions.

 > 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/i...)?
 >
 > 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 think you're right about DrScheme, and unfortunately, I can't think of
any Ruby-based IDEs with similar features.  I can't imagine that it
would be hard to replicate the salient features of DrScheme, minus the
debugging, pretty easily in Eclipse, although I don't know that anyone's
tried yet.

For those wondering how an IDE could possibly be useful for a beginning
programming course, you should absolutely download DrScheme and check it
out.  You might be surprised.

I guess at the end of the day I do think that Ruby is a pretty good fit
for beginners, even non-technical sophomores.  I *can* say that HtDP
left a pretty sour taste in my mouth for a long time.  But Ruby is
relatively internally consistent, it's elegant, it's friendly, and it's
immediately useful.

Brian Guthrie
C475cffda1800fbc3f3af17bc10c220f?d=identicon&s=25 Curt Hibbs (Guest)
on 2006-06-12 07:26
(Received via mailing list)
On 6/11/06, Nicholas Evans <OwlManAtt@owlmanatt.com> wrote:
>
> I'm not after a full-blown IDE. They'd be working under Windows, and I'm
> (perhaps wrongly) reluctant to open up the command prompt. I want to
> focus on programming, and not have to bother with Windows shell commands
> too.
>
> 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!).


I think that Ruby is an excellent vehicle for teaching programming. I
have a
couple of suggestions:

1) Get a copy of "Learn To Program" by Chris Pine. It does precisely
what
you want to do: teach programming using Ruby. You should easily be able
to
build a curriculum from the material in this book. You can find it here:

   http://www.pragmaticprogrammer.com/titles/fr_ltp/index.html

2) If you use the One-Click Ruby Installer for Windows (
http://rubyinstaller.rubyforge.org/), it includes the FreeRIDE IDE (
http://freeride.rubyforge.org/).

Good luck!

Curt
04a0f1074e1b621746954ccc73eec7d7?d=identicon&s=25 Matthew Harris (kuja)
on 2006-06-12 07:29
(Received via mailing list)
On 6/12/06, Nicholas Evans <OwlManAtt@owlmanatt.com> wrote:
> Howdy list,
>
> I'm a highschool student with a very high chance of ending up
> student-teaching the Programming I course during the 07-08 schoolyear.

Glad to hear you have that priviledge, as a student :)

>
> This year was the first year for the course, and Scheme was used.

Scheme? Wow, that must really beat the students to death.

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

This is why I love Ruby. Ruby is very adventurous, and with every
adventure you have a good time, and it's not so difficult to
understand.

Ruby is easy to explore, and really doesn't get in your way. If you
want to teach the students some of the basics first, perhaps you
should consider the QuickRef, which is an excellent reference
(http://www.zenspider.com/Languages/Ruby/QuickRef.html).

The Pickaxe also covers a lot of the language in an orderly fashion
(http://www.rubycentral.com/book).

> The goal of the course is to teach programming concepts in half of a
> school year.

If you can teach Java or C++ in half a school year (as my high school
did), then you can most certainly teach Ruby in half 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.

I don't believe that programming is about solving only one person's
problems. Only focusing on a specific set of functionality for a
semester seems to only restrict the students from doing what they want
to do.

I'd suggest walking them through the basics, handing them lessons, but
also every now and then telling them to write programs which solve
problems they have.

Maybe one student's problem may be that he wants to calculate his
monthly allowance based on his grades. Say this student wants to see
how much allowance his parents will give him if he aces his US History
exam. Maybe another student wants to write a small game. This can be
sort of a project the students will get every 2 weeks.

I feel that programming is more about having fun.

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

If the students don't learn anything, it's natural for the teacher to
feel ashamed and feel that she is to be blamed.

I think this is where Ruby fits in well, because Ruby has a more
readable syntax than Scheme (obviously) and it has a better flow of
logic as far as the student's concerned.

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

Teaching Ruby is good, but I suggest you stay away from
metaprogramming. Students may get as confused by Ruby's
metaprogramming than they did with basic Scheme.

All in all, I think it's a good idea to teach high school students Ruby.

I have to warn you though, I'm obviously biased :)
96950c5dec0af04a5c12dae973e96cc7?d=identicon&s=25 Jeremy Tregunna (Guest)
on 2006-06-12 09:53
(Received via mailing list)
On 11-Jun-06, at 12:55 PM, Nicholas Evans wrote:

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

If you can teach someone to program, learning a new language isn't
going to be a big problem. Your decision should be less about the
language and more about the concepts you need to be teaching. Scheme
is an excellent language for teaching people how to program. Sure,
most of them are unlikely to use scheme much if ever in day to day
operations on the job (if they choose to go down this path and stick
with it), but it's an excellent language to teach programming concepts.

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

No, I don't. Keep the language simple, teach them how to program;
those who continue on with programming will find languages that they
wish to pursue, and will learn those when the time is appropriate.

> Nick Evans

--
Jeremy Tregunna
jtregunna@blurgle.ca


"One serious obstacle to the adoption of good programming languages
is the notion that everything has to be sacrificed for speed. In
computer languages as in life, speed kills." -- Mike Vanier
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-06-12 10:09
(Received via mailing list)
On 6/11/06, Nicholas Evans <OwlManAtt@owlmanatt.com> wrote:
> Howdy list,
>
> I'm a highschool student with a very high chance of ending up
> student-teaching the Programming I course during the 07-08 schoolyear.

Brian Schroeder put together quite a nice course:
http://ruby.brian-schroeder.de/course/

I found a few errors but mostly I thought it was very good.
FXRI comes with the Ruby one-click installer and may be able to
replace DrScheme.

As to whether to teach Ruby - of course! The advantage with Ruby is
that it's FUN, and I think that's the biggest factor when learning
anything.

Les
Ffcb418e17cac2873d611c2b8d8d891c?d=identicon&s=25 unknown (Guest)
on 2006-06-12 10:15
(Received via mailing list)
Jeremy Tregunna wrote:
> If you can teach someone to program, learning a new language isn't
> going to be a big problem. Your decision should be less about the
> language and more about the concepts you need to be teaching. Scheme
> is an excellent language for teaching people how to program. Sure,
> most of them are unlikely to use scheme much if ever in day to day
> operations on the job (if they choose to go down this path and stick
> with it), but it's an excellent language to teach programming concepts.

I completely agree with the above.

>> 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?
>
> No, I don't. Keep the language simple, teach them how to program;
> those who continue on with programming will find languages that they
> wish to pursue, and will learn those when the time is appropriate.

And almost agree with this too.

Knowing almost nothing about Scheme (it's a lisp), and not prejudiced
agaist it at all (honestly), a possible advantage of Ruby could be that
its libraries let you do some really fun stuff very quickly, cleanly and
easily. I can imagine that being extremely appealing in a learning
environment. However, there may be equally wonderful libraries for
Scheme, in which case this is a moot point.

The other possible advantage with Ruby is that it has a current, active
community (which, again, Scheme may have; I don't know), and if these
children are good at looking for things for themselves (which I hope
they are), then they may have more luck with Ruby in this respect.

Having made those two points, I would expect Scheme to have more
teaching environment material available for it - potted courses,
teacher's notes, etc; I believe it was originally conceived as a
teaching oriented language (this may well show my total ignorance!).

Once again though, Jeremy Tregunna is absolutely right that concepts are
transferable, and there's not a great deal of value in choosing a
teaching language because of current "real world" use.
31af45939fec7e3c4ed8a798c0bd9b1a?d=identicon&s=25 Matthew Smillie (notmatt)
on 2006-06-12 11:13
(Received via mailing list)
[much elided, since a lot of it seems like specific examples of the
following general idea]

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

Sincere and serious answer: Not really.  Most are willing to suspend
their disbelief and take your word for it, given some reasonable
explanations as to how it might benefit them.  I wouldn't say that
they really *know* it, certainly not at first, maybe not until
they've had a hairy, real-world project to tangle with, and maybe not
ever and they just think of it as having paid their dues once upon a
time by proving that quicksort will always terminate.

There's always a certain amount of "what's the point"-ism and "I'll
never have to do this in the Real World", and the various academic
urban legends[1] provide some interesting insight into how students
often conceive of their studies and evaluation[2].  Getting around
these perceptions, such as by inducing the above-mentioned suspension
of disbelief, is a fairly large part of your job as an instructor.

matthew smillie.

[1] The 'barometer question' is probably the canonical example of
academic urban legends:
http://en.wikipedia.org/wiki/Barometer_question
http://www.snopes.com/college/exam/barometer.asp

[2] In a lot of cases, though, they're entirely correct.  I've had
what I'd say is a more varied programming career than most (from web
apps c. 1997, through mainframes and telecoms switches, to graduate
school in natural language processing) and there are plenty of things
from my undergrad degree that I've never had to worry about again.
The catch, though, is that as an undergrad neither I nor my
instructors could ever have predicted exactly what has ended up being
the most useful:  I really liked the graphics course, but I've never
touched it since, and the frustratingly hard course on graph theory
has been enormously helpful.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-06-12 13:19
(Received via mailing list)
Ed Borasky said: "I believe the goals are stated in the original post.
The
first half of
the course, Programming I, is to teach programming concepts. The second
half, presumably by someone else, called Programming II, is in Java."

You rather missed my point, and the rest of your post goes on to show
that
you implicitly answered my question in a particular way. (You're
thinking
about how best to give early training to young people who intend to
become
serious programmers, as has everyone else on this thread.) That's the
assumption I was questioning.

You're an old pro, Ed, and you have a lot of good insights on how to
train
people who will be doing serious programming using the traditional
methodologies we all use every day. But CS pedagogy (at least at the
university level) has undergone at least two upheavals in the last dozen
years that I'm aware of. The Scheme revolution happened at places like
MIT
and Stanford when people realized that of the two equivalent models for
understanding computation (Church-style and Turing-style), only the
former
can be taught easily without a lot of distortion from the lanugages
used. (I
have opinions about why that turns out to be true, but that's another
thread.) Several years after that, business leaders started complaining
that
CS graduates had no real-world skills (only Scheme), and a lot of places
changed their programs to basically teach algorithm cookbooks in Java.
(In
my opinion, equally useless, in fact worse, since these young people may
know how to write Java but they don't know how to think about
computation.)

Now it's dawning on a lot of people that since programming itself may
become
a relatively low-value economic activity (why is yet another thread but
Ruby
ironically has something to do with it), some other kind of training may
need to supplement programming pedagogy. And that may be training in how
sophisticated information technology may be used to add value to
business
processes and other environments. It would be forward-looking if nothing
else for high-schoolers to be exposed to some of this.
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-12 13:37
(Received via mailing list)
Nicholas Evans <OwlManAtt@OwlManAtt.com> writes:

> I also like Ruby better than Scheme.

Again, just a matter of taste. ;-)

> teacher's assistant and I can sell Ruby, I'm going to be the one
> teaching it to the class AND the teacher.

Aah, so that's the reason.  Okay.  Of course, given you know Ruby, you
can teach Ruby better than Scheme.  Fair point.  (And it's probably
better to teach Ruby by a person that can program instead of teaching
Scheme by a person that can't program.)

>     true
>   [else false]
>  )
> )
>
> (Sorry for parse errors, if there are any.)

IMHO, cond is overused.  This is perfectly readable, no?

(define (do_something n)
  (if (< n 10)
    true
    false))

(Hint: Senseful indentation matters.)

> I was unaware that Scheme had OO. I don't really *know* Scheme, so I
> guess I'm not being terribly fair.

It doesn't have OO out of the box, but it's powerful enough to build
your own OO.

>> Of course, teaching this is not that easy.  Did you ever read SICP?
>> Have a look into it and rethink your choice.
> I haven't even heard of that. I'll look into it. =)
>
>> (Despite all of this, I prefer Ruby for *coding*, of course.  But
>> Scheme is the better choice for teaching.  YMMV.)
> Thank you for the feedback!

You're welcome.
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-12 13:44
(Received via mailing list)
Matthew Smillie <M.B.Smillie@sms.ed.ac.uk> writes:

> Ruby does have a lot going for it in this regard: first-order
> functions,

Did I miss something?
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-12 13:47
(Received via mailing list)
James Britt <james.britt@gmail.com> writes:

> Hear hear!
>
> Machine code or bust.

Once you *know* how a linked list/hash/sort/Delegate/Flyweight works,
you can use the existing version.  It's always been like that, no?
1d77c875de622dff5c63e113253d03a5?d=identicon&s=25 Bob Angell (Guest)
on 2006-06-12 14:12
(Received via mailing list)
On Jun 11, 2006, at 23:29, Matthew Harris wrote:

>> This year was the first year for the course, and Scheme was used.
>> instead
>> of Scheme. I'd have to develop my own curriculum, but whatever.
>>
>
> This is why I love Ruby. Ruby is very adventurous, and with every
> adventure you have a good time, and it's not so difficult to
> understand.
>

I thought I needed to add my $0.02 here.  My background - Medical
Informaticist
with an undergrad in Engineering/Programming.  Program in 16+ languages
on a fairly regular basis.  Love Ruby.  This being said, Scheme is
one of those
languages that do more than teach you how to write lines of code.
Many can
write programs, however, the design and understanding to put together
interfaces,
applications, etc. take a bit more understanding.  Also, computer
languages are
like tools in a tool box.  Many mechanics like programmers only use
one tool.
We have computers, calculators and other helpful devices, however,
one still
needs to understand the math, science, biology, etc. fundamentals
behind these devices to be fully effective.


> Ruby is easy to explore, and really doesn't get in your way. If you
> want to teach the students some of the basics first, perhaps you
> should consider the QuickRef, which is an excellent reference
> (http://www.zenspider.com/Languages/Ruby/QuickRef.html).
>
> The Pickaxe also covers a lot of the language in an orderly fashion
> (http://www.rubycentral.com/book).
>
>> The goal of the course is to teach programming concepts in half of a
>> school year.

Scheme is very good here.

> problems. Only focusing on a specific set of functionality for a
> exam. Maybe another student wants to write a small game. This can be
> sort of a project the students will get every 2 weeks.
>
> I feel that programming is more about having fun.
>

One can have fun with programming.  However, the scope of such courses
are generally fundamentals in nature.

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

Here is an example of poor programming principles and understanding.


>> files,
>
> I have to warn you though, I'm obviously biased :)
>

I use Ruby for quite a few things and am quite happy with its
functionality.
I too am biased in many ways, however, stepping back and looking at the
larger picture one needs to keep in mind the scope of the project.


> --
> Matt
>

-Bob-
01d68aff859065b5cbc1cfc67cb16871?d=identicon&s=25 Keith Fahlgren (Guest)
on 2006-06-12 14:16
(Received via mailing list)
On Sunday 11 June 2006 7:33 pm, Timothy Hunter wrote:
> > For student just starting to learn a language, a good IDE would
> > help greatly.
> >
>
> All right, I'm listening. How would an IDE help?

Well, if you're learning to program in Scheme and hear everyone say "Ew,
I can _never_ figure out those damn parens,"[1] you can give them a
real IDE so that they essentially never have to worry about the parens
again (see DrScheme or vim with proper syntax highlighting and %), nor
do they need to learn how to use a more advanced editor.

Now, if you're learning programming in Ruby, an IDE may not be as
important, but it's probably useful to remove as many barriers to entry
as possible--you want the kids to be learning the language, not :wq or
CTRL-X CTRL-C.

HTH,
Keith

[1]
On Sunday 11 June 2006 1:54 pm, Nicholas Evans wrote:
> That said, I saw people getting incredibly confused by the idea of
> matching the curly braces up.

On Monday 19 September 2005 12:32 am, Kev Jackson wrote:
>     - I think from your list it covers 1,2 and 3 (but only in my
> opinion) Cons
>     - notoriously alternative
>     - wierd keywords (car?)
>     - braces everywhere!
>     - not so easy to learn (not 4 in your list)

On Saturday, 26 Mar 2005 07:44am, Csaba Henk wrote:
> So the point is that you can get "lisp powa" in a modern scripting
> language as well without burying yourself under tons of parens and
> whew-how-the-heck-should-I-name-this-one like function names.


.....
31af45939fec7e3c4ed8a798c0bd9b1a?d=identicon&s=25 Matthew Smillie (notmatt)
on 2006-06-12 14:28
(Received via mailing list)
On Jun 12, 2006, at 12:42, Christian Neukirchen wrote:

> Matthew Smillie <M.B.Smillie@sms.ed.ac.uk> writes:
>
>> Ruby does have a lot going for it in this regard: first-order
>> functions,
>
> Did I miss something?

I probably should have said "higher-order functions" or "first-class
functions".  I admit to a habitual disfluency when it comes to this
distinction**.  Or am I missing what you think you're missing?

matthew smillie

** in my defence, they're very closely related, and first-order
functions are a subset of higher-order functions, so I claim that I
was technically correct (which is the best kind of correct).
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-06-12 15:35
(Received via mailing list)
Leslie Viljoen wrote:
> FXRI comes with the Ruby one-click installer and may be able to
> replace DrScheme.
>
> As to whether to teach Ruby - of course! The advantage with Ruby is
> that it's FUN, and I think that's the biggest factor when learning
> anything.
See previous post on fun ... Scheme is just as much fun as Ruby IMNSHO.

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
14ee2e1620f4c121cc25dfcd6110ebfe?d=identicon&s=25 Anton 'tony' Bangratz (Guest)
on 2006-06-12 15:38
(Received via mailing list)
Hello,

I have followed this thread now for a while, and cannot resist to add a
few
words. (Background: Freelance Programmer/Sysadmin with quite some
experience
in teaching 'Something about Computers', including various programming
languages. No LISP or Scheme, though.)

Jeremy Tregunna wrote:
>
> On 11-Jun-06, at 12:55 PM, Nicholas Evans wrote:
>
>> [Ruby or Scheme as programming language?
>
> If you can teach someone to program, learning a new language isn't going
> to be a big problem. Your decision should be less about the language and
> more about the concepts you need to be teaching.

I have to support and stress that point. The biggest mistake in a lot of
courses seems to be that the instructor mixes up 'How to program' with
'learning a specific programming language'. The most basic concepts
(calculations, conditions, operators) can be taught with the help of a
multitude of languages. The 'not-so-basic-anymore' stuff (for example
variables, functions/procedures, assignment ...) will exclude a handful
from
the set, but there's still enough left.

But all of these things can be presented even without the use of any
language.
These concepts should be like templates or blueprints: (Almost) every
language
has/needs those, and the only difference for the programmer is the
syntax.
Especially for a non-technical person, approaches that use metaphors and
'real-life examples' are easier to understand and realize.

It really doesn't matter which tools you use to visualize and exemplify
those
concepts. The real focus in this phase should be the ease of access to
the
tools of choice for the student. In this case, a scripting language has
immense advantages over every compiled language: no wait for success.
But I
digress.

The more advanced topics will sometimes be bound to the use of a certain
language, but what good does that? Knowing about specifics of a
programming
language does as little for programming skills as knowing (only) about
MySQL
(or dBase, or BDB) teaches about databases. With good basics, though,
one can
come far.

All in all, an understanding is much more productive and helpful than
mechanical repetitions and 'cookbook recipes'.

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

For me, it's all about the question 'Which tools will enable the student
to
learn without being sidetracked or even hindered?'

AFAIK, DrScheme or Smalltalk have a clear advantage there. Knowing only
the
latter, I dare to simplify: the IDE is the VM is the IDE. Now, my
personal
preference is still Ruby.

First reason: Because I can -- without having to specify anything --
leave the
choice of the most important tool, the editor, to the students whose
interests
are deep enough for making that kind of choice, and show the other
simple yet
powerful alternatives (my own choice doesn't count, as I personally
prefer
vim, but wouldn't try to force anyone to make use of all the builtin
goodness).

The second reason is the ultimate blackboard, the try-and-error
playground
which is built in: irb. Readline support, even completion is available,
and
the success for the most basic things is immediately visible, which is
invaluable for overall success and progress.

In the end, it's all about personal preference. If you feel more
comfortable
with Ruby, stick with it. If any other programming languages feels more
natural to you, and you manage to explain the most basic concepts to
someone
new to programming with the help those, stick with that.

>
> No, I don't. Keep the language simple, teach them how to program; those
> who continue on with programming will find languages that they wish to
> pursue, and will learn those when the time is appropriate.
>

This is the second statement I want to support with all emphasis. The
/concepts/ are more important than any specific language skill at the
end of
the day. There is no need to teach every possible way (as mentioned
somewhere
else in this thread): the skillful will find the way, the less skillfull
will
work with what has been given to them.

Now, I want to freely comment on some other statements within this
thread:

It seems that sometimes 'learning how to program' is confused with 'not
having
fun' or even 'no pain - no gain'. I had the mixed blessing to learn
various
things (not only programming) from very different people. The things I
remember best and that helped me most were those where learning was
coupled
with 'having fun'. And nowadays, where we have (as instructors) the
freedom of
choice of tools, why should we still transfer 'our' pain of the past
onto the
back of our poor students?

Or maybe it's just elitism, and the creepy feeling that these days
'hackerdom'
isn't as removed from 'the masses' as it has been?

On another note: if a certain concept doesn't exist in a certain
language, and
the concept is too important to be skipped, why sticking to one language
all
the time? If it's really *that* necessary to teach it, there's ways
around the
'restrictions' we put on ourselves. I do not preach babylonic confusion,
but
eclectic picking of choices.

Yes, the signature is random, no, I didn't pick it. Neat fit, though.

I'll leave it at that.

t.
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-12 16:00
(Received via mailing list)
Christian Neukirchen wrote:
> James Britt <james.britt@gmail.com> writes:
>

>>
>>Machine code or bust.
>
>
> Once you *know* how a linked list/hash/sort/Delegate/Flyweight works,
> you can use the existing version.  It's always been like that, no?

Yes.  One could use Ruby to show how various built-in features work,
then use the Ruby version.  Students would know the essentials of linked
lists, etc., and could then move on to using the built-in stuff.

Arguing that this may involve too much hand-waving means moving further
down the abstraction layers; the demarcation point, though, may be
arbitrary.  At what point do you say, That's too much low-level detail?

(For the previous poster: Why is it OK to use, say, C to write data
structures?  Doesn't that obscure how something is built (registers,
memory allocation, instruction pointers, etc.) )

A later post by Matthew Smillie raised some good questions, particularly
regarding what it is that students should be learning.  For vocational
training, maybe the copious Java APIs would be best, or C# and WinForms.

But to prepare people to make best use of current computational
technology, how much geeky detail is right?   Do people *really* need to
know the differences among various sorting algorithms?  I'm inclined to
think that one cannot call oneself a programmer  without some reasonable
knowledge of sorting, searching, various machine architectures,
networking basics; well, basically the stuff one gets from a CS degree.

Much like taking a driver's ed. course does not make you a mechanic,
knowing how to assemble lines of code to run without errors and produce
correct results does not make you a programmer (except in some loose
populist sense).   It means you can get from one place to another
without crashing.  Maybe that's enough.

Does the average coder need to know how to write a search algorithm or
build a linked list?  Perhaps students should first be taught good
taste; there seems to be less and less need to solve the low-level
problems.  They're done. The issue now is how to best take available
tools and make good, clean choices, both in the problems to solve and
how the solutions are executed.

Teach aesthetics, not engineering.

--
James Britt

"I never dispute another person's delusions, just their facts."
  - Len Bullard
31af45939fec7e3c4ed8a798c0bd9b1a?d=identicon&s=25 Matthew Smillie (notmatt)
on 2006-06-12 16:44
(Received via mailing list)
> there seems to be less and less need to solve the low-level
> problems.  They're done.

Or maybe not!
http://googleresearch.blogspot.com/2006/06/extra-e...
it-nearly.html

m.s.
C475cffda1800fbc3f3af17bc10c220f?d=identicon&s=25 Curt Hibbs (Guest)
on 2006-06-12 17:26
(Received via mailing list)
On 6/12/06, Keith Fahlgren <keith@oreilly.com> wrote:
> real IDE so that they essentially never have to worry about the parens
> again (see DrScheme or vim with proper syntax highlighting and %), nor
> do they need to learn how to use a more advanced editor.
>
> Now, if you're learning programming in Ruby, an IDE may not be as
> important, but it's probably useful to remove as many barriers to entry
> as possible--you want the kids to be learning the language, not :wq or
> CTRL-X CTRL-C.


The navigation tree that shows the ffile's contents (modules. classes,
methods)  that you get with most IDEs is very useful to be able to see
the
structure of the software at a glance. This is very helpful to beginners
and
experts, alike.

Curt
391f9b787cdc12aa2c179713f5103e3a?d=identicon&s=25 Ilan Berci (iberci)
on 2006-06-12 17:38
Concerning the ide vs command line: nothing beats irb as a learning
tool.  It's quick, easy, immediate, tangible, heavenly!

I don't work for or am in any way associated with Thomas/Hunt and/or the
pickaxe books but if I was tasked with designing a course, I would
follow their example.  They mentioned in their first book of the
difficulties of putting the book together as they initially wanted to
start with OO but then later realized that it would have to be addressed
only after introducing 'some' language constructs or the OO concepts
would have no footing.  That book was one of the best books ever written
in the software field and has a great juke box rolling example that you
can base your whole course around.

All basic coding constructs can be expressed as easily in Ruby as any
other language.  So what if it has many built in features?  I remember
learning all about arrays with my trusty Borland 3.0 c++  compiler and
then being horrified to see that they had an Array class and thinking
that there would never be a need for simple arrays.. :)

Finally OO IS REAL LIFE, the whole world is made of components
interacting with other components.  It is impossible to think of a
component that we use daily that doesn't have aspects of polymorphism or
encapsulation.  We start out at the age of 3 knowing what an object is
only to unlearn it when we start to code!? Anyways, thankfully, I think
the days of OO being some kind of mystery are finally behind us.  This
may seem contradictory from what I stated above but isn't!  :)

IDE's are actually confusing to the user as they have to jump 2 steps
instead of one.  They may be intimidatd from learning the IDE and that
would deter them from learning the language.  I work with Eclipse for my
day job and after years of twiddling with it, have it perfectly tweaked
for my needs, but anyone coming to my office would have a problem being
productive with it.  Actually, come to think of it, I don't think there
is a sigle member on my team that has a simillar development
environment.

p.s.  If I was to use Ruby in a teaching course, I would explicitly
express the method signature notation to ease the learning curve.

with love, ilan
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-06-12 17:55
(Received via mailing list)
On Jun 12, 2006, at 8:25 AM, Matthew Smillie wrote:

> class functions".  I admit to a habitual disfluency when it comes
> to this distinction**.  Or am I missing what you think you're missing?
>
> matthew smillie
>
> ** in my defence, they're very closely related, and first-order
> functions are a subset of higher-order functions, so I claim that I
> was technically correct (which is the best kind of correct).
>

I think what you're missing that he's missing is that Scheme has
first-class functions (higher order functions), and is in fact so
wrapped up in them that it's almost useless (or at least not very
idiomatic scheme) without them. IOW, when comparing Ruby to Scheme
that's probably not the point to emphasize ;)
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-12 18:09
(Received via mailing list)
ilan berci wrote:

>
> Finally OO IS REAL LIFE,

Really?   OO is a gross simplification of real life, handy for code
organization under various (but not all) circumstances.

Luckily, software is not real life.


--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine
4674615d2cf231975c741731be9a8685?d=identicon&s=25 why the lucky stiff (Guest)
on 2006-06-12 18:13
(Received via mailing list)
On Mon, Jun 12, 2006 at 06:10:37PM +0900, Matthew Smillie wrote:
> Sincere and serious answer: Not really.  Most are willing to suspend
> their disbelief and take your word for it, given some reasonable
> explanations as to how it might benefit them.

Also, you will probably have to do a few sleights-of-hand.  For example,
many
people feel driven to use Try Ruby[1] because of the initial fun of just
watching the tutorial work.  I knew most people wouldn't really care
that
"2 + 6" works.  The first few lesson are just to get people comfortable,
disarm
their ideas about the difficulty of learning.

I would find some tricks to make your students think they're learning
faster
than they actually are.  It'll juice the adrenaline just enough.

It's just like a chemistry teacher having fun with liquid nitrogen and a
banana.
You want to find dramatic, compelling exercises that you enjoy
performing and
that the students totally lap up.

For Ruby, the equivalent of the liquid nitrogen experiment is the social
projector demo.  You set up a projector connected to a server.  And you
give
each student a REPL (irb) which acts as the client.  Then you give
students
commands which will affect the screen.  In the past, I've used DRb[2]
and students
are given an object and they run methods.  I have a number of variations
of this:

 * Each student gets a section of the screen which can be altered in
color and
   shape.  Or a screen full of emoticons or avatars.

 * Students vote on topics and the screen charts their response.

 * You show a picture on screen and ask students to "tag" the picture.
Words
   appear on screen with size corresponding to the popularity.  Use
ambiguous
   imagery that solicits interesting responses.

The idea here is that students watch the screen fill and feel the reward
as a
group.  High school students crave group acceptance anyway, so this
feeds that
craving.

Unfortunately, you may not have the resources to do this, since commerce
has
thieved rabidly any good concentration on education.  I have been
working on my
own tools, but I'm a very bad programmer and distracted.  It's sad that
DrScheme
is even considered as an option.  Sure, it's among the best we have, but
it's
still a bad option.  It's ugly, it has too many menus, the interface is
unnatural.  It's not made for the average kid, it's made for geek kids.

Anyway, this is Programming I.  Lower your goals.  I wouldn't even
attempt to
cover most of the concepts.  Just get the class captivated and stay as
simple as
you can.  Good luck, intrepid Nicholas.  DO NOT TRY TO WRITE A GAME.

_why

[1] http://tryruby.hobix.com
[2] http://www.chadfowler.com/ruby/drb.html
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-12 19:07
(Received via mailing list)
Matthew Smillie <M.B.Smillie@sms.ed.ac.uk> writes:

> functions".  I admit to a habitual disfluency when it comes to this
> distinction**.  Or am I missing what you think you're missing?

Well, Ruby doesn't have first-class *functions*.  It "just" has
blocks, which allow code to be passed around as *objects*, not as
*functions* (read: methods).

Compare mymethod(foo) with myblock.call(foo).

> matthew smillie
>
> ** in my defence, they're very closely related, and first-order
> functions are a subset of higher-order functions, so I claim that I
> was technically correct (which is the best kind of correct).

I see what you mean, but it's important to recognize that Scheme has
true first-class functions (being a Lisp-1), whereas there is a
fundamental difference between Blocks/Procs/lambdas and methods (being
a Lisp-2).

Since Ruby is considered an OO language and Scheme a functional
language, this is fine.
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-12 19:20
(Received via mailing list)
Anton 'tony' Bangratz <tony@twincode.net> writes:

> AFAIK, DrScheme or Smalltalk have a clear advantage there. Knowing only the
> latter, I dare to simplify: the IDE is the VM is the IDE. Now, my personal
> preference is still Ruby.

Funny you mention Smalltalk.  I think it would make a great teaching
language too.  It has an easy and logical, but well readable syntax, a
graphical environment and it's great for teaching OO, of course.

> First reason: Because I can -- without having to specify anything -- leave the
> choice of the most important tool, the editor, to the students whose interests
> are deep enough for making that kind of choice, and show the other simple yet
> powerful alternatives (my own choice doesn't count, as I personally prefer
> vim, but wouldn't try to force anyone to make use of all the builtin goodness).

I could imagine these kids post endless stuff on their Livejournal or
MySpace and write that directly into the browser... do you really
think they care that much about editors?  Both DrScheme and Squeak
provide convenient and appropriate ways of code editing.  (Though I
have to admit that the main reason I don't use more Squeak is that I
can't easily edit it in Emacs.)

> The second reason is the ultimate blackboard, the try-and-error playground
> which is built in: irb. Readline support, even completion is available, and
> the success for the most basic things is immediately visible, which is
> invaluable for overall success and progress.

Is irb that much better than an evaluation window?  Squeak is even
more "live" than Ruby.
171a9b5755cdb090e0c2b3c20a521fbc?d=identicon&s=25 Phil Hagelberg (Guest)
on 2006-06-12 19:31
(Received via mailing list)
why the lucky stiff <ruby-talk@whytheluckystiff.net> writes:

> DO NOT TRY TO WRITE A GAME.

I'm a bit curious about why you suggested this since writing a game
seems to be precisely the way many beginning programmers learn. (Or at
least it was in the days when practically every computer had QBasic.)
Is it because you'll get sidetracked by graphics concepts (which don't
really have much to do with the fundamentals of programming) or is
there another reason?

It seems if it's done right, writing a game can be a very engaging way
to learn. Perhaps it would be better if the incidentals (like
graphics) were abstracted away--perhaps handled by a program written
by the instructor on one machine hooked up to a projector, while
students only communicated with it over DRb, and thus wouldn't have to
think about things like rendering.

-Phil Hagelberg

http://technomancy.us
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-12 19:39
(Received via mailing list)
James Britt <james.britt@gmail.com> writes:

> Christian Neukirchen wrote:
>> Once you *know* how a linked list/hash/sort/Delegate/Flyweight
>> works,
>> you can use the existing version.  It's always been like that, no?
>
> Yes.  One could use Ruby to show how various built-in features work,
> then use the Ruby version.  Students would know the essentials of
> linked lists, etc., and could then move on to using the built-in
> stuff.

Exactly.

> Arguing that this may involve too much hand-waving means moving
> further down the abstraction layers; the demarcation point, though,
> may be arbitrary.  At what point do you say, That's too much low-level
> detail?

Of course, that's a question of time.  If you only have a half or a
full year, you need to stop digging deeper pretty soon; depending on
what you really want them to learn.  Give foundations for figuring out
on their own.

> But to prepare people to make best use of current computational
> technology, how much geeky detail is right?   Do people *really* need
> to know the differences among various sorting algorithms?

People don't, but a reasonable programmer really ought to.  He at
least should know *where* to lookup sort algorithms, *how* to evaluate
them and make a good choice, and finally *implement* them, given a
description in English or pseudocode.

Your PHP codemonkey doesn't need to be able to do that, but if I hired
a serious programmer, I would expect that.

> I'm
> inclined to think that one cannot call oneself a programmer  without
> some reasonable knowledge of sorting, searching, various machine
> architectures, networking basics; well, basically the stuff one gets
> from a CS degree.

You don't need a CS degree (there are so many very good self-thought
people around), and you don't to know all the stuff by heart.  But you
need to be able to learn and pickup these things.

> Much like taking a driver's ed. course does not make you a mechanic,
> knowing how to assemble lines of code to run without errors and
> produce correct results does not make you a programmer (except in some
> loose populist sense).   It means you can get from one place to
> another without crashing.  Maybe that's enough.

That's a bad analogy.

Driver   : Car = User       : Application
Mechanic : Car = Programmer : Application

> Does the average coder need to know how to write a search algorithm or
> build a linked list?  Perhaps students should first be taught good
> taste; there seems to be less and less need to solve the low-level
> problems.  They're done. The issue now is how to best take available
> tools and make good, clean choices, both in the problems to solve and
> how the solutions are executed.

I'd like to add that it's wrong to think every problem can be solved
by another level of abstraction.

> Teach aesthetics, not engineering.

"Software aesthetics" sounds a lot better than "Software engineering",
too :-)
51a34236538906ab994cf9f2e533d14d?d=identicon&s=25 Lou Scoras (ljscoras)
on 2006-06-12 20:10
(Received via mailing list)
On 6/12/06, James Britt <james.britt@gmail.com> wrote:
> Do people *really* need to know the differences among various sorting algorithms?  I'm
> inclined to think that one cannot call oneself a programmer  without some reasonable
> knowledge of sorting, searching, various machine architectures, networking basics; well,
> basically the stuff one gets from a CS degree.

[ snip ]

> Does the average coder need to know how to write a search algorithm or build a linked
> list?  Perhaps students should first be taught good taste; there seems to be less and
> less need to solve the low-level problems.  They're done. The issue now is how to best
> take available tools and make good, clean choices, both in the problems to solve and
> how the solutions are executed.

James, I think that your conclusion here is correct: there should be a
focus on using the best tools available to complete the current task.
However, might I suggest that there is still much value in focusing on
the traditional CS fare, even for "the average coder"?

Although it may not be important to know the intimate details of
implementing, say a bubble-sort vs. a merge-sort, I would contend that
it *is* important to know what makes each one (in)efficient and under
what circumstances.  Someone learning to code should learn O(n)
notation so that they know how to compare different algorithms--even
one's of their own creation.

Is it important to know you are using an array rather than a
linked-list?  I think so.  Even if you don't know how they are built,
you should know which one to use.  Which is better if I need to do
many insertions to the middle of the list?  Of course, we CS types
take this sort of thing for granted because we understand the
concepts, even when we aren't required to  implement them.

In fact, my thought here is that the most important stuff really is
the theory: algorithms & data structures, not any particular language.
 Students should probably be encouraged to write things out as
pseudo-code before anything else.  You don't need a computer to write
an algorithm. Just ask Euclid =)

Consequently, I think this is one thing scheme (lisp in general) has
going for it.  There isn't really much syntax to learn at all.  You
have atoms, lists, and function calls but not much else (well, macros,
but I'll leave that one alone).
31af45939fec7e3c4ed8a798c0bd9b1a?d=identicon&s=25 Matthew Smillie (notmatt)
on 2006-06-12 20:59
(Received via mailing list)
On Jun 12, 2006, at 18:06, Christian Neukirchen wrote:

> it's important to recognize that Scheme has
> true first-class functions (being a Lisp-1), whereas there is a
> fundamental difference between Blocks/Procs/lambdas and methods (being
> a Lisp-2).

This has slightly confused me, but I'll admit that it's been a while
since I've dealt with this sort of thing, so jump in with corrections
as required.

   - A language has first-class functions when a function can be
assigned to variable, passed to or returned from another function,
and so on.  In Ruby, a = lambda { |x| x + 1 } for example.

   - The distinction between Lisp-1 and Lisp-2 that the latter has a
separate namespace for functions, in Ruby, for example, def a(x) x +
1; end can exist alongside a = lambda { |x| x + 1 } (and there's a
corresponding hoop to jump through to call the lambda).

What I don't understand is how it follows that being in a different
namespace implies that Lisp-2 doesn't have true first-class
functions.  The only reason I can think of is the circular one that
"only Lisp-1 has true first-class functions", which gives it the
distinct flavour of an age-old Lisp holy war (if that's the case,
consider me uninterested).

matthew smillie.
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-06-12 21:09
(Received via mailing list)
On Jun 12, 2006, at 2:58 PM, Matthew Smillie wrote:

> corrections as required.
> What I don't understand is how it follows that being in a different
> namespace implies that Lisp-2 doesn't have true first-class
> functions.  The only reason I can think of is the circular one that
> "only Lisp-1 has true first-class functions", which gives it the
> distinct flavour of an age-old Lisp holy war (if that's the case,
> consider me uninterested).
>
> matthew smillie.
>

In a Lisp-2 you have to use special syntax (funcall, apply, #call) to
call a function-value. I believe that was the distinction he was making.
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2006-06-12 21:38
(Received via mailing list)
> http://rubyinstaller.rubyforge.org/), it includes the FreeRIDE IDE (
> http://freeride.rubyforge.org/).
>
> Good luck!

I just want to second this. I definitely think Ruby is a useful
language to teach beginning programming. It's real-world enough that
you might use it for practical purposes further down the line and it's
easy enough that the kids will think about "what can I do with this?"
instead of just freaking out over the details.

a friend in his early 20s was taking a Java class, I told him drop out
and get "Learn to Program" instead. I definitely endorse that
approach.
96950c5dec0af04a5c12dae973e96cc7?d=identicon&s=25 Jeremy Tregunna (Guest)
on 2006-06-12 22:10
(Received via mailing list)
On 12-Jun-06, at 12:08 PM, James Britt wrote:

> ilan berci wrote:
>
>> Finally OO IS REAL LIFE,
>
> Really?   OO is a gross simplification of real life, handy for code
> organization under various (but not all) circumstances.

People tend to abuse this point of object-oriented languages; they
treat classes/objects like modules, and quite frankly, it's sometimes
really annoying to read.

> Luckily, software is not real life.

Phew!

> James Britt

--
Jeremy Tregunna
jtregunna@blurgle.ca


"One serious obstacle to the adoption of good programming languages
is the notion that everything has to be sacrificed for speed. In
computer languages as in life, speed kills." -- Mike Vanier
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-12 22:54
(Received via mailing list)
Jeremy Tregunna wrote:
>
>
> People tend to abuse this point of object-oriented languages; they
> treat classes/objects like modules, and quite frankly, it's sometimes
> really annoying to read.

Oh, absolutly.  But, by the same token, not every line of code needs to
be part of some object scheme.



--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine
14ee2e1620f4c121cc25dfcd6110ebfe?d=identicon&s=25 Anton 'tony' Bangratz (Guest)
on 2006-06-12 23:27
(Received via mailing list)
Christian Neukirchen wrote:
> Anton 'tony' Bangratz <tony@twincode.net> writes:
>
>> AFAIK, DrScheme or Smalltalk have a clear advantage there. Knowing only the
>> latter, I dare to simplify: the IDE is the VM is the IDE. Now, my personal
>> preference is still Ruby.
>
> Funny you mention Smalltalk.  I think it would make a great teaching
> language too.  It has an easy and logical, but well readable syntax, a
> graphical environment and it's great for teaching OO, of course.

I have to take your word for this (and that of a good friend, of
course). After installing squeak, I had a few troubles to get me
started, but that was probably because X.org is a means to hold a
multitude of xterms and three other applications to me. I'm too much
of a console guy, I fear.

> I could imagine these kids post endless stuff on their Livejournal or
> MySpace and write that directly into the browser... do you really
> think they care that much about editors?  Both DrScheme and Squeak
> provide convenient and appropriate ways of code editing.  (Though I
> have to admit that the main reason I don't use more Squeak is that I
> can't easily edit it in Emacs.)

The point-and-click interface is not so intuitive as I hoped, but I
could get used to it.

> Is irb that much better than an evaluation window?  Squeak is even
> more "live" than Ruby.
>

That's true. For me, irb is my 'sandbox', my testing area where I can
try ideas with a few keystrokes. In my experience, focussing on more
than one window or following instructions around "move the mouse
pointer over the orange tab with the word 'Navigation' on it and click
ONCE!" is taxing for most beginners. Typing a word, hitting 'Enter'
and seeing immediate reaction is more direct - in the beginning.

It's true that objects and messages can be more easily illustrated and
used in squeak. That's when the personal preferences hit, about syntax
and intuitive manipulation.

My other 'thing' is that I am using ruby for administrative tasks,
complex scripts and Rails. So it has a lot of real-world value and
provides me with a neverending source of useful examples.

Summary: I could not decide which to take if my life depended on it. I
think I'd try to show both, thus stressing the point that concepts are
more important than recipes.

t.
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-06-12 23:50
(Received via mailing list)
why the lucky stiff wrote:
>
> It's just like a chemistry teacher having fun with liquid nitrogen and a banana.
> You want to find dramatic, compelling exercises that you enjoy performing and
> that the students totally lap up.
>

Ahhh, now we're talking. Watch as I dip my Ruby code
into liquid nitrogen and then use it to drive a nail...


Hal
38c94343d160b921ee22e9f0fb4c18b4?d=identicon&s=25 Nicholas Evans (Guest)
on 2006-06-13 01:04
(Received via mailing list)
benjohn@fysh.org wrote:
>
> I completely agree with the above.

Now that I think about it, I suppose that the language is not that
important. I won't be teaching a bunch of people who are interested in
programming as a hobby, nevermind professionally.

The Programming I course is part of a program at my school called the
Academy of Information Technology. The purpose of the program is to
expose students to lots of career possibilities in the IT field. That
means we get lots of half-year courses. The full run of the academy
lasts three years, sophmore to senior, and covers a quick run through
computer history, programming, relational databases, systems support,
networking, and a full year of Microsoft Office (woo).

I'll be lucky (luckier than a lucky stiff!) if I get one or two people
who are actually interested in programming. So maybe it would be
detrimental if I were to get 'too' geeky/in-depth. My target audience
will probably use the concepts taught in simple Excel formulas.

I'm completely torn on the issue of Scheme or Ruby now. I've seen a
major point on each side of the debate:

A. Scheme, if unelegant looking, does have simple, consistant syntax,
allowing people to focus more on learning 'programming' as opposed to
learning Scheme.

B. Ruby offers many ways to do things, syntax-wise. Only one way could
be taught and stuck to, and those interested could explore on their own.
All the same, it would be easy to get caught up in Ruby syntax instead
of programming.

James Britt wrote:
> A big part of programming is understanding the world you live in.
>
> 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.

I suppose I have to agree with you. That said, we *are* children, and we
do act like children (some a good deal more than others).

I think one of my school's biggest problems with all of its classes
involving computers is that teachers ignore it when you screw around on
MySpace or Miniclip all class. Students no longer take the class
seriously, and are not there to learn, but to check their e-mail. Of
course, a typical American teenager's (lack of?) desire to learn is a
whole nother topic.

Keith Fahlgren wrote:
> Now, if you're learning programming in Ruby, an IDE may not be as
> important, but it's probably useful to remove as many barriers to entry
> as possible--you want the kids to be learning the language, not :wq or
> CTRL-X CTRL-C.

This is my reluctance to open up the Windows command line. James,
however, put that reluctance away by pointing out that programming is
about understanding your world. I guess introducing people to such a
beast does have a place in Programming I, even if its just to better
farmiliarize people with their Windows environment.

All the same, a DrScheme-like frontend to irb would be a big convinience
to everyone. Less typing == less errors == less confusion == less
frustration-in-an-already-challenging-situation. IMHO.

Christian Neukirchen wrote:
> Of course, that's a question of time.  If you only have a half or a
> full year, you need to stop digging deeper pretty soon; depending on
> what you really want them to learn.  Give foundations for figuring out
> on their own.

Matthew Smillie wrote:
> This has slightly confused me, but I'll admit that it's been a while  since I've dealt 
with this sort of thing, so jump in with corrections  as required.
>
>   - A language has first-class functions when a function can be  assigned to variable, 
passed to or returned from another function,  and so on.  In Ruby, a = lambda { |x| x + 1 
} for example.
>
>   - The distinction between Lisp-1 and Lisp-2 that the latter has a  separate namespace 
for functions, in Ruby, for example, def a(x) x +  1; end can exist alongside a = lambda { 
|x| x + 1 } (and there's a  corresponding hoop to jump through to call the lambda).
>
> What I don't understand is how it follows that being in a different  namespace implies 
that Lisp-2 doesn't have true first-class  functions.  The only reason I can think of is 
the circular one that  "only Lisp-1 has true first-class functions", which gives it the 
distinct flavour of an age-old Lisp holy war (if that's the case,  consider me 
uninterested).

Nothing holds less truth than the phrase 'there is always a better
wizard than you'.  I'll admit that I've never had any formal CS
training, and until recently, my experiences have been limited to
PHP4/MySQL/Oracle stuff. (I'm a self-taught sixteen year old with some
obscene amount of time invested in fiddling with PHP, then had my
education greatly sped up when I was recruited as a web app developer
for a small ISP.)

No object stuff. Limited technical vocabulary. I'm not qualified to
teach the class, but (all ego aside, really!) I am probably more
qualified than one of our business teachers, who has no experience with
programming. So I suppose I have some learning of my own to do before
the '07 schoolyear. :-)

I am very grateful to you all for your inputs. I did not anticipate such
an overwhelming response. Thanks!
38c94343d160b921ee22e9f0fb4c18b4?d=identicon&s=25 Nicholas Evans (Guest)
on 2006-06-13 01:13
(Received via mailing list)
why the lucky stiff wrote:
> It's just like a chemistry teacher having fun with liquid nitrogen and a banana.
> You want to find dramatic, compelling exercises that you enjoy performing and
> that the students totally lap up.
Aye, that's something I agree with. Thermite paste is a bit more
dramatic that /anything/ nitrogen can do, though.

>
>  * You show a picture on screen and ask students to "tag" the picture.  Words
>    appear on screen with size corresponding to the popularity.  Use ambiguous
>    imagery that solicits interesting responses.
>
> The idea here is that students watch the screen fill and feel the reward as a
> group.  High school students crave group acceptance anyway, so this feeds that
> craving.
That's actually a really nifty idea for introducting people to Ruby.

> Good luck, intrepid Nicholas.  DO NOT TRY TO WRITE A GAME.
Thanks!

I'm also guessing that you're saying don't write a game because people
will be discouraged by the fact that they can't create Unreal 2010 with
four lines of code, MS Paint, and a lot of luck?

Again, thank you all!

Regards,
Nick Evans
E2bbe31fb94e92f5f404c5cb550c371f?d=identicon&s=25 unknown (Guest)
on 2006-06-13 02:02
(Received via mailing list)
> This is the second statement I want to support with all emphasis. The
> /concepts/ are more important than any specific language skill at the end of
> the day. There is no need to teach every possible way (as mentioned somewhere
> else in this thread): the skillful will find the way, the less skillfull will
> work with what has been given to them.

I am currently in finals week for two courses I am teaching using Ruby
at the Art Institute of Phoenix and I can attest whole heartedly to
this sentiment.  With the caveat that I a have students that are
either 50% programming / 50% art students or 100% art students and are
taking a required course, my experience has been that the concepts are
where people are getting hung up, not the syntax/language constructs.
As a result I am changing my curriculum for next quarter to be MUCH
heavier on non-computer related exercises that promote a healthy dose
of critical thinking and problem solving abilities.  I?m not sue
exactly what kind of students you are going to get but I find that
critical thinking is a skill that needs to be developed a bit before
going anywhere near an IDE.

As for a Ruby vs Scheme I have also found a fair amount of people have
dabbled at least a little in programming related topics.  Perhaps it?s
adding a Javascript do-dad to their website or (since these are
artists) a simple Flash game.  The more familiar syntax of Ruby was a
big win there.  It was especially rewarding to ask the students to
?write? a program by just calling out some pseudocode which I could
baby sit on the whiteboard as we came to a solution.  When it was all
done I told them to type that into their editor and run it.  The Ruby
syntax and the problem I had chosen went together very well and it
really was a case of executable pseudocode which I think helped with
some of the fears about the ?strangeness? of programming.

Now I only have 11 weeks while you have half a year so obviously your
course can be a bit more full that mine bit I find that I can get up
to objects but not cover them in any particular depth.  For our final
projects we did a lot involving the File and Directory classes as many
people wanted to write helper utilities to clean up files or rearrange
them.  This practical application seems to have gone over pretty well
as the students can see how this skill can benefit them on a day to
day basis.  I?m not sure I could have gotten to the same point using
something like Scheme (and yes, I did consider it for this course).

Hopefully this will be useful to you in some degree.  I plan on
putting up all my course material and posting a link once I have
incorporated the changes from this quarter.

David Koontz
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-13 15:38
(Received via mailing list)
Logan Capaldo <logancapaldo@gmail.com> writes:

>> This has slightly confused me, but I'll admit that it's been a
>> a corresponding hoop to jump through to call the lambda).
>
> In a Lisp-2 you have to use special syntax (funcall, apply, #call) to
> call a function-value. I believe that was the distinction he was
> making.

Exactly.  If there are two different syntaxes for a) method calling,
and b) calling of "first-class" code objects ("functions"), these
functions are a) either are not really first-class or b) not functions
in the usual meaning of the term.

I could also say: Ruby has first-class lambdas (which *wrap* a block
or a method), but not first-class methods (or blocks, for that
matter).  In Scheme, all executable code objects are first-class.

In real life, it's probably not that important; but from the language
aspect, it's rather characterizing.  (E.g. python has first-class
functions and first-class methods (which are functions, too)).
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-06-13 15:47
(Received via mailing list)
david@koontzfamily.org writes:

> With the caveat that I a have students that are
> either 50% programming / 50% art students or 100% art students and are
> taking a required course, my experience has been that the concepts are
> where people are getting hung up, not the syntax/language constructs.

Now you mention it, I'd like to add one more thing: Don't do too much
math.

The CS class I need to attend is led by a maths/physics teacher, and
we use Pascal---a language that sucks at string/symbol processing.  A
lot of my pals get turned off by calulating factorials, printing
square roots or doing fibonacci stuff.

With the languages considered here---Scheme, Ruby or Smalltalk---you
have the great possibility to do better.  For example, write a small
database-like system with a few hashes, or a vocabulary trainer, or
whatever.  Sure, some of these math things are "essential", but there
is so much more computers can do that is not number-crunching.  Your
students will like it, especially if they are not maths-oriented anyway.
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-06-13 15:51
(Received via mailing list)
Nicholas Evans wrote:

>
> I suppose I have to agree with you. That said, we *are* children, and we
> do act like children (some a good deal more than others).

Me too, but even *I* can still use the command line.


>
> I think one of my school's biggest problems with all of its classes
> involving computers is that teachers ignore it when you screw around on
> MySpace or Miniclip all class. Students no longer take the class
> seriously, and are not there to learn, but to check their e-mail. Of
> course, a typical American teenager's (lack of?) desire to learn is a
> whole nother topic.

Turn off the freakin' Internet access.


> ...
> I am very grateful to you all for your inputs. I did not anticipate such
> an overwhelming response.


Well, this is Rubyland.  We're responsively overwhelming here.




--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine
Ce8b03e5750097942c58e12b46724312?d=identicon&s=25 Giles Bowkett (Guest)
on 2006-06-13 19:30
(Received via mailing list)
>> Don't treat people like children, or they'll start acting like children.
>
> I suppose I have to agree with you. That said, we *are* children, and we
> do act like children (some a good deal more than others).

I think this is actually your greatest asset. Make it as fun as you
can (and as James said kill the internet access, then all eyes will be
on you).
E2bbe31fb94e92f5f404c5cb550c371f?d=identicon&s=25 unknown (Guest)
on 2006-06-13 21:27
(Received via mailing list)
Heh, yes I am very aware of the math-phobia in my students.  The only
time I can really get buy-in on math concepts is in a "necessary evil"
capacity such as for game related scenarios.  I'm certainly not going
to have them solve fibonacci just for the sake of doing it, and there
is naught a square root to be seen in the course work :)  I'm shooting
for more usage of RRobots next quarter after I can eliminate most of
the "just ignore all that stuff, I'll explain it later" which I detest
doing.

David Koontz

Quoting Christian Neukirchen <chneukirchen@gmail.com>:
This topic is locked and can not be replied to.