From: Tomasz Wegrzanowski <taw@...>
Date: 2002-01-01T09:05:55+09:00
Subject: [ruby-talk:29913] Re: Ruby/Python: Software Engineering

On Tue, Jan 01, 2002 at 07:06:38AM +0900, noone wrote:
> > Ruby doesn't do things you want and we should thank Matz it doesn't.
> 
> Which things: "Software Engineering" or the (few) things I listed?

Things you listed.

> > Enforcement of indentation, lack of what you call "line noise" and lack of short cuts
> > have very little to do with quality of software.
> > 
> 
> 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, because it is explained somewhere else. If one follows "lightweight"
> process, then the code itself become more important, and must be more than just "code".
> 
> My environment happens to be one where "classic" documentation is 'difficult' to implement
> and for whatever other reasons not done for the most part.
> 
> Finally, if this is the case, then what is the benefit to Ruby being/having:
> 
>   It is simple, straight-forward, ...
> 
>   . . . .
> 
>   Ruby has simple syntax, partially inspired by Eiffel and Ada. 
> 
>   [ 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 ....

Readability have little to do with *enforced* intendation, usage of non-alphanumerics versus keywords
and using shortcuts. What is readable for you is mostly function of what have you're used to read.

> > Nobody will try to force you to switch from Python to Ruby.
> 
> Unfortunately, this is NOT the case. When my group within my company looks to improve productivity,
> one question is: Can we develop code better? Again, unfortunately, most people simply compare languages
> by 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?!
> 
> If iterators would improve productivity (or are required) then naturally that will become
> a requirement for one's language choice. If "classic" specifications are required,
> then naturally we ought to use the language which best facilitates this requirement
> (for example, it would be nice if the language had constructs for "programming-by-contract"
> and which could be extracted to HTML documentation, say). If one "codes-the-test-first",
> then a framework would be most helpful; and the closer it is tied to one's development
> environment (embedded within the code, extractable to documentation, one window, one key stroke, etc.) the better.
> 
> A language is more than its syntax--it ought to fit into a methodology, encourage adherence,
> and reward with better code quicker (among much else).

Most efforts to discourage writing bad code so far ended with making writing *any* code harder.
Please compare Ada and C. They are on completely opposite side of enforce-good-programming to
let-programmer-do-whatever-he-wants axis. There is order of magnitude more good programs in C than
in Ada and there is virtualy no evidence that Ada programming is more efficient than C programming.
If so huge difference in "encoraging" results in so small gain in results (if any),
I seriously doubt that difference in encouragement between Ruby and Python, which are very similar,
will have any significant result on efficiency or quality of software writing.