From: Phrogz <gavin@...>
Date: 2006-01-10T07:58:01+09:00
Subject: Re: Ideas on "Why Living Dangerous can be A Good Thing" in Ruby?

> However, to the outsider, this is only an explanation of "how" to
> overcome the apparent "flaw".  I'd like to do as good a job I can of
> explaining why it isn't a flaw, when practiced correctly.

There seems to be some sort of logical fallacy at play here, but I
can't sniff out what it is. Arguing from authority? Begging the
question?

You seem to be half-asking for good answers to "Is Ruby's openness a
flaw?" and at the same time looking for good answers to the argument
"Why Ruby's openness isn't a flaw."

I would argue that it IS a flaw...for some people, use cases, or
programming styles. At the same time, I would then argue that it's also
a huge feature...for some people, use cases, or programming styles.

Don't try to convince people that they're wrong for wanting a compiler
to catch certain typos for them without writing use cases. Don't tell
them "if you include libraries A and B in your application, and B
modifies A in a way that neither's documentation covers...that's a
feature! You should embrace it, not hate it!"

Instead, convince them that use cases are more secure than the false
sense of security syntax- and static-checking provide. Acknowledge that
there ARE some downsides to the openness, but that they are outweighed
by the freedom provided.

This thread is not about a language war, but touches on issues at the
fringes of one. Remember that no one language is the Right language for
all cases. There may be cases where the openness of Ruby makes it the
wrong choice.

To convince people that Ruby is Right for cases where they are clinging
to a few misconceptions:

1) Identify clear problems, or perceived problems.
2) One by one, lay out:
2a) What the problem is in Ruby.
2b) Why it isn't (or is) a problem in the 'standard' language of
choice.
2c) How you can remove or mitigate the problem in Ruby using additional
features or changed coding styles. If you can't, say so.
2d) What benefits are made possible by the features of Ruby that cause
the problem.

The combination of 2c and 2d should give the listener a good idea of
cost/benefits. 2b may give the user an 'ah-ha' moment, realizing they
have misconceptions, or have been relying on a false sense of security.