Ruby for Highschoolers?

ruby-talk
41

James Britt <james.britt@gmail.com> writes:

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.

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?

···

James Britt

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

42

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.

···

--
Anton Bangratz - Key ID 363474D1 - http://tony.twincode.net/
fortune(6):
Everybody gets free BORSCHT!

43

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.

···

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

44

Nicholas Evans wrote:

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

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

45

James Britt wrote:

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.

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

46

[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:

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

···

from my undergrad degree that I've never had to worry about again.

47

> 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 7:33 pm, Timothy Hunter wrote:
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.

.....

48

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

···

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?

49

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

50

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!

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.

···

--
Giles Bowkett
http://www.gilesgoatboy.org

51

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

···

--
Giles Bowkett
http://www.gilesgoatboy.org

52

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 :slight_smile: 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>:

···

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.

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

53

there seems to be less and less need to solve the low-level problems. They're done.

Or maybe not!

m.s.

54

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

···

On 6/12/06, Keith Fahlgren <keith@oreilly.com> wrote:

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.

55

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

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! :slight_smile:

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

···

--
Posted via http://www.ruby-forum.com/.

56

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 :wink:

···

On Jun 12, 2006, at 8:25 AM, Matthew Smillie wrote:

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

57

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

···

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.

58

Matthew Smillie <M.B.Smillie@sms.ed.ac.uk> writes:

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?

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.

···

On Jun 12, 2006, at 12:42, Christian Neukirchen wrote:

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

59

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 :slight_smile:

···

James Britt

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

60

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

···

On 6/12/06, James Britt <james.britt@gmail.com> wrote:

--
Lou.