Ruby Book for People Who Aren't (Yet) Programmers

Hi –

···

On Thu, 5 Dec 2002, Chris Pine wrote:

Here’s what I consider to be one of the last programs before variables are
introduced, and it uses a different kind of loop:

puts ‘Type something, will ya? Then press “Enter”.’

while (true)
if (gets == ‘quit’)
break
else
puts ‘Type “quit” to quit!’
end
end

puts ‘Very good! Good-bye.’

So… thoughts?

gets == ‘quit’ won’t happen, because the string will be ‘quit\n’ :slight_smile:

David


David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

Try

irb --simple-prompt

···

----- Original Message -----

Huh! Learn something new every day…

Well, that is much nicer, I must admit. Still, I had other complaints about
irb (as a learning tool, mind you), too. Teaching people Ruby with irb is
using the right tool for the wrong job, IMHO. :slight_smile:

Chris

Alright, concensus seems to be irb is not the best option. I’ll start
changing what I have. You can look at my progress:

http://www.math.umd.edu/~dcarrera/ruby/0.1/

If you notice, I mentioned String, Float and Integer right away. (No
Fixnum, because then you should really explain Bignum, too, and really
those are just implementation for Integer, anyway… plus, it sounds
really complicated: Fixnum??)

Yeah. I don’t really know what to do. When students type ‘3.class’ they
are going to get ‘Fixnum’, not ‘Integer’.

I don’t see why we have to explain Bignum at all. I really don’t.

For now, I’ve replaced both ‘Fixnum’ and ‘Float’ by ‘integer’ and
‘decimal’. Take a look at it.

No, here’s a great loop (which I put in my last post, too)

5.times do
print 'Hello, everyone! ’
end

Good idea. I’ll use that instead, and delay variables for later.

Daniel.

Did you do multi-line statements in BASIC interactively? Like loops?
How did it turn out?

Did you find it frustrating when you made a typo?

···

Hi,

From: “Chris Pine” nemo@hellotree.com

[…]

Finally, I remember when I was learning Ruby. Simple text files were easy
to understand. I found irb confusing until I understood basic programming
in Ruby. Plain and simple. I doubt if anyone learned on irb first, and I
imagine most people found it harder to understand when they were nubies.

I learned on IRB first… If it hadn’t existed I would have written it.
(A simplified version, albeit. :slight_smile: … It’s somewhat baffling to me
why, in learning a language, one would deliberately eschew something so
interactive that gives such immediate feedback like IRB.

I started out in BASIC (in 1980), and it was interactive. My next
language was Forth… highly interactive. From there onto C and C++,
and I was thoroughly irked by the lack of an interactive development
environment (profoundly different from a source level debugger.)
When I got to Perl, I was ecstatic, 'cause one of the first things I
realized I could write was:

perl -e “while(<>){$=eval;print qq’ => $ $@\n’}”

… which is like a mini “IRB” for Perl… Essentially the Ruby
equivalent of:

ruby -e “while gets; puts eval $_; end”

Then on to Smalltalk, where I was again in heaven with the interactive
development capabilities (kind of squared, in smalltalk :slight_smile:

Finally on to Ruby, where it’s prolly not too surprising how thrilled
I was to find IRB waiting for me…

So… I’m wondering if some of the disagreement (just jumping into
this thread here :slight_smile: might be somehow associated with personal
preference? Because as a beginner, in BASIC and Forth, I found the
interactivity of those languages highly appealing in learning to
program, and learning the language… Almost as appealing
[and indespensible] as I find IRB now.

So if I can presume some “nubys” out there think and experiment and
learn the way I do, I’d imagine IRB would be perfect for them as a
learning tool (perhaps, as has been noted, with --simple-prompt :).
…But, I don’t know what percentage of total nubys these people
represent.

Just pitchin in the $0.02…

Regards,

Bill

[snip]

So if I can presume some “nubys” out there think and experiment and
learn the way I do, I’d imagine IRB would be perfect for them as a
learning tool (perhaps, as has been noted, with --simple-prompt :).
…But, I don’t know what percentage of total nubys these people
represent.

···

----- Original Message -----

An important point to note: when I said ‘nuby’, I was referring to people
who were both new to Ruby, and new to programming in general. (see topic of
this thread)

Ruby being your 4th or 5th (or more?) language, I just don’t think you
apply! You definitely aren’t my target audience… I’m afraid you’re
over-qualified for the position, sir. :slight_smile:

In fairness, Ruby wasn’t my first language, either. I am basing this more
on my experiences teaching Ruby. As I said, confidence is a huge part of
successful learning, and understanding everything that’s going on is a huge
part of confidence. (I doubt either you or myself had any trouble with
confidence when learning Ruby.)

Chris

A little bit off-topic. Does anybody know how to activate vi editing
mode for readline in irb? I created file ~/.inputrc and put there:

set editing-mode vi

Does not help. Any suggestions?

Thanks in advance,
Gennady.

···

On Wednesday, Dec 4, 2002, at 18:12 US/Pacific, Eric Schwartz wrote:

Nikodemus Siivola tsiivola@cc.hut.fi writes:

[…]
irb uses readline, which means if you typo, you can just go back and
correct it, instead of typing it all in again from scratch. That’s

Why not use loop do … end? I find it more natural than while(true) …

···

----- Original Message -----

Yeah, I thought about that. I decided against it because I wanted to put
off ‘do’ for as long as possible. I remember getting confused when code
like this didn’t work:

if (foo < 5) do
puts 'foo is relatively small.'
end

I understand now why it doesn’t work, but until I really explain blocks, I
want to avoid using them.

Chris

gets == ‘quit’ won’t happen, because the string will be ‘quit\n’ :slight_smile:

···

----- Original Message -----

D’oh!

True enough. Well, I think I’m going to introduce variables and assignment
sooner than I was originally planning on, anyway.

Chris

Try

irb --simple-prompt

Huh! Learn something new every day…

Same here. One of these days, I’ll remember to try “xxx --help” before even
starting to use something :-).

Well, that is much nicer, I must admit. Still, I had other complaints
about irb (as a learning tool, mind you), too. Teaching people Ruby with
irb is using the right tool for the wrong job, IMHO. :slight_smile:

The biggest problem I see with using irb for this kind of learning scenario,
especially with a newbie, is that they’re likely to make a lot of mistakes
(some typos, some due to lack of understanding) and they’re going to want to
edit their code a lot.

That’s not so easy to do with something like irb … as far as I know. Sure,
you can go back through the history, but for a multi-liner like

5.times do
puts “Hello”
end

(or something bigger, like a class definition, in which you’re almost
guaranteed to make a couple of typos), being able to get back to the top
doesn’t help much, if you have to re-type everything else.

The other thing is that the student would probably find it useful to keep some
of their old scripts. Again, maybe irb has a way to save the contents of the
current session; I haven’t looked.

Just my AUD 0.02 worth :-).

Harry O.

···

On Thu, 5 Dec 2002 06:38, Chris Pine wrote:

----- Original Message -----

I think it will be difficult to reach a consensus on every issue. But
I also think that a consensus doesn’t have to be reached. irb could be
introduced for the learner to play with as they wish, and teaching
material using irb, and saved programs, could be presented for the
learner (or the teacher) to choose from. What works should emerge from
practice.

···

On Wednesday, December 4, 2002, at 05:22 PM, Daniel Carrera wrote:

Alright, concensus seems to be irb is not the best option. I’ll start
changing what I have. You can look at my progress:

http://www.math.umd.edu/~dcarrera/ruby/0.1/

If you notice, I mentioned String, Float and Integer right away.
(No
Fixnum, because then you should really explain Bignum, too, and really
those are just implementation for Integer, anyway… plus, it sounds
really complicated: Fixnum??)

Yeah. I don’t really know what to do. When students type ‘3.class’
they
are going to get ‘Fixnum’, not ‘Integer’.

I don’t see why we have to explain Bignum at all. I really don’t.

For now, I’ve replaced both ‘Fixnum’ and ‘Float’ by ‘integer’ and
‘decimal’. Take a look at it.

No, here’s a great loop (which I put in my last post, too)

5.times do
print 'Hello, everyone! ’
end

Good idea. I’ll use that instead, and delay variables for later.

Daniel.

I started out in BASIC (in 1980), and it was interactive. My next
language was Forth… highly interactive.

Did you do multi-line statements in BASIC interactively? Like loops?

Well, yes… but in BASIC one could not only enter statements to
be executed immediately-interactively, but by preceding the statement
with a line number could enter it in as a line of the program…

So,

print “hello world”

didn’t feel too much different from

10 print “hello world”
20 goto 10

:slight_smile:

How did it turn out?
Did you find it frustrating when you made a typo?

Not particularly… but then, I believe one could type “EDIT”
and have an interface for scrolling through and editing the
source code. So, when my programs (quickly) became large enough
to need the features of the editor, I still enjoyed being able to
leave the editor and type ‘immediate’ statements into the
interpreter for interactive evaluation… and then back into the
editor. (Much as I do now between an editor and IRB… :slight_smile:

Forth was rather similar, now that I think about it, in terms of
having a built-in editor. (But, I could name my subroutines! :wink:

Perhaps some sort of Ruby editor with a built-in IRB would be
ideal… (Actually I seem to recall Phlip announcing something
like that many moons ago… Yes- RuEdit in [ruby-talk:22766]…
Hmm in this case the editor’s built-in macro language is Ruby…)

Any Ruby editors out there that let you try out/evaluate snippets
of source code, IRB-style, without leaving the editor? Just
curious…

Regards,

Bill

···

From: “Daniel Carrera” dcarrera@math.umd.edu

Daniel Carrera wrote:

Did you do multi-line statements in BASIC interactively? Like loops?
How did it turn out?

Did you find it frustrating when you made a typo?

I like irb but I do sometimes feel frustrated when this happens. But
it’s not an inherent problem with interactive shells. Take zsh for
example. If you type a multiline statement (e.g., a function def), you
can later edit the whole multiline statement. You get all the usual
command line editing bindings, plus up and down arrow for changing lines
(when you get to the top or bottom, the arrows take on their more
familiar history-scrolling function). IMO, irb would be much more
valuable with this feature.

[snip]

So if I can presume some “nubys” out there think and experiment and
learn the way I do, I’d imagine IRB would be perfect for them as a
learning tool (perhaps, as has been noted, with --simple-prompt :).
…But, I don’t know what percentage of total nubys these people
represent.

An important point to note: when I said ‘nuby’, I was referring to people
who were both new to Ruby, and new to programming in general. (see topic of
this thread)

Ruby being your 4th or 5th (or more?) language, I just don’t think you
apply! You definitely aren’t my target audience… I’m afraid you’re
over-qualified for the position, sir. :slight_smile:

Well… yeahbut. :slight_smile: I was trying to focus on my 1st two languages
being of the interactive variety. I’ve long held the belief (or, at
least, strong suspicion) that programmers who don’t begin programming
in an interactive language, rarely seem to fully realize how many of
their questions can be answered while coding, just by “asking the
language”… because it’s 'way too much trouble to write little programs
to ask the question in a non-interactive language… And those habits,
from what I’ve seen, seem to be fairly tenacious…

In fairness, Ruby wasn’t my first language, either. I am basing this more
on my experiences teaching Ruby. As I said, confidence is a huge part of
successful learning, and understanding everything that’s going on is a huge
part of confidence. (I doubt either you or myself had any trouble with
confidence when learning Ruby.)

For the past couple weeks, off and on, I’ve been helping someone
learn Ruby, who is a novice programmer who a year or so ago had
taught herself enough Perl to write a 3000-odd line program, which
she doesn’t understand anymore… I’ve also been helping her with
some new Perl code she’s been writing. In both cases, Perl and
Ruby–she’s receptive to ideas such as coding unit tests first,
but the transition has so far been gradual–rather; she tends to
get stuck thinking she needs to test her whole program manually,
after having added some new lines of code to it. Well, the program
makes a socket connection and connects to a chat-like server and
acts as a little “bot” to auto-respond to people or various
transpiring events. The point is: I think, because she hasn’t
learned the utility of being able to treat an interactive language
interpreter as a sort of “Oracle” to which one can make inquiries
about whether the code one wants to write is correct, she thinks
she needs to add/modify her parser in the context of her whole
program, adding some new regexp that she (understandably) might
have some trouble arriving at the correct syntax - and the only
way she thinks she can test it is to run the whole program and
log it onto the chat room and try to have someone generate the
appropriate circumstances to get her regexp to trigger… and
then it doesn’t work. . . . . And I’ve been encouraging her to
leave an IRB window open, and hoping to persuade her it might
be worthwhile to test out her regexp syntax (for example) there
in IRB, since she can get so much more instant feedback about
whether it even works… And yet this interactive capability is
such a foreign concept to her that she regularly spends hours
sometimes (we correspond largely by email) testing her not-
correct code in the cumbersome context of running her entire
program. Something that she could have just tried in IRB and
seen didn’t work instantly.

So my point is that experiences such as these (not just with
beginners - professional college-educated programmer newbies
will often spin their wheels similarly) has suggested to me
that not starting programmers out in an interactive language
environment as beginners can do them a disservice by instilling
habits that are biased toward trial-and-error solutions, and
spending more time in the debugger. And for some reason, these
habits have consistently seemed difficult to un-teach…

Thus my bent towards preferring an interactive environment for
beginners…

Regards,

Bill

···

From: “Chris Pine” nemo@hellotree.com

----- Original Message -----

Nikodemus Siivola tsiivola@cc.hut.fi writes:

[…]
irb uses readline, which means if you typo, you can just go back and
correct it, instead of typing it all in again from scratch. That’s

A little bit off-topic. Does anybody know how to activate vi editing
mode for readline in irb? I created file ~/.inputrc and put there:

set editing-mode vi

Does not help. Any suggestions?

Oops, sorry. I found it – variable INPUTRC should point to the file.

···

On Wednesday, Dec 4, 2002, at 23:42 US/Pacific, Gennady Bystritsky wrote:

On Wednesday, Dec 4, 2002, at 18:12 US/Pacific, Eric Schwartz wrote:

Thanks in advance,
Gennady.

Alright, concensus seems to be irb is not the best option. I’ll start
changing what I have. You can look at my progress:

http://www.math.umd.edu/~dcarrera/ruby/0.1/

Looks great! My first comment, though, is that you need some links for next,
previous, back-to-contents.

By the way, I notice in your chapter on strings, you are using single quotes.
I’d have to agree with whomever it was earlier who suggested it might be a
good idea to start with double quotes, so you don’t have to explain “you can
also use double quotes …” when you want to do things like “2 + 2 = #{2 +
2}” later on.

For now, I’ve replaced both ‘Fixnum’ and ‘Float’ by ‘integer’ and
‘decimal’. Take a look at it.

Personally, I like “integer”, but my memory doesn’t go back far enough to
reach my schooldays … I think they tend to say “whole number”, rather than
“integer”. If I recall, I learned the terms integer, natural number, real
etc. in first year university.

I realise you’re not aiming this directly at kiddies, but it might be worth
checking into this kind of vocabulary if you want to make it easy for kids to
use the tutorial.

H.

···

On Thu, 5 Dec 2002 09:22, Daniel Carrera wrote:

This brings up a very important point … it really goes without saying that
every piece of code in the tutorial should be tested, running code.

There’s nothing more frustrating to a newbie (or even a seasoned programmer,
trying to learn something new) than typing something in, having it fail and
not knowing whether they’ve made a mistake or whether it’s a typo in the
documentation.

H.

···

On Fri, 6 Dec 2002 05:42, Chris Pine wrote:

----- Original Message -----
gets == ‘quit’ won’t happen, because the string will be ‘quit\n’ :slight_smile:

D’oh!

Why not use loop do … end? I find it more natural than while(true) …

Yeah, I thought about that. I decided against it because I wanted to put
off ‘do’ for as long as possible. I remember getting confused when code
like this didn’t work:

if (foo < 5) do
puts ‘foo is relatively small.’
end

I understand now why it doesn’t work, but until I really explain blocks, I
want to avoid using them.

Chris

That reasoning seems a bit far-fetched to me (even though it’s based on your
experience :).

while true

end

is a progamming idiom.

loop do

end

is quite a natural expression. The student needn’t be told it’s a block. As
you do with objects, methods, etc., they can be introduced to blocks without
knowing it.

Gavin

···

From: “Chris Pine” nemo@hellotree.com

----- Original Message -----

The biggest problem I see with using irb for this kind of learning scenario,
especially with a newbie, is that they’re likely to make a lot of mistakes
(some typos, some due to lack of understanding) and they’re going to want to
edit their code a lot.

But that’s precisely one of the reasons why I think irb is good.
Getting the student to write things on a file has two downsides:

  1. More things they can do wrong.
  2. Takes longer to realize and correct their mistakes.

This might sound silly, but when I tried to teach my little brother Perl,
this was a great source of frustration for him. I found myself missing
a shell like Python’s.

As long as the student is doing one-liners, there is no downside to irb.

Perhaps we should start using files as soon as we start multiple-line
statements.

Does that sound like a good idea?

Also, I took Chris’ suggestion and dropped the terms ‘Fixnum’ and ‘Float’
in the first chapters. Here is my plan:

Chapter 1: Discuss numbers. Call them integers and decimals.
Chapter 2: Discuss text. Introduce the term string, but keep saying
‘text’.
Chapter 3: Title: “New names for old thins”.
Just a brief chapter to say that Ruby uses the names ‘Fixnum’,
‘Float’ and ‘String’ for integers, decimals and text. And
it uses the word ‘method’ for the things that each can do.
Mention the methods the’ve already seen.

Thoughts?

Daniel.

I hate to say this but the Windows irb (at least the one packaged with
the PragProg installer) is awesome for multi-liners. If you go back in
the history and select a line, then the next line’s history will begin
at the selected line. Make sense? If not, try this:

o Run irb from Windows cmd.
o Type in your three lines of code.

  5.times do
     puts "Hello"
  end

o Now, punch the up arrow three times to display the line ‘5.times do’
on your irb console.
o Hit enter.
o Now, press down. What line appears?
o Hit enter.
o Press down again. Hit enter.

Hello
Hello
Hello
Hello
Hello

How do you like that? I gotcha all hooked up now. I haven’t looked
into how it works, but I often long for it on my primary platforms. Wo
is me.

_why

···

Harry Ohlsen (harryo@zip.com.au) wrote:

That’s not so easy to do with something like irb … as far as I know. Sure,
you can go back through the history, but for a multi-liner like

5.times do
puts “Hello”
end

(or something bigger, like a class definition, in which you’re almost
guaranteed to make a couple of typos), being able to get back to the top
doesn’t help much, if you have to re-type everything else.

You make several good points Bill.
I also learned first on an iteractive languge - Logo - and then moved on
to Basic. Then I learned Turing (it’s a rip-off of Pascal) which I
think also had an interactive shell.

Your points are very compelling.

Daniel.

···

On Thu, 5 Dec 2002, Bill Kelly wrote:

From: “Chris Pine” nemo@hellotree.com

----- Original Message -----
[snip]

So if I can presume some “nubys” out there think and experiment and
learn the way I do, I’d imagine IRB would be perfect for them as a
learning tool (perhaps, as has been noted, with --simple-prompt :).
…But, I don’t know what percentage of total nubys these people
represent.

An important point to note: when I said ‘nuby’, I was referring to people
who were both new to Ruby, and new to programming in general. (see topic of
this thread)

Ruby being your 4th or 5th (or more?) language, I just don’t think you
apply! You definitely aren’t my target audience… I’m afraid you’re
over-qualified for the position, sir. :slight_smile:

Well… yeahbut. :slight_smile: I was trying to focus on my 1st two languages
being of the interactive variety. I’ve long held the belief (or, at
least, strong suspicion) that programmers who don’t begin programming
in an interactive language, rarely seem to fully realize how many of
their questions can be answered while coding, just by “asking the
language”… because it’s 'way too much trouble to write little programs
to ask the question in a non-interactive language… And those habits,
from what I’ve seen, seem to be fairly tenacious…

In fairness, Ruby wasn’t my first language, either. I am basing this more
on my experiences teaching Ruby. As I said, confidence is a huge part of
successful learning, and understanding everything that’s going on is a huge
part of confidence. (I doubt either you or myself had any trouble with
confidence when learning Ruby.)

For the past couple weeks, off and on, I’ve been helping someone
learn Ruby, who is a novice programmer who a year or so ago had
taught herself enough Perl to write a 3000-odd line program, which
she doesn’t understand anymore… I’ve also been helping her with
some new Perl code she’s been writing. In both cases, Perl and
Ruby–she’s receptive to ideas such as coding unit tests first,
but the transition has so far been gradual–rather; she tends to
get stuck thinking she needs to test her whole program manually,
after having added some new lines of code to it. Well, the program
makes a socket connection and connects to a chat-like server and
acts as a little “bot” to auto-respond to people or various
transpiring events. The point is: I think, because she hasn’t
learned the utility of being able to treat an interactive language
interpreter as a sort of “Oracle” to which one can make inquiries
about whether the code one wants to write is correct, she thinks
she needs to add/modify her parser in the context of her whole
program, adding some new regexp that she (understandably) might
have some trouble arriving at the correct syntax - and the only
way she thinks she can test it is to run the whole program and
log it onto the chat room and try to have someone generate the
appropriate circumstances to get her regexp to trigger… and
then it doesn’t work. . . . . And I’ve been encouraging her to
leave an IRB window open, and hoping to persuade her it might
be worthwhile to test out her regexp syntax (for example) there
in IRB, since she can get so much more instant feedback about
whether it even works… And yet this interactive capability is
such a foreign concept to her that she regularly spends hours
sometimes (we correspond largely by email) testing her not-
correct code in the cumbersome context of running her entire
program. Something that she could have just tried in IRB and
seen didn’t work instantly.

So my point is that experiences such as these (not just with
beginners - professional college-educated programmer newbies
will often spin their wheels similarly) has suggested to me
that not starting programmers out in an interactive language
environment as beginners can do them a disservice by instilling
habits that are biased toward trial-and-error solutions, and
spending more time in the debugger. And for some reason, these
habits have consistently seemed difficult to un-teach…

Thus my bent towards preferring an interactive environment for
beginners…

Regards,

Bill