From: Mathieu Bouchard <matju@...>
Date: 2002-01-01T10:34:20+09:00
Subject: [ruby-talk:29924] Re: Ruby/Python: Software Engineering


On Tue, 1 Jan 2002, noone wrote:
> I am not meaning to annoy people or "fight", so I will ask again:
>   Is there any resource which explains how Ruby helps me write better
> code from the software engineering / methodology perspective?

That perspective doesn't exist, because there are many of them. AFAIK,
methodologies like XP and PragProg (which are the most popular among Ruby
users) carefully avoid dictating coding or cosmetics and instead
concentrate on the whole authorship process.

> This can quickly turn into another topic, but it seems to me if you
> use "classic" methodologies, then you might be right: You spend a
> bunch of time facilitating communication outside of code (eg. w/
> documents such as specifications, test plans, etc.)--you can then
> "afford" to have unintelligable code,

You can only afford to have unintelligible code if intelligibility is
implemented elsewhere, e.g. in documentation, or in job security. Anyway I
don't know why I should violate OnceAndOnlyOnce just to allow myself
writing bad code. ;-)

> Finally, if this is the case, then what is the benefit to Ruby being/having:
>   [ http://www.ruby-lang.org/en/whats.html ]  
> If readable code has little to do with "quality software" then, well
> ... that can not be what you meant to say ....

Most people on this mailing list do not represent ruby-lang.org and are
not accountable for it. conversely, ruby-lang.org does not represent the
opinions of most members of this mailing-list.

> their "features" (eg. "pure"-OO or iterators). When asked: What about
> choosing a langauge which is "friendly" towards one's problems *and
> methodologies*? one is dismissed with: You can write bad code in any
> language. Well, sure you can, but why *encourage* it?!

You are relatively safe with either Ruby or Python. The biggest offenders
may be C (buffer overflows, too many typecasting) and shell-scripts
(quoting hell). Perl is safe compared to those, but still lacks exception
handling, which makes it overhead to write correct code.

> (for example, it would be nice if the language had constructs for
> "programming-by-contract" and which could be extracted to HTML
> documentation, say).

I also thought of this one and this is why I talked about
method-combinations in my other mail: it would allow D.b.C. to be
implemented as a library instead of directly in the language. IMHO what
can be implemented outside of the language should be implemented outside
of the language. You'll find out that the libraries that you can use with
a language are as important as the language itself. (note: There already
exist library implementing D.b.C. and meth-comb in Ruby... they're just
somewhat experimental and certainly not bullet-proof)

> If one "codes-the-test-first", then a framework would be most helpful

TestFirst is very popular among Ruby users. see RubyUnit (test framework) 
and Rubicon (tests for ruby itself, using RubyUnit).

> A language is more than its syntax--it ought to fit into a
> methodology, encourage adherence,

A language is there to allow, not to restrict.

________________________________________________________________
Mathieu Bouchard                   http://hostname.2y.net/~matju