Exit method?

[Charlie Ca]

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

 

[Marnen Laibow-Koser]

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
(e-mail address removed)

 

[Charlie Ca]

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
(e-mail address removed)

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

 

[Eric Christopherson]

If you need to ask the mailing list a question like this, then you are
not ready to be writing Ruby tutorials. =A0Sorry, 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.

 

[Marnen Laibow-Koser]

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
(e-mail address removed)

 

[Ehsanul Hoque]

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

Well no, don't just "stick to 'Hello World'" programs. What Marnen means isthat 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 Rubyand programming in general, do write programs, as many as you can. just not tutorials for Ruby just yet.

No reason to get discouraged, you're a beginner now. You just have to spendsome time learning yourself before you can teach others. Instead of "HelloWorld" 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.

 

[Robert Klemme]

Oh, if that's the case, then yes, my response was uncalled-for. =C2=A0I d= id
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.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[Marnen Laibow-Koser]

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.

No, it was deliberately meant to be a bit harsh -- shock tactics.

Kind regards

robert

Best,

 

[Mason Kelsey]

[Note: parts of this message were removed to make it a legal post.]

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

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.

No, it was deliberately meant to be a bit harsh -- shock tactics.

Kind regards

robert

Best,

 

[Marnen Laibow-Koser]

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.

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
(e-mail address removed)

 

[Seebs]

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

 

[Marnen Laibow-Koser]

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
(e-mail address removed)

 

[Seebs]

"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

 

[Marnen Laibow-Koser]

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
(e-mail address removed)

 

[Seebs]

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

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

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

 

[Marnen Laibow-Koser]

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
(e-mail address removed)

 

[Seebs]

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

 

[Marnen Laibow-Koser]

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
(e-mail address removed)

 

[Albert Schlef]

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.