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

I agree with both of you. I think Chris’s tutorial should introduce IRB
somewhere, just not right at the beginning. And Daniel’s tutorial should
introduce it right up-front because it seems to be aiming at a slightly more
knowledgeable audience.

And then we can soak in tutorial goodness!

Whatever the considerations about teaching IRB to nubies, the fact can’t be
avoided that the answers to most of life’s questions are found in IRB, so
nubies should be made to understand that. But it doesn’t hurt for them to be
taught a few important things beforehand!

Gavin

···

----- Original Message -----
From: “Bill Kelly” billk@cts.com

[excellent points for and against teaching IRB up-front]

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.

···

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

Well, you’d be agree with him, then, because Daniel’s the one who said that!
My argument was two-fold:

  1. With single-quotes, there is less chance that you’ll accidentally stumble
    upon an escape sequence, especially since kids are going to want to bang on
    the keyboard and print snoopy swearing.

  2. Why teach someone “2 + 2 = #{2 + 2}” when they can already build things
    like:

print '2 + 2 = ’ + (2+2).to_s?
print '2 + 2 = ', 2+2

In any case, new students (and even the rest of us) in practice tend to do
this more with strings, so:

print 'Hello, ’ + name + ‘! How are you?’

This is enforcing ideas like “Strings can be added” (which they already know
by the time they are doing variable substitution), rather than adding new
(unnecessary) complexities, like ‘variable substitution’. Really, I have
avoided variable substitution altogether, replacing it with something they
already know: string concatenation. In fact, I don’t plan ever to teach
them this pseudo-variable-substitution; they’ll figure it out on their own.

Variable substitution often messes up the syntax coloring, too. Not
everyone uses vim!

My personal feelings about variable substitution was that I put off learning
it until I really had to, and I still almost never use it, in favor of
string concatenation. I just don’t see the point. As my wife (who doesn’t
program) was reading the pickaxe, she came upon the part describing variable
substitution and at first didn’t get it. When she did, the first thing she
said was “Why do they have this?” Her first assumption was that this was
something she didn’t already know, and didn’t see what it was. When I
didn’t have a good reason justifying variable substitution (at least in
terms of what she already knew), she let out a disdainful “Hmmph!” and moved
on; clearly, she wasn’t going to waste any time on another way to do
something she already.

My 2 cents, anyway.

While I don’t think Daniel is focussing on children as his target audience
(but I could be wrong?), that is precisely who I am thinking about (despite
the obvious irony of using my wife as an example… she does work with kids
all day…).

:slight_smile:

Chris

“Bill Kelly” wrote:

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

Hmm. FreeRIDE beat me to the critical mass there (and to rather epic
BDUF in my exalted opinion).

The point of a Ruby-on-Ruby editor would be to beat Squeak at its own
game - editing itself within itself using itself, on the fly.

My own work is proceding quietly, in my >copious< spare time.

···


Phlip
greencheese.org
– Randroids teased. $4.95 each. Group rates avail. –

OK, I’m messing around with hashes for the first time,
and I’ve hit a (very) small bump.

Let’s say I have a an array where each line contains
key=value. Also, assume that there can be duplicate
keys and if so, the final ‘value’ should be an array.

In theory, I’d like to ‘each’ through the array and
fill the hash like this…

foo = Hash.new
data.each {|line|
line =~ /^(.)=(.)$/
key, value = $1.split, $2.split # so far, so good

foo[key].push(value)
}

Now, there are two problems with this.

(1) << (or .push) doesn’t change the array… I have
to do foo[key] = foo[key].push(value). This is ok,
but wouldn’t it make sense to have <<= or .push!
methods? But this is completeness stuff and obviously
not a priority for Matz.

(2) << (or .push) doesn’t know what to do if foo[key]
is nil (since it doesn’t know it’s of type Array). No
problem, I think to myself… I’ll just declare foo as
foo=Hash.new([]). Of course, this doesn’t work since
now, ALL keys point to the SAME array… if I modify
one, I modify all of them…doh! I know I COULD do a
check to see if the value is nil or not, but that gets
a little messy. I guess what would be nice is if I
could specify that this is a Hash of Arrays (or
whatever) during instantiation without the defining of
a default value… something like foo=Hash.new(Array).

Anyone have a better solution?

Jason

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.

···

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

I couldn’t agree with your more. All of the code I have actually put in my
tutorial (of which that was not a part) has been tested. I’m even testing
the one-liners, because no matter how clever I may deem myself, I am
fallible.

Actually, I already caught one really dumb typo that way, so it’s a proven
success!

(Eventually, though, I would like to automate the process, just in case I
forget to test some code somewhere.)

Chris

while true

end

is a progamming idiom.

loop do

end

is quite a natural expression.
[snip]

···

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

Yes, if it’s ‘while true’. However:

while (number < 400)
puts 'Still too small…'
number = number * 2
end

…seems almost like english. “While the number is less than 400, write out
’Still too small…’, and then…”

When would you ever use the phrase ‘loop do’ in a sentence? Maybe ‘loop
doing’, or ‘In the loop, do…’

Even so, I really want to avoid the ‘do’ until after blocks have been
well-explained. That bit me time and time again. Am I the only one this
happened to?

If so, then I will think about it some more… no promises, though. :slight_smile:

Chris

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,
^^^^
:open_mouth:

this was a great source of frustration for him. I found myself missing
a shell like Python’s.

[…]

The brain-dead ruby “shell” I created would indent code as it was being
typed, auto-complete variable and method names, and was so stupid it’d
be easy to modify. It could, for example, be tailored to give meaningful
(to the beginner) error messages.

···

On Thu, Dec 05, 2002 at 06:57:30AM +0900, Daniel Carrera wrote:


_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |
__ \ | | | | | (| | | | |
.__/ _,
|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Those who don’t understand Linux are doomed to reinvent it, poorly.
– unidentified source

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.

How do you like that? I gotcha all hooked up now.

I guess it’s a matter of taste, but I don’t like it.

Daniel.

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

···

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

For the most part, I agree… but a student won’t be doing one-liners for
very long. Why switch from one way of doing things to another so soon?
Again, I just think it would be confusing. It goes against my DRY rule of
tutorials: “One thing is easier to learn than two.”

On the other hand, it is my rule, and not yours! :slight_smile: Perhaps we just see
this issue differently.


Also, I took Chris’ suggestion and dropped the terms ‘Fixnum’ and ‘Float’ in
the first chapters.

Oh, no! I must not have explained myself very well!

I don’t think there’s anything wrong with calling them floats and integers
right away (though I would avoid Fixnum and Bignum until you really
introduce classes in depth). Same with strings. You have to call them
something, so go ahead and call them by their real names. If you call
stuff ‘text’ in one chapter, then switch to ‘string’ in the next, I think
you are more likely to confuse the nuby.

What I was trying (and failing) to say was that talking about the String
CLASS or String OBJECTS was a bad idea (so early). Just call them strings.

I was thinking of something along these lines:

“In most computer languages (and Ruby is no exception) numbers without
decimal points are called ‘integers’, and numbers with decimal points are
usually called ‘floating-point numbers’, or more simply, ‘floats’. It is
also customary to refer to a chunk of text as ‘strings’.” (Then give some
simple and some extreme examples of each.)

Hope that makes more sense,

Chris

Let me say that Chris has taken me on as a distance “student” to work out
some of the details (I know nada programming basically). I can tell you a
lot from a students perspective as some of these issues iron out.

A few tutorial additions/etc:
A tutor is most helpful. Self pacing is great, but when you don’t even know
what the pool looks like it’s hard to jump in. The first advice I got was
write a game. I don’t know how to write anything more complex than “hello,
world.” I don’t fault the person who said this, they just didn’t know where
I was, and probably didn’t want to get messily involved in my skinned
programming knees.

Advise people to right away try to grab pickaxe from amazon or half.com
used. I have it winging its way here for $10 US.

irb is 50/50… I think I would rather go with an editor or ide upfront
(I’m a sysadmin, used to nanoing things all day). I think that a lot of
people are used to word processors etc, where they can see the whole. Just
my thoughts there.

If you want me to address specific things as this thread goes on, email me
directly, or just throw my name in there with a Hey, what do you think? I
may be wrong, but at least I can help you all remember how a nuby feels
about things.

Jason

···

----- Original Message -----
From: “Gavin Sinclair” gsinclair@soyabean.com.au
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, December 04, 2002 9:19 PM
Subject: Re: Ruby Book for People Who Aren’t (Yet) Programmers

----- Original Message -----
From: “Bill Kelly” billk@cts.com

[excellent points for and against teaching IRB up-front]

I agree with both of you. I think Chris’s tutorial should introduce IRB
somewhere, just not right at the beginning. And Daniel’s tutorial should
introduce it right up-front because it seems to be aiming at a slightly
more
knowledgeable audience.

And then we can soak in tutorial goodness!

Whatever the considerations about teaching IRB to nubies, the fact can’t
be
avoided that the answers to most of life’s questions are found in IRB, so
nubies should be made to understand that. But it doesn’t hurt for them to
be
taught a few important things beforehand!

Gavin


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002

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.

True.

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?

Yes, that makes sense. My real comment was to do with the multi-line scripts.
I think it’s a pain doing that stuff in irb … but, of course, I’ve been
using the same editor (vi, now vim) for 25 years, so keeping things in files
is second-nature, whereas I see your point that it is yet another thing to
learn for a newbie.

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?

That sounds good to me. The “right” terms are just more things for them to
learn. Keeping away from that stuff until they gain a little confidence is
probably a good idea.

H.

I hate to say this but the Windows irb (at least the one packaged with
the PragProg installer) is awesome for multi-liners.

I realised that was probably the case, about five seconds after I pressed the
“send” button :-).

This is one place where Windows has it all over Linux … although, there’s no
reason someone couldn’t port rubyw (?) to Linux, to provide the same nice
learning environment.

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.

Ah, so it’s not as nice as I’d imagined. I figured you’d be able to just type
in a window, highlight some code and press a button to execute it. Hence,
fixing typos would be just a matter of editing what’s in the window.

Mind you, in that case, it wouldn’t be much different from using a real
editor, except for the ease of execution. I seem to recall someone wote some
macros to execute Ruby code in vim … but then, teaching someone vim AND
ruby would be twice the challenge, so best avoided, really !!

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.

Not me, I’m afraid :-). Give me a real editor any day.

After all, that’s the point of having multiple windows in a windowing system,
isn’t it? I can have an editor open on a “play” script in one window and a
shell where I can just go “!!” to run it again after I’ve hacked a bit more
in another window.

Actually, I was thinking to myself the other day, I wonder whether anyone has
written a library to allow you to hook gvim into a window of a GUI? I’d love
to use one of these nice IDE thingies, but just can’t be bothered learning
another editor.

But, I digress …

H.

I agree with both of you. I think Chris’s tutorial should introduce IRB
somewhere, just not right at the beginning. And Daniel’s tutorial should
introduce it right up-front because it seems to be aiming at a slightly
more knowledgeable audience.

This is probably highly impractical, but perhaps before either turorial goes
much further, it might be worthwhile doing a small experiment, if you can
find enough people to teach a little Ruby to.

Start out with irb with a couple of them and with some kind of editor + shell
with another couple. See which one makes them feel more comfortable.

And then we can soak in tutorial goodness!

Yes, I’m getting a really nice feeling from this thread.

H.

···

On Thu, 5 Dec 2002 13:19, Gavin Sinclair wrote:

My personal feelings about variable substitution was that I put off learning
it until I really had to, and I still almost never use it, in favor of
string concatenation. I just don’t see the point. […]

My 2 cents, anyway.

I must say, I find this opinion absolutely amazing. I am being forced to code
Java at work at the moment, and of course there are many things I hate about
it. Somewhere near the top is the lack of variable substitution. I suppose if
Vim couldn’t handle the highlighting, it would be off-putting.

Anyway, my two cents only buys one of your cents so I’m off now :slight_smile:

Gavin

···

From: “Chris Pine” nemo@hellotree.com

Hi –

···

On Fri, 6 Dec 2002, Phlip wrote:

“Bill Kelly” wrote:

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

Hmm. FreeRIDE beat me to the critical mass there (and to rather epic
BDUF in my exalted opinion).

What is BDUF? Is it good? :slight_smile:

David


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

Hi –

OK, I’m messing around with hashes for the first time,
and I’ve hit a (very) small bump.

Let’s say I have a an array where each line contains
key=value. Also, assume that there can be duplicate
keys and if so, the final ‘value’ should be an array.

In theory, I’d like to ‘each’ through the array and
fill the hash like this…

foo = Hash.new
data.each {|line|
line =~ /^(.)=(.)$/
key, value = $1.split, $2.split # so far, so good

foo[key].push(value)
}

Now, there are two problems with this.

(1) << (or .push) doesn’t change the array… I have
to do foo[key] = foo[key].push(value). This is ok,
but wouldn’t it make sense to have <<= or .push!
methods? But this is completeness stuff and obviously
not a priority for Matz.

<< and push do change the array. If they don’t seem to, then
something else is wrong. A method called push! would make no sense,
since push already modifies the receiver, and the ! is a clue that
this is a method which modifies the receiver in a case where there’s a
!-less version that doesn’t.

(2) << (or .push) doesn’t know what to do if foo[key]
is nil (since it doesn’t know it’s of type Array). No

Yes, they do know what to do: raise an exception :slight_smile: Or,
more precisely, an object that doesn’t respond to << or
push knows to raise an exception.

problem, I think to myself… I’ll just declare foo as
foo=Hash.new(). Of course, this doesn’t work since
now, ALL keys point to the SAME array… if I modify

I think there’s a capacity in 1.7.x to create a hash with
a default proc that gets called each time, instead of a
static default. (I can never seem to remember the status
of that, but I think it’s there, or coming.)

one, I modify all of them…doh! I know I COULD do a
check to see if the value is nil or not, but that gets
a little messy. I guess what would be nice is if I
could specify that this is a Hash of Arrays (or
whatever) during instantiation without the defining of
a default value… something like foo=Hash.new(Array).

Anyone have a better solution?

This might be useable or give you some ideas (in the absence of the
dynamic hash default mentioned above):

data = <<EOS
one=un
one=eins
two=deux
two=zwei
two=due
three=trois
EOS

h = Hash.new
data.each do |line|
k,v = line.split(/=/)
h[k] ||= Array.new
h[k].push(v)
end

p h # nice hash of all those things :slight_smile:

The key here is:

h[k] ||= Array.new

which basically means: if h[k] is nil, assign a new array to
it. If it isn’t nil, leave it alone.

You could even combine the last two lines into:

(h[k] ||= Array.new).push(v)

which is actually a fairly common idiom.

David

···

On Fri, 6 Dec 2002, Jason Persampieri wrote:


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

OK, I’m messing around with hashes for the first time,
and I’ve hit a (very) small bump.

Let’s say I have a an array where each line contains
key=value. Also, assume that there can be duplicate
keys and if so, the final ‘value’ should be an array.

In theory, I’d like to ‘each’ through the array and
fill the hash like this…

foo = Hash.new
data.each {|line|
line =~ /^(.)=(.)$/
key, value = $1.split, $2.split # so far, so good

foo[key].push(value)
}

Now, there are two problems with this.

(1) << (or .push) doesn’t change the array… I have

Array#push and Array#<< DO change the receiver.

a = [1, 2, 3]
a.size ==> 3
a.push(4) ==> [1, 2, 3, 4]
a.size ==> 4
a.push([5,6] ==> [1, 2, 3, 4, [5, 6]]
a.size ==> 5

to do foo[key] = foo[key].push(value). This is ok,
but wouldn’t it make sense to have <<= or .push!
methods? But this is completeness stuff and obviously
not a priority for Matz.

(2) << (or .push) doesn’t know what to do if foo[key]
is nil (since it doesn’t know it’s of type Array). No
problem, I think to myself… I’ll just declare foo as
foo=Hash.new(). Of course, this doesn’t work since

(foo[key] ||= ).push(value)

···

----- Original Message -----
From: “Jason Persampieri” jason@persampieri.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, December 05, 2002 2:42 PM
Subject: Hash ‘issues’

now, ALL keys point to the SAME array… if I modify
one, I modify all of them…doh! I know I COULD do a
check to see if the value is nil or not, but that gets
a little messy. I guess what would be nice is if I
could specify that this is a Hash of Arrays (or
whatever) during instantiation without the defining of
a default value… something like foo=Hash.new(Array).

Anyone have a better solution?

Jason

(Eventually, though, I would like to automate the process, just in case I
forget to test some code somewhere.)

Yes, it should be possible to parse out all the pieces of code from the HTML
and write some unit tests for them.

I note that currently the code is inside

 tags.  I’m no HTML guru, but I
would have thought that there may be other
 tags in your document (now,
or in the future), so maybe would make more sense, to guarantee that
the pieces you pull out are actually source code … assuming you go with the
idea of parsing the scripts from the HTML, that is.

Since you’re using CSS, I don’t believe there’s anything stopping you from
making look precisely as you currently have your

 looking in the
browser.

Just a thought.

Of course, all these comments may be pointless, if you’re actually writing the
tutorial in something else and converting to HTML. But, in that, case you
presumably have a similar way to do the same thing.

H.

Hi,

···

At Fri, 6 Dec 2002 07:42:32 +0900, Jason Persampieri wrote:

(1) << (or .push) doesn’t change the array… I have
to do foo[key] = foo[key].push(value). This is ok,
but wouldn’t it make sense to have <<= or .push!
methods? But this is completeness stuff and obviously
not a priority for Matz.

foo[key]<<=value' works as foo[key]=foo[key]<<value’.

foo = Hash.new {} # 1.7 feature
data.each {|line|
line =~ /^(.?)=(.)$/
foo[$1.strip] <<= $2.strip
}


Nobu Nakada

Even so, I really want to avoid the ‘do’ until after blocks have been
well-explained. That bit me time and time again. Am I the only one this
happened to?

Yes, you are, but that doesn’t mean you shouldn’t still prevent it from
happening to others :slight_smile: Keep up the good work.

Cheers,
Gavin

···

From: “Chris Pine” nemo@hellotree.com