[ruby-talk:29904] Re: Ruby/Python: Software Engineering

Tomasz/All:

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?


Embedded below is more detail which you are certainly not required to read <grin!>:

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

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

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


thanks!! <<q



On Tue, 1 Jan 2002, Tomasz Wegrzanowski wrote:

> On Tue, Jan 01, 2002 at 05:03:35AM +0900, noone wrote:
> > All:
> > 
> > There are many things I like about Python, but the one that seems to keep me w/ Python
> > is (IMHO) its commitment to "software engineering practices/methodologies".
> > 
> > Hopefully staying away from an infinite recursive descent into definitions,
> > is there any good summary that attempts to justify where/how Ruby makes this a priority?
> > 
> >   Quentin Crain
> > 
> > What follows is detail which is not necessary to answer the question above, but fills out (a little) my thinking.
> > 
> > Software Engineering Practices/Methodologies include:
> > 
> >   Designed from the "ground up" for readability
> > 
> >     Enforced indention (you indent your own code I bet)
> >     { @No #line $noise }
> >     No short cuts ($!, $%, etc)
> > 
> >   Documentation a priority from the beginning
> > 
> >     docstrings (at all)
> >     docstrings (as properties)
> > 
> > Many of you are probably tired of this type of thread, but these are the types of things that keep
> > me using Python and I am wondering if/when/where Ruby addresses them. Are these simply topics of opinion,
> > or do they actually matter?
> 

-------------------------------------------------------------------------
I think we are miscommunicating. I actually expected some confusion with
my last response and I am not sure if there actually was some, but I feel
like it. So, my message is going to assume I did not make my points, but
perhaps you did understand me. If so, then that means *I* did not
understand *YOUR* response - in which case you will need to rephrase.