What are your favorite Ruby features?

[Juan Zanos]

That is very hard to read indeed, but why?

def foo( bar )

This is not so much better!
We are all totally accustomed to the fact that foos and bars designate
the same kind of thing.

I therefore think that

def fact n

is more readable for most people than

def n( fact )

which is nonsense of course (in the particular context).

Naming seems more important than params or not params (of course if I
might say?).

Cheers
Robert


--=20
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

Good point. Syntax isn't all there is to readability. But it does =20
have some effect.

In this case the parenthesis don't make anything inherently more =20
readable and aren't helpful in resolving the nonsense names. The =20
parenthesis are only meaningful if you already know what they mean. =20
Readability arguments are often tainted by experience with previous =20
languages. And it must be remembered that no programmer is born =20
knowing a previous programming language. If we insist, implicitly or =20=

otherwise, that readability means that something looks like 'C' or =20
Java or any other language then we place limits on how much we can =20
simplify syntax. I'd actually say that each example with parenthesis =20=

requires a lot more explanation of why they are their, what they =20
mean, what are the syntax rules that govern them, etc.

Cheers,
Juan=

 

[Michal Suchanek]

Good point. Syntax isn't all there is to readability. But it does have
some effect.

In this case the parenthesis don't make anything inherently more readable
and aren't helpful in resolving the nonsense names. The parenthesis are
only meaningful if you already know what they mean. Readability arguments
are often tainted by experience with previous languages. And it must be
remembered that no programmer is born knowing a previous programming
language. If we insist, implicitly or otherwise, that readability means
that something looks like 'C' or Java or any other language then we place
limits on how much we can simplify syntax. I'd actually say that each
example with parenthesis requires a lot more explanation of why they are
their, what they mean, what are the syntax rules that govern them, etc.

Parentheses are traditionally used to group things together. If you
have things that are logically linked together but do not visually
appear so then adding parentheses which are not required might help
you to make the code more readable.

This has nothing to do with other programming languages, you should
have learned that in elementary school during your math classes.

Thanks

Michal

 

[Juan Zanos]

Parentheses are traditionally used to group things together. If you
have things that are logically linked together but do not visually
appear so then adding parentheses which are not required might help
you to make the code more readable.

This has nothing to do with other programming languages, you should
have learned that in elementary school during your math classes.

Thanks

Michal

Michal,

Did you look at the message to which I was replying? Were =20
parentheses being used to group things together? No. They were =20
not. They were being used to distinguish a single argument from a =20
function name. In what elementary school should I have learned that =20=

use of parentheses?

Cheers,
Juan=

 

[Juan Zanos]

This message is in MIME format. The first part should be =20
readable text,
while the remaining parts are likely unreadable without MIME-=20
aware tools.
Hi --



I agree (except for your last sentence). I honestly don't give C or
Java (or Lisp, etc.) a moment's thought in any of this, when I'm
writing Ruby. Just Ruby.

One thing I've had to come to terms with, reluctantly (because it
would be so nice if it were otherwise), is that there is literally no
such thing as inherent readability. Readability simply does not inhere
in the notation, any more than it does in a given alphabet.

Ok. We don't have to agree completely. We both seem to agree that =20
there are arbitrary aspects to syntax conventions that do not =20
inherently affect readability. Perhaps where we disagree is that I =20
do believe something can be inherently more or less readable and you =20
do not. I believe that overly complicated syntax becomes less =20
readable and even more unwritable. So I tend to prefer a simpler =20
syntax even if it's slightly different from a particular convention.

Cheers,
Juan=20
=20=

 

[Michal Suchanek]

Michal,

Did you look at the message to which I was replying? Were parentheses
being used to group things together? No. They were not. They were bei= ng
used to distinguish a single argument from a function name. In what
elementary school should I have learned that use of parentheses?

I have taken your "each example with parenthesis" as referring to the
parenthesis discussion on this thread in general, not the particular
examples with defining methods.

For that the 'def' keyword should be distinctive enough.

Thanks

Michal

 

[Robert Dober]

Michal,

Did you look at the message to which I was replying? Were parentheses
being used to group things together? No. They were not. They were being
used to distinguish a single argument from a function name. In what
elementary school should I have learned that use of parentheses?

I agree with you here, Juan.
We are of course not talking about parentheses which are *needed* and
IIRC we learned in math classes to leave away all parentheses which
were *not needed*.
Robert
--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[James Britt]

Thats a harsh statement for those that do actually like parantheses and
not because they are C//Java-Guys.

It's simply an observation based on reasons people have given me when I
try to understand what value the parens offer. It ends up being, "I'm
used to them", or, "It looks weird without them", or, "I find it more
readable."

Basically, their absence makes some people uneasy; they feel better with
them there, though they do not provide any information or programmatic
value.

I'm sure there are people who did not come to Ruby after using Java or C
and still think the parens make the code easier to work with. I just
haven't met them.

For example, i find the following irritating and bad style:

===
def initialize foo, bar, batz = {}, &block
#(vs.)
def initialize( foo, bar, batz = {}, &block )
===

I see the argument list as a tuple and I like it to resemble one.

Except you can't do this:

def foo (my, tuple, arg); end

Also, i tend to brace long and unbalanced statements:

===
var_foo_bar = :Something::Somewhere::Object.new(
:foo => "bar"
)
)

There *are* times when the parens may make the arg list more readable,
but it ends up being a matter of taste, and that comes from exposure.

The more people add the redundant parens, the more they see it as
"right", and the more they do it.

I prefer to omit whatever I can until I have a good reason not to.
Maybe that good reason ends up being, "I'm making more stupid errors",
and that's fine, but so far I've had fewer such errors without the
parens than with them.

I don't expect anyone is going to change their minds on this based on
words alone, but it's interesting to see how preferences evolve.

For example, in learning Haskell, I've come across a number of places
that explain that while one can use parens in various places, the
preferred style is to leave them out when possible. Different culture.

--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

 

[Florian Gilcher]

I'm sure there are people who did not come to Ruby after using Java
or C and still think the parens make the code easier to work with.
I just haven't met them.

Meet: me. No Java//C-Exposure beyond the absolute must in university
courses (and I learned Ruby before them). And as I said before, it's
highly depending on the context.

Except you can't do this:

def foo (my, tuple, arg); end

Sure, it is not a perfect image. It's just the direction.

There *are* times when the parens may make the arg list more
readable, but it ends up being a matter of taste, and that comes
from exposure.

I'm a fan of consistency. Even in relativly strict defined languages
like Java and C I always shriek when seeing people using several
styles just as they see fit. Obviously, making them mandantory (and
them omittable in some very special cases...) doesn't fix the problem
as well.

As you said: there are moments where parens help ("def a b,c = {}"
being a good example). So, I prefer to stick to them in all parameter
lists to eliminate this question. Especially because I have a tendency
for creative use of parameter lists (that make Java guys shriek).

Rest assured, I am writing:

===
div.address "bla", :class => bar do
#something different
end
===

when using Builder//Markaby (for example), because parens would
clutter the declaration.

The thing is that I try not to mix the styles. As I said, I clearly
prefer:

===
foo(bar(batz))
# over
foo bar(batz) # looks unbalanced
===

To extend this:

===
some_method bar(batz)
some_other_method bar # oh
===

Suddently, the braces really hurt. While in a balanced display
(granted, it's hard to conjure up nice examples):

===
some_method(bar(batz))
some_other_method(bar)
===

So, I prefer to just stick to the braces.

The more people add the redundant parens, the more they see it as
"right", and the more they do it.

That sounds like they are utterly wrong.

I prefer to omit whatever I can until I have a good reason not to.
Maybe that good reason ends up being, "I'm making more stupid
errors", and that's fine, but so far I've had fewer such errors
without the parens than with them.

I don't to parens errors as well... so? I think the difference is
neglectible.

I don't expect anyone is going to change their minds on this based
on words alone, but it's interesting to see how preferences evolve.

For example, in learning Haskell, I've come across a number of
places that explain that while one can use parens in various places,
the preferred style is to leave them out when possible. Different
culture.

Not only a different culture but also different facilities. Haskell is
far better in grasping things like "foo bar batz a" (oh, didn't write
Haskell for at least 2 years... is that valid?).

At the end of the day, it is the projects maintainers call how the
code should be written.
Maybe it might be worthwhile to document those styles at a certain
place for maintainers to refer to "their" style.

And, thats why I tuned in: attributing brace styles other then Your
Enlightened One to other persons inability to find The True Way. There
is a language called Python for that .

Regards,
Florian Gilcher

--
Florian Gilcher

smtp: (e-mail address removed)
jabber: (e-mail address removed)
gpg: 533148E2

 

[James Britt]

And, thats why I tuned in: attributing brace styles other then Your
Enlightened One to other persons inability to find The True Way. There
is a language called Python for that .

I think you're putting words in my mouth.

I have my own preference, and have so far found arguments to the
contrary unsatisfying because they are usually based on previous use of
parens in other languages. (The most interesting suggestion I've
heard is to use the parens to indicate if the return value of the method
is useful or not. That is, whether a method is intended as a statement
or an expression.)

I'm truly puzzled when people get their back up at the suggestion that
their style preference is based on bias obtained from previous exposure
to other language, conscious or not. I don't think too many people are
deliberately thinking, "I want to make this look like
[C|Java|Perl|PHP]", but surely there is *some* bias based on experience.

Whether or not that makes anyone enlightened is yet another matter of
opinion and not all that interesting a topic. I'm certainly not
claiming it for myself.

The debate is not entirely academic. New features and syntax are being
added to Ruby on 1.9, and there are similar debates about the
readability of many things. It's worth understanding why people have
such issues, and whether or not the difficulties can be overcome by
extended exposure, or whether there are intrinsic reason why something
is hard for people to visually parse.

Ruby is quite similar to other languages, and people bring assorted
expectations, and to what degree those expectations should be matched or
encouraged in Ruby as it evolves is a reasonable question.

 

[David Masover]

For example, i find the following irritating and bad style:

===
def initialize foo, bar, batz = {}, &block
#(vs.)
def initialize( foo, bar, batz = {}, &block )
===

I see the argument list as a tuple and I like it to resemble one.

However, tuples in Ruby can also be assigned without parens:

some_array = 1, 2, 3

I find that it's purely a matter of style. I like to drop whatever
syntax I can, and infer the rest from the environment. However, I also
like the fact that they are _optional_ -- it means we don't actually
have to agree, unless we're working on the same codebase. We can both
use the same language, and you can use parens, and I can drop them.

That was my point -- I like the syntax to be flexible like that.

Also, i tend to brace long and unbalanced statements:

===
var_foo_bar = :Something::Somewhere::Object.new(
:foo => "bar"
)
)
===

In that case, I would tend to write it either like this:

var_foo_bar = Something::Somewhere::Object.new :foo => 'bar'

Or, if that was really getting cumbersome, and I had to wrap it, I'd
probably do something like this:

var_foo_bar = Something::Somewhere::Object.new(
:foo => 'bar',
:frobinate => true,
:frobs => [1, 2, 3]
)

Again, a matter of style. In particular, I would be just as frustrated
with a language that did not allow superfluous parentheses as one that
required them.

We should never forget that the purpose of the language is to encode our
thoughts in a machine-readable and human-readable form. If some rule of
syntax gets in the way of that, the language is failing in its purpose.
If it's possible for humans to write unreadable code (Perl's "line
noise" problem), that is poor style on the part of the coder, not a
fault of the language.

 

[David Masover]

Parentheses are traditionally used to group things together. If you
have things that are logically linked together but do not visually
appear so then adding parentheses which are not required might help
you to make the code more readable.

That is a good rule of thumb.

However, my editor has decent syntax highlighting, so in many cases,
things are grouped together by color. When they are not, or when it is
actually ambiguous, I use parentheses.

 

[David A. Black]

Hi --

It's simply an observation based on reasons people have given me when I try
to understand what value the parens offer. It ends up being, "I'm used to
them", or, "It looks weird without them", or, "I find it more readable."

Basically, their absence makes some people uneasy; they feel better with them
there, though they do not provide any information or programmatic value.

I'm sure there are people who did not come to Ruby after using Java or C and
still think the parens make the code easier to work with. I just haven't met
them.

I did learn C before Ruby, but post hoc ergo propter hoc is still a
logical fallacy

I write what I think is clearest, which as we know means that some
people will also find it clearest and others won't. I don't have any
emotions or convictions one way or another about the characters '('
and ')' themselves.

I understand why you think it's sort of mushy and non-rigorous to use
discretionary parentheses, and it probably is, but I can't seem to
convince myself to stop being guided by criteria of (what I judge to
be) clarity. I'm just an old softy


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09

 

[Robert Dober]

I have no idea what they're talking about -- but I have to assume they
really do find it more readable, and that whatever is going on in
their brain when they look at the first version is similar to what
goes on in my brain when I look at the second.

That seems quite likely to me and I even daresay that if you were
exposed to the first style for a given time T your brain would adapt.
And probably T is not even very long.
And vice versa of course.
Robert
--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[David A. Black]

Hi --

That seems quite likely to me and I even daresay that if you were
exposed to the first style for a given time T your brain would adapt.
And probably T is not even very long.
And vice versa of course.

Just to be clear: I do understand the notation that I don't
particularly like. I just don't particularly like it


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09

 

[Juan Zanos]

That seems quite likely to me and I even daresay that if you were
exposed to the first style for a given time T your brain would adapt.
And probably T is not even very long.
And vice versa of course.
Robert
--=20
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

Relative to time spent learning a language I'd say the T might as =20
well be zero. Mostly the arguments for using parentheses when they =20
aren't necessary seem to be arguments of taste. There's no disputing =20=

taste, but simplicity is a powerful argument. If someone can give =20
me a convincing argument for why the way I do something is less =20
simple than the way they do something I'm very likely to change. I =20
find myself swayed by the argument that unnecessary use of =20
parentheses is more complicated. It's more ink. It's more =20
syntax. It's more overloading of the meaning of the parentheses =20
character.

When it comes to pure taste I try to be ambivalent. If everyone in =20
the world decided it would be cool to switch parentheses around so =20
the ends pointed outside I don't think I could raise a legitimate =20
argument against it. At least I can't think of a convincing argument =20=

off the top of my head and it would be mildly amusing.

Cheers,
Juan=

 

[Bill Kelly]

I have my own preference, and have so far found arguments to the
contrary unsatisfying because they are usually based on previous use of
parens in other languages. (The most interesting suggestion I've
heard is to use the parens to indicate if the return value of the method
is useful or not. That is, whether a method is intended as a statement
or an expression.)

I'm truly puzzled when people get their back up at the suggestion that
their style preference is based on bias obtained from previous exposure
to other language, conscious or not. I don't think too many people are
deliberately thinking, "I want to make this look like
[C|Java|Perl|PHP]", but surely there is *some* bias based on experience.

I agree there is some bias based on experience, as I went through
a phase about 18 years ago as a C programmer, deliberately
memorizing the operator precedence table and taking small delight
in being able to write expressions devoid of any parens except
those strictly necessary to the parser.

Note, also, that my first language was Forth, which I programmed
in for seven years--initially as a hobbyist, then professionally--
before I learned C.

Forth doesn't need parens for anything... ( they're comment delims. )

However, I'm not sure my Forth experience played a role in my
temporary dalliance with extreme paren minimalism in C. At the
time, I felt memorizing the operator precedence table and making
use of that knowledge by minimizing use of parens was sort of a
natural course to take for someone intent on mastering the
language.

Eventually one of my co-workers told me he had trouble reading
my code. Initially my (private) reaction was, this guy isn't
serious about his craft! He really ought to learn the language.

Thankfully I got past that phase eventually.

My current bias based on experience is that when reading code,
my brain does frequently prefer more parens than are strictly
necessary to the parser.

Example from earlier post:

I find the second irritating because those parens are sooo
superfluous.

If I could have participated in this thread eighteen years ago I
would almost certainly have been in the superfluous==suboptimal
camp.

Nowadays, my brain finds the latter declaration with the parens,
more restful to the eye than the former.

It's easier for me to see the structure at-a-glance in the
latter....

I realize this is necessarily very subjective. But my point is
just that the strictly minimal syntax required to satisfy the
parser is no longer an important criterion to me when I'm
writing code I want to be easy for me(*) to read.

*(((and apparently my poor co-workers))) <grin>


Regards,

Bill

 

[Juan Zanos]

I have my own preference, and have so far found arguments to the =20
contrary unsatisfying because they are usually based on previous =20
use of parens in other languages. (The most interesting =20
suggestion I've heard is to use the parens to indicate if the =20
return value of the method is useful or not. That is, whether a =20
method is intended as a statement or an expression.)
I'm truly puzzled when people get their back up at the suggestion =20
that their style preference is based on bias obtained from =20
previous exposure to other language, conscious or not. I don't =20
think too many people are deliberately thinking, "I want to make =20
this look like [C|Java|Perl|PHP]", but surely there is *some* bias =20=
based on experience.

I agree there is some bias based on experience, as I went through
a phase about 18 years ago as a C programmer, deliberately
memorizing the operator precedence table and taking small delight
in being able to write expressions devoid of any parens except
those strictly necessary to the parser.

Note, also, that my first language was Forth, which I programmed
in for seven years--initially as a hobbyist, then professionally--
before I learned C.

Forth doesn't need parens for anything... ( they're comment delims. )

However, I'm not sure my Forth experience played a role in my
temporary dalliance with extreme paren minimalism in C. At the
time, I felt memorizing the operator precedence table and making
use of that knowledge by minimizing use of parens was sort of a
natural course to take for someone intent on mastering the
language.

Eventually one of my co-workers told me he had trouble reading
my code. Initially my (private) reaction was, this guy isn't
serious about his craft! He really ought to learn the language.

Thankfully I got past that phase eventually.

My current bias based on experience is that when reading code,
my brain does frequently prefer more parens than are strictly
necessary to the parser.

One of the things that confuses this discussion is that some people =20
are talking about the use of parentheses with regard to operator =20
precedence rules and others are discussing far more arbitrary and =20
questionable usages such as in declaring and calling functions. I =20
think it's telling that such a seemingly minor complexity is cause =20
for confusion.

I doubt you'll get much disagreement that operator precedence rules =20
for c (or Ruby) are complex enough that there are cases where the use =20=

of parentheses simplifies reading. That doesn't seem to be =20
something anyone is questioning.

Cheers,
Juan=

 

[Juan Zanos]

This message is in MIME format. The first part should be =20
readable text,
while the remaining parts are likely unreadable without MIME-=20
aware tools.
Hi --

From: "James Britt" <[email protected]>
I have my own preference, and have so far found arguments to the =20=
contrary unsatisfying because they are usually based on previous =20=
use of parens in other languages. (The most interesting =20
suggestion I've heard is to use the parens to indicate if the =20
return value of the method is useful or not. That is, whether a =20=
method is intended as a statement or an expression.)
I'm truly puzzled when people get their back up at the =20
suggestion that their style preference is based on bias obtained =20=
from previous exposure to other language, conscious or not. I =20
don't think too many people are deliberately thinking, "I want =20
to make this look like [C|Java|Perl|PHP]", but surely there is =20
*some* bias based on experience.
I agree there is some bias based on experience, as I went through
a phase about 18 years ago as a C programmer, deliberately
memorizing the operator precedence table and taking small delight
in being able to write expressions devoid of any parens except
those strictly necessary to the parser.
Note, also, that my first language was Forth, which I programmed
in for seven years--initially as a hobbyist, then professionally--
before I learned C.
Forth doesn't need parens for anything... ( they're comment =20
delims. )
However, I'm not sure my Forth experience played a role in my
temporary dalliance with extreme paren minimalism in C. At the
time, I felt memorizing the operator precedence table and making
use of that knowledge by minimizing use of parens was sort of a
natural course to take for someone intent on mastering the
language.
Eventually one of my co-workers told me he had trouble reading
my code. Initially my (private) reaction was, this guy isn't
serious about his craft! He really ought to learn the language.
Thankfully I got past that phase eventually.
My current bias based on experience is that when reading code,
my brain does frequently prefer more parens than are strictly
necessary to the parser.

One of the things that confuses this discussion is that some =20
people are talking about the use of parentheses with regard to =20
operator precedence rules and others are discussing far more =20
arbitrary and questionable usages such as in declaring and calling =20=
functions. I think it's telling that such a seemingly minor =20
complexity is cause for confusion.

I don't think there's any confusion, just (rather trivially, in the
overall scheme of things) different practices.


David

--=20
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/=20
atlanta09

I haven't heard any different practices with regard to parenthesis =20
and operator precedence in this discussion. Am I wrong about this? =20=

And with regard to operator precedence it doesn't sound like there =20
are any unique issues with Ruby. Well, other than the fact that you =20=

can create new operators with Ruby and you can't in most languages. =20
But nobody has mentioned that feature.

Cheers,
Juan=

 

[Bill Kelly]

One of the things that confuses this discussion is that some people
are talking about the use of parentheses with regard to operator
precedence rules and others are discussing far more arbitrary and
questionable usages such as in declaring and calling functions. I
think it's telling that such a seemingly minor complexity is cause
for confusion.
Again:

Nowadays, my brain finds the latter declaration with the parens,
more restful to the eye than the former.

It's easier for me to see the structure at-a-glance in the
latter....

I find these reasons sufficient and non-arbitrary.

I doubt you'll get much disagreement that operator precedence rules
for c (or Ruby) are complex enough that there are cases where the use
of parentheses simplifies reading. That doesn't seem to be
something anyone is questioning.

But we do get disagreement among programmers as to the *degree*
to which parens ought to be used to clarify operator precedence.

The same kind of disagreement happens in C with regard to
whether and when to use braces when the body of a conditional
is a single statement.

if (foo)
bar();
else
baz();

if (foo) {
bar();
}
else {
baz();
}

if (xyzzy)
if (foo)
bar();
else
baz();

if (xyzzy) {
if (foo)
bar();
else
baz();
}

 

[Rick DeNatale]

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

I agree there is some bias based on experience, as I went through
a phase about 18 years ago as a C programmer, deliberately
memorizing the operator precedence table and taking small delight
in being able to write expressions devoid of any parens except
those strictly necessary to the parser.
...

Eventually one of my co-workers told me he had trouble reading
my code. Initially my (private) reaction was, this guy isn't
serious about his craft! He really ought to learn the language.

Thankfully I got past that phase eventually.

My current bias based on experience is that when reading code,
my brain does frequently prefer more parens than are strictly
necessary to the parser.

Somehow this reminds me of the old story of a waiter motioned over to one of
his tables, the customer said:

"Would you taste this soup?"

Waiter, "I'm sorry sir, if there's something wrong with your soup, I'd be
happy to have the chef fix it or bring you something else, but the health
inspector is rumored to be paying a surprise visit, and we've been warned
not to do anything which might cause a problem."

Customer, "No, I insist, please taste my soup!"

The waiter looked around to see if anyone was looking, turned back to the
customer, and said,

"Okay, where's your spoon?"

To which the customer replied

"AHA!"

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale