Exit method?

Ruby
1

Hello World,
I am new to programming and am writing a program in ruby that serves as
a tutorial for absolute beginners. It’s heavily reliant on if & else. I
was wondering if there is a method for exiting a program. Here is the
Context;

puts ’ If you would like to begin, press enter.’
confirm1 = gets.chomp
if confirm1 == ‘’
puts ‘OK, Lets begin!’
else
puts ‘Try pressing enter this time.’
gets.chomp
if gets.chomp == ‘’
puts ‘Press enter twice’
else
puts ‘Next time press enter ;( ’
end
end
puts ’ If you are reading this you have already downloaded’
puts ’ the interactive ruby console with the’ #…

When they don’t press enter the 2nd time, I would like to exit the
program. Thanks, Charlie

2

Charlie Ca wrote:

Hello World,
I am new to programming and am writing a program in ruby that serves as
a tutorial for absolute beginners. It’s heavily reliant on if & else. I
was wondering if there is a method for exiting a program. Here is the
Context;

puts ’ If you would like to begin, press enter.’
confirm1 = gets.chomp
if confirm1 == ‘’
puts ‘OK, Lets begin!’
else
puts ‘Try pressing enter this time.’
gets.chomp
if gets.chomp == ‘’
puts ‘Press enter twice’
else
puts ‘Next time press enter ;( ’
end
end
puts ’ If you are reading this you have already downloaded’
puts ’ the interactive ruby console with the’ #…

When they don’t press enter the 2nd time, I would like to exit the
program. Thanks, Charlie

If you need to ask the mailing list a question like this, then you are
not ready to be writing Ruby tutorials. Sorry, but that’s the way it
is.
Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

3

Marnen Laibow-Koser wrote:

If you need to ask the mailing list a question like this, then you are
not ready to be writing Ruby tutorials. Sorry, but that’s the way it
is.
Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Thanks for the encouragement. I guess I should stick to ‘Hello World’
programs.

4

On Wed, Feb 10, 2010 at 5:53 PM, Marnen Laibow-Koser [email protected]
wrote:

If you need to ask the mailing list a question like this, then you are
not ready to be writing Ruby tutorials. Sorry, but that’s the way it
is.

That’s a little harsh, although it would probably be true if the
poster was actually writing the tutorial. I thought that on first
reading too, but after I read it again I figured he meant he was
writing a program as a solution to a problem in a tutorial he’s going
through.

Anyway, Charlie, the method is simply ‘exit’. It’s a class method of
the Kernel module, so it will be invoked if you don’t specify a
receiver object.

5

Eric C. wrote:

On Wed, Feb 10, 2010 at 5:53 PM, Marnen Laibow-Koser [email protected]
wrote:

If you need to ask the mailing list a question like this, then you are
not ready to be writing Ruby tutorials. �Sorry, but that’s the way it
is.

That’s a little harsh, although it would probably be true if the
poster was actually writing the tutorial. I thought that on first
reading too, but after I read it again I figured he meant he was
writing a program as a solution to a problem in a tutorial he’s going
through.

Oh, if that’s the case, then yes, my response was uncalled-for. I did
interpret the OP’s original post as saying he was creating a tutorial.

Anyway, Charlie, the method is simply ‘exit’. It’s a class method of
the Kernel module, so it will be invoked if you don’t specify a
receiver object.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

6

2010/2/11 Marnen Laibow-Koser [email protected]:

writing a program as a solution to a problem in a tutorial he’s going
through.

Oh, if that’s the case, then yes, my response was uncalled-for. Â I did
interpret the OP’s original post as saying he was creating a tutorial.

I am not a native speaker but actually that is exactly what he wrote:
“I am […] writing a program in ruby that serves as a tutorial for
absolute beginners.”

I do agree to your statement although I found it to be harsh as well.
It’s probably your concise style of writing. :slight_smile:

Kind regards

robert

7

On Wed, 10 Feb 2010 19:02:05 -0500
Charlie Ca [email protected] wrote:

Thanks for the encouragement. I guess I should stick to ‘Hello World’
programs.

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

Well no, don’t just “stick to ‘Hello World’” programs. What Marnen means
is that if you are trying to actually create a tutorial for others to
learn Ruby from, it would be a good idea to wait until you know the
language much more intimately. That way, you won’t risk providing
incorrect information, or just bad practices in your tutorial.

In the mean time, to actually get to that level of competence in using
Ruby and programming in general, do write programs, as many as you can.
just not tutorials for Ruby just yet. :wink:

No reason to get discouraged, you’re a beginner now. You just have to
spend some time learning yourself before you can teach others. Instead
of “Hello World” programs, you should write little useful utilities, or
games, or whatever interests you, moving up towards more difficult parts
of Ruby until you have a good understanding of how to program. Also,
read other people’s code, you’ll learn a lot that way.

8

Robert K. wrote:

2010/2/11 Marnen Laibow-Koser [email protected]:

writing a program as a solution to a problem in a tutorial he’s going
through.

Oh, if that’s the case, then yes, my response was uncalled-for. Â I did
interpret the OP’s original post as saying he was creating a tutorial.

I am not a native speaker but actually that is exactly what he wrote:
“I am […] writing a program in ruby that serves as a tutorial for
absolute beginners.”

Yeah, I thought so too – und ich bin Englischmuttersprachler.

I do agree to your statement although I found it to be harsh as well.
It’s probably your concise style of writing. :slight_smile:

No, it was deliberately meant to be a bit harsh – shock tactics. :slight_smile:

Kind regards

robert

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

9

Mason K. wrote:

Harsh and shock tactics seem to be universal solutions for problems that
don’t exist.

The problem appeared to exist. Nothing is to be gained from mincing
words.

What next, sterilization of programmers who overlook a
period
in the wrong place?

No. If you miss a period, you’re probably not sterile. :smiley:

Getting the work done is rarely accomplished from a pulpit or soapbox.

“Never doubt that a small group of concerned citizens can change the
world. Indeed, it’s the only thing that ever does.” --Margaret Mead

Miss Manners would not be pleased with your “methods”.

I do not think my methods were beyond the pale of etiquette.

No Sam

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

10

On 2010-02-11, Marnen Laibow-Koser [email protected] wrote:

Mason K. wrote:

Harsh and shock tactics seem to be universal solutions for problems that
don’t exist.

The problem appeared to exist. Nothing is to be gained from mincing
words.

This is untrue.

If the goal is to cause someone’s behavior to change, politeness is
MUCH more effective than “shock tactics”.

If the goal is to hurt people while making them more convinced that
their
behavior was fine and you’re just mean, shock tactics work. If the goal
is to persuade people to appreciate your point, they don’t.

-s

11

Harsh and shock tactics seem to be universal solutions for problems that
don’t exist. What next, sterilization of programmers who overlook a
period
in the wrong place?

Getting the work done is rarely accomplished from a pulpit or soapbox.

Miss Manners would not be pleased with your “methods”.

No Sam

12

On 2010-02-11, Marnen Laibow-Koser [email protected] wrote:

“Shock tactics” was a poor choice of words on my part. I suppose I
should have said “putting things in a way that is less easy to ignore.”

It came across as more confrontational, but that is in practice easier
to ignore than you might think. It’s hard to not notice that there was
a message, but it’s easier to overlook the message.

-s

13

Seebs wrote:

On 2010-02-11, Marnen Laibow-Koser [email protected] wrote:

Mason K. wrote:

Harsh and shock tactics seem to be universal solutions for problems that
don’t exist.

The problem appeared to exist. Nothing is to be gained from mincing
words.

This is untrue.

If the goal is to cause someone’s behavior to change, politeness is
MUCH more effective than “shock tactics”.

Agreed. And I really don’t think I was impolite.

If the goal is to hurt people while making them more convinced that
their
behavior was fine and you’re just mean, shock tactics work. If the goal
is to persuade people to appreciate your point, they don’t.

“Shock tactics” was a poor choice of words on my part. I suppose I
should have said “putting things in a way that is less easy to ignore.”

-s

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

14

On 2010-02-11, Marnen Laibow-Koser [email protected] wrote:

Seebs wrote:

On 2010-02-11, Marnen Laibow-Koser [email protected] wrote:

“Shock tactics” was a poor choice of words on my part. I suppose I
should have said “putting things in a way that is less easy to ignore.”

It came across as more confrontational, but that is in practice easier
to ignore than you might think. It’s hard to not notice that there was
a message, but it’s easier to overlook the message.

OK, how would you have put it?

That’s a good question, and I don’t remember enough of the initial
context
to give an answer. I would guess I’d probably start with asking for
clarification as to whether the OP was working through an existing
tutorial
or trying to create a new tutorial.

-s

15

On Wed, Feb 10, 2010 at 5:53 PM, Marnen Laibow-Koser
[email protected]wrote:

If you need to ask the mailing list a question like this, then you are
not ready to be writing Ruby tutorials. Sorry, but that’s the way it
is.
Best,

I’m not sure that this is true. Sometimes, when the person writing the
tutorial has a very firm commanding of the subject matter, they gloss
over
the kinds of things that trip up newbies. To someone well versed in
Ruby,
exit is so obvious that they probably don’t think to address it.

I was tutoring a student at my school for “Problem Solving and
Programming
in C” (CS211, first programming course) and he was struggling with
things
like figuring out where his files were, simple syntax, understanding
prototypes, understanding that functions can’t see eachother’s data.
Things
I would not have focused on if I were writing a tutorial, things the
course
probably gave a cursory explanation to.

When you are just starting out with something, you have a steep slope
ahead
of you, and only after you climb over it will you have the foundation of
knowledge necessary to understand most of the available resources.

I’m trying to learn Clojure right now, and getting started was very
frustrating, there were things the Clojure book just says, that I needed
specific steps and examples for, but the author thought that just
telling me
to do something was enough. So I had to do a lot of work and a lot of
digging, and consider quitting several times, because the perspective of
the
author was so different from my perspective.

So I think there may be a case for tutorials for newbies by newbies,
because
the things that trip up the tutorial’s author are the kinds of things
the
author is going to emphasize, and these are much more likely to be the
kinds
of things that the readers will also be struggling with. When you don’t
know
anything, and you figure something out for the first time, you know
firsthand what the hurdles are for someone in your situation, and so if
your
readers are in that same situation, then the tutorial’s subject matter,
and
emphases are more relevant to them.

This is my hypothesis. It might be useful to have Charlie ask some of
the
people he is writing the tutorial for to use a different tutorial by
someone
with more knowledge, and see how effective each was (ie gather some
empirical data to test the hypothesis).

16

Seebs wrote:

On 2010-02-11, Marnen Laibow-Koser [email protected] wrote:

“Shock tactics” was a poor choice of words on my part. I suppose I
should have said “putting things in a way that is less easy to ignore.”

It came across as more confrontational, but that is in practice easier
to ignore than you might think. It’s hard to not notice that there was
a message, but it’s easier to overlook the message.

OK, how would you have put it?

-s

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

17

On 2010-02-11, Josh C. [email protected] wrote:

So I think there may be a case for tutorials for newbies by newbies,

The problem is that the newbies will often figure things out
incorrectly,
leading to tutorials that teach people bad habits, or superstitions, or
whatever.

That said, you raise a good point about tutorials in general – it’s
extremely
hard to write a good introductory text for something you know extremely
well.

Tragically, as of yet, it has proven impossible for anyone to try
showing a
document to prospective readers to ask for feedback, but we hope that
some
day this technology will be developed and it will be possible to improve
documents based on that kind of feedback.

-s

18

Josh C. wrote:

On Wed, Feb 10, 2010 at 5:53 PM, Marnen Laibow-Koser
[email protected]wrote:

If you need to ask the mailing list a question like this, then you are
not ready to be writing Ruby tutorials. Sorry, but that’s the way it
is.
Best,

I’m not sure that this is true. Sometimes, when the person writing the
tutorial has a very firm commanding of the subject matter, they gloss
over
the kinds of things that trip up newbies. To someone well versed in
Ruby,
exit is so obvious that they probably don’t think to address it.

Quite true. I certainly didn’t know the answer off the top of my head
– but I knew where to look it up. My point – which perhaps I should
have made more clearly was that the OP didn’t know the answer, and
apparently didn’t know where to look for the answer. That pretty
clearly says to me that the OP should not be creating tutorials.

I was tutoring a student at my school for “Problem Solving and
Programming
in C” (CS211, first programming course) and he was struggling with
things
like figuring out where his files were, simple syntax, understanding
prototypes, understanding that functions can’t see eachother’s data.
Things
I would not have focused on if I were writing a tutorial, things the
course
probably gave a cursory explanation to.

Yeah. But I don’t think this is the same sort of situation.

When you are just starting out with something, you have a steep slope
ahead
of you, and only after you climb over it will you have the foundation of
knowledge necessary to understand most of the available resources.

I’m trying to learn Clojure right now, and getting started was very
frustrating, there were things the Clojure book just says, that I needed
specific steps and examples for, but the author thought that just
telling me
to do something was enough. So I had to do a lot of work and a lot of
digging, and consider quitting several times, because the perspective of
the
author was so different from my perspective.

So I think there may be a case for tutorials for newbies by newbies,
because
the things that trip up the tutorial’s author are the kinds of things
the
author is going to emphasize, and these are much more likely to be the
kinds
of things that the readers will also be struggling with. When you don’t
know
anything, and you figure something out for the first time, you know
firsthand what the hurdles are for someone in your situation, and so if
your
readers are in that same situation, then the tutorial’s subject matter,
and
emphases are more relevant to them.

This is my hypothesis. It might be useful to have Charlie ask some of
the
people he is writing the tutorial for to use a different tutorial by
someone
with more knowledge, and see how effective each was (ie gather some
empirical data to test the hypothesis).

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

19

Seebs wrote:

On 2010-02-11, Josh C. [email protected] wrote:

So I think there may be a case for tutorials for newbies by newbies,

The problem is that the newbies will often figure things out
incorrectly,
leading to tutorials that teach people bad habits, or superstitions, or
whatever.

There’s one point people here missed:

He said we was going to write a tutorial. This doesn’t necessarily
mean that he was going to publish it.

Many people enjoy writing articles. To increase his motivation when
learning a subject, such a person accompanies his studying with writing
an essay or tutorial or something. This purposeful writing does
something to their mind. It makes them feel good.

I myself have written several “micro” tutorials on various subjects,
while learning. I’ve never published them because once I finished
studying the subject these tutorials have served their purpose (and they
never were polished enough for public consumption). I actually know in
advance my “tutorials” aren’t good enough and won’t “see the light of
day”, but this writing is part of the experience. Every means is
legitimate.

20

Seebs wrote:

On 2010-02-11, Josh C. [email protected] wrote:

So I think there may be a case for tutorials for newbies by newbies,

The problem is that the newbies will often figure things out
incorrectly,
leading to tutorials that teach people bad habits, or superstitions, or
whatever.

That said, you raise a good point about tutorials in general – it’s
extremely
hard to write a good introductory text for something you know extremely
well.

Yes indeed! And skilled newcomers could play an important role here.

Tragically, as of yet, it has proven impossible for anyone to try
showing a
document to prospective readers to ask for feedback, but we hope that
some
day this technology will be developed and it will be possible to improve
documents based on that kind of feedback.

Wikis?

-s

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]