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

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" <[e-mail]>
> > ----- 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.  :)
>
> Well... yeahbut.  :)  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
>
>
>
>
>
>