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

> 
> [Quentin Crain]
> James/All:
> 
> 
> At 09:06 AM 1/1/2002 +0900, James Britt (rubydev) wrote:
> >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.)
> 
> Umm ... my interpretation of the above is that you did understand my 
> meaning of "classic" (duly quoted), so its usage seems to be clear nonetheless.

I should have been more specific: software development is not old enough to have
"classic" anything.

> 
> >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.
> 
> In short: It is not important to be able to draw, create music or code in 
> "unnatural" styles. The point is to use the tools which are "friendly" 
> without loss of power.
> 
> Or do I miss something?

If a tool *forces* me to follow a style then I have lost power.


> >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 ...)
> 
> Agreed--but why does this matter? Obviously anything/everything can be 
> misused; but that does not mean everything is then equal.

I don't think anyone has claimed everything is then equal.  The point is that
while some languages force you to adhere to *some* aspect of a coding style, 
there are still so many other ways permissible to break that style that, overall,
the adhering to a coding style still requires individual discipline.


> >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.
> 
> Agreed again. But just because a language says it does not restrict you 
> does not make it true. Or better put, every language has a philosophy and 
> restricts to it. Ruby is no different right? In fact, by being "pure"-OO it 
> forces *that* particular philosophy (would it not?).

No.  It may encourage it, but Ruby does not prevent you from writing
procedural code.  Not sure how it fairs if you want to mimic a functional
programming language.

I agree that each language has its own "world view."  The difference is 
to what degree a language allows you to disagree with that view, or to what
extent that view is permissive or restrictive.

There is also a separation between language philosphy (e.g.., OO, functional,
procedural) and design/development methods (XP, Agile, NewBuzzWord, ...)

So, if you decide that OO is the cat's meow, then you should probably use
an OO language.  But if you are looking at development from a somewhat higher
level, that becomes a different issue.  There's nothing about Ruby that
argues for XP, or any other approach at that level, and doing so would be 
inappropriate for a language.


> 
> >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.
> 
> I do not understand this. I hear you saying that I should not rewrite just 
> because I have changed my thinking. Fine--but *new* code should be written 
> in the way I find appropriate right?

Of course. But, if you've chosen a language that *compels* you to think a certain
way, and later decide to think differently, then the language becomes a hindrance.

For example, if next year you decide "Code the unit test first" is a bone-head 
idea, you shouldn't have to change langauges becasue you picked one that forces 
you code unit tests.


> 
> Otherwise, is not this saying: One should code in ways one does not think? 
> That can not be very efficient nor productive.

One should code in accordance to how one thinks.  The language should get out
of the way as much as possible.  You should be able to say, "Today I want to follow
software development philosphy X, and language Foo will help me." Next year you
should be able to say, "today I want to follow software development philosphy Y, 
and language Foo will help me." 


> 
> 
> >
> >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.
> 
> Unless I am misunderstanding this says: The tools should drive the methodology.
> 
> I believe the needs of the developers (along with being human) take 
> precedence. And I would be confused as to how things would go better when 
> forcing people to act in "unnatural" ways, ways forced on them by their 
> tool choices.

Tools don't force you to do anything; if you don't like a tool, don't use it.
And don't let a methodology lead you to do something unatural.

James