From: "James Britt (rubydev)" <james@...>
Date: 2002-01-01T09:06:49+09:00
Subject: [ruby-talk:29914] Re: Ruby/Python: Software Engineering

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

The use of the word "classic" suggests that software development is a mature field, with
a long, venerable history of knowldege and techniques.  People have been writing
code for less than 100 years.  Calling anything to do with computers "classic" 
seems odd.  (It makes me think of "classic rock"; might make sense in 200 years.)

I'm not convinced that writing software is engineering.  I'd rather pick my tools
the way I would pick drawing pencils or a violin; I want things that give me
freedom, not force me to work in a certain style.

> 
> Finally, if this is the case, then what is the benefit to Ruby being/having:
> 
>   It is simple, straight-forward, ...

I find Ruby makes it simpler to write code that does just what I want done.  
It's easier to read, and easier to see what's supposed to be happening.

> 
> 
> If readable code has little to do with "quality software" then, well ... that 
> can not be what you meant to say ....

Illegible code can still be well-designed, though it can be a major pain
to maintain.  Readability goes beyond indentation and avoiding line-noise shortcuts.
I've yet to hear of a language that prevents you from misnaming variables or
methods.  (Hmm. Maybe we need a language that prevents variables names less 
than five characters long; must have a least one vowel?  Might be a start ...)

Besides, enforcing decent coding style is generally not hard.  The odd-person-
out gets ridiculed and ostracized by the other developers. :)

> 
> > 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?!

I think you may be putting the cart before the horse.  What looks like bad
code according to one design method may be fine according to another. If a language
requires (or strongly encourages) following a particular philosophy then it also
restricts you from exploring others.

Evolving one's development philosophy shouldn't require you to change languages
(though that may happen anyway).  One day people will look back at XP and say,
"How quaint."  Not because XP is wrong or misguided, but because it will inevitably
lead to other, better things.  You shouldn't have to ditch code because the
language forces you to think in a way you no longer find appropriate.


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

Perhaps it should be the other way around: Find languages that provide
clean ways to do most things with a minimum of fuss, and see what development
methods can be derived from their use.


James

> 
> 
> thanks!! <<q