Ruby/Python: Software Engineering 
Author Message
 Ruby/Python: Software Engineering

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

thanks!! <<q

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



Sat, 19 Jun 2004 04:06:04 GMT  
 Ruby/Python: Software Engineering

Quote:

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

Ruby doesn't do things you want and we should thank Matz it doesn't.

Enforcement of indentation, lack of what you call "line noise" and lack of short cuts
have very little to do with quality of software.

Nobody will try to force you to switch from Python to Ruby.



Sat, 19 Jun 2004 04:27:27 GMT  
 Ruby/Python: Software Engineering

Quote:

> [...] commitment to "software engineering practices/methodologies".
> [...] Software Engineering Practices/Methodologies include:
>   Designed from the "ground up" for readability

The most readability comes from people who understand what they write, and
the language in which they're writing it, and use appropriate
abstractions. Bad readability comes from sweating the little stuff, and
forgetting the big picture.

Quote:
>     Enforced indention (you indent your own code I bet)

That's a nice feature to save writing "end" all the time. But not having
to write "self" all the time is much more important to me.

Quote:

>     No short cuts ($!, $%, etc)

Ruby's sigils convey meaning, therefore they are not noise. Perl's sigils
are closer to useless because "$" occurs way too often in situations where
you couldn't write anything else than "$".

Programming is essentially made of shortcuts. I think the art of concise
expression is something that should be understood and mastered, not
feared. But I think half of the Perl-inspired shortcuts are no good.
Example of good Perlish "shortcuts" would be && || &&= ||= operators.

Quote:
>   Documentation a priority from the beginning
>     docstrings (at all)
>     docstrings (as properties)

Docstrings are nice, and Ruby doesn't have them. I'd like them to be
there, but this is far from being a priority to me.

Meaningful, structured code is still more important to me, which is why
I'd vote Lisp-style method-combinations as much higher priority on the
list of things I'd add to Ruby.

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



Sat, 19 Jun 2004 05:47:57 GMT  
 Ruby/Python: Software Engineering

If you want readability, use Cobol.

Quote:
-----Original Message-----

Sent: Monday, December 31, 2001 1:42 PM
To: ruby-talk ML; noone

Cc: ruby-talk ML
Subject: [ruby-talk:29896] Re: Ruby/Python: Software Engineering


> [...] commitment to "software engineering practices/methodologies".
> [...] Software Engineering Practices/Methodologies include:
>   Designed from the "ground up" for readability

The most readability comes from people who understand what they write, and
the language in which they're writing it, and use appropriate
abstractions. Bad readability comes from sweating the little stuff, and
forgetting the big picture.

>     Enforced indention (you indent your own code I bet)

That's a nice feature to save writing "end" all the time. But not having
to write "self" all the time is much more important to me.


>     No short cuts ($!, $%, etc)

Ruby's sigils convey meaning, therefore they are not noise. Perl's sigils
are closer to useless because "$" occurs way too often in situations where
you couldn't write anything else than "$".

Programming is essentially made of shortcuts. I think the art of concise
expression is something that should be understood and mastered, not
feared. But I think half of the Perl-inspired shortcuts are no good.
Example of good Perlish "shortcuts" would be && || &&= ||= operators.

>   Documentation a priority from the beginning
>     docstrings (at all)
>     docstrings (as properties)

Docstrings are nice, and Ruby doesn't have them. I'd like them to be
there, but this is far from being a priority to me.

Meaningful, structured code is still more important to me, which is why
I'd vote Lisp-style method-combinations as much higher priority on the
list of things I'd add to Ruby.

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



Sat, 19 Jun 2004 06:09:21 GMT  
 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!>:

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

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

Quote:
> 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

Quote:


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


Sat, 19 Jun 2004 06:09:21 GMT  
 Ruby/Python: Software Engineering

Quote:
> >     Enforced indention (you indent your own code I bet)
> That's a nice feature to save writing "end" all the time. But not
having
> to write "self" all the time is much more important to me.

That's always been a mystery to me... I enjoy Python's terseness that
comes from using indentation to describe blocks, but it doesn't seem to
reconcile with the (IMHO) sillyness of writing self everywhere.


I *do* like both Python and Ruby, so please don't interpret either of my
comments as flames or flamebait...

--

[ Consulting, Training, and Software development tips and   ]
[ techniques: Java, Delphi, ASTA, BDE Alternatives Guide,   ]
[ JB Open Tools, EJB, Web applications, methodologies, etc. ]



Sat, 19 Jun 2004 07:00:45 GMT  
 Ruby/Python: Software Engineering

Quote:



> > >     Enforced indention (you indent your own code I bet)

> > That's a nice feature to save writing "end" all the time. But not
> having
> > to write "self" all the time is much more important to me.

> That's always been a mystery to me... I enjoy Python's
> terseness that comes from using indentation to describe
> blocks, but it doesn't seem to reconcile with the (IMHO)
> sillyness of writing self everywhere.

You need some way of disambiguating nested classes (how does Ruby do
this btw?):

  class Outer:
      def method1(self): pass
      def method2(self):
          class Inner:
              def innerMeth1(this): pass
              def innerMeth2(this):
                  self.method1()
                  this.innerMeth1()

Etc.

-- bjorn



Sat, 19 Jun 2004 07:13:23 GMT  
 Ruby/Python: Software Engineering

Quote:

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

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

- Show quoted text -

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


Sat, 19 Jun 2004 08:06:29 GMT  
 Ruby/Python: Software Engineering

Quote:

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

Quote:

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

Quote:

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

Quote:

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

Quote:

..

> 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

Quote:

> thanks!! <<q



Sat, 19 Jun 2004 08:11:49 GMT  
 Ruby/Python: Software Engineering

Quote:

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

Quote:
> 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. ;-)

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

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

Quote:
> (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)

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

Quote:
> 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



Sat, 19 Jun 2004 09:36:51 GMT  
 Ruby/Python: Software Engineering

Quote:
> -----Original Message-----

> Sent: Monday, December 31, 2001 6:09 PM
> To: ruby-talk ML
> Subject: [ruby-talk:29910] Re: Ruby/Python: Software Engineering




> > > >     Enforced indention (you indent your own code I bet)

> > > That's a nice feature to save writing "end" all the time. But not
> > having
> > > to write "self" all the time is much more important to me.

> > That's always been a mystery to me... I enjoy Python's
> > terseness that comes from using indentation to describe
> > blocks, but it doesn't seem to reconcile with the (IMHO)
> > sillyness of writing self everywhere.

> You need some way of disambiguating nested classes (how does Ruby do
> this btw?):

>   class Outer:
>       def method1(self): pass
>       def method2(self):
>           class Inner:
>               def innerMeth1(this): pass
>               def innerMeth2(this):
>                   self.method1()
>                   this.innerMeth1()

In this example is class Inner defined in the method2 body?

In Ruby you can do this:

class Outer
  def method1
  end

  class Inner
    def innerMethod1
    end
  end
end

but the Inner class is NOT an inner class (a la Java) but a class defined in
the namespace Outer and referenced as:

in = Outer::Inner.new
in.innerMethod1

Now, that class does not have access to the methods on Outer (unless they
are class methods like:

class Outer
  def Outer.method1
  end
end

Then the innerMethod1 can execute the class method as:

class Inner
  def innerMethod1
    Outer.method1
  end
end

Or if Inner is a subclass of Outer you could do this:

class Outer
  def method1
  end

  class Inner < Outer
    def innerMethod1
      method1
    end
  end
end

- Show quoted text -

Quote:

> Etc.

> -- bjorn



Sat, 19 Jun 2004 10:19:14 GMT  
 Ruby/Python: Software Engineering
Tomasz/All:

Embedded:


Quote:

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

I am unclear: Does this mean Ruby does/might do some of the "software
engineering" things I want? If so, is this documented/enumerated anywhere?

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

Again, I must be unclear. Is this suggesting that stuffing one's program
all on one line, using variables such as one, two, three, four, five, etc.
is no different than indented code and meaningful variable names?

Quote:
>  What is readable for you is mostly function of what have you're used to
> read.

Right--but why should I have to learn how to read in an unfamiliar (not to
speak of unnatural) way?

But perhaps I am the only one who would like to program in their native
*human* language.

- Show quoted text -

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

I have no information on this. Please point me to relevant citing and I
will investigate. (And the *number* of "good programs" is unimportant--IMHO
it would be the percentage of "good" vs. "bad".)

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

I do wish there were some studies which might speak to this. Anyone know of
any?

thanks!! <<q

------------------------------
Service guarantees Citizenship
Would you like to know more?



Sat, 19 Jun 2004 12:21:26 GMT  
 Ruby/Python: Software Engineering
James/All:

Embedded:


Quote:

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

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.

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

Quote:

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

I find Python makes it simpler to write code that when read by another is
easier for them to see what I want done.

Quote:

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

Agreed--but why does this matter? Obviously anything/everything can be
misused; but that does not mean everything is then equal.

- Show quoted text -

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

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

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

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

Quote:

>...

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

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.

Quote:
>James

> > thanks!! <<q

thanks again!! <<q

------------------------------
Service guarantees Citizenship
Would you like to know more?



Sat, 19 Jun 2004 12:42:45 GMT  
 Ruby/Python: Software Engineering
Mathieu/All:

Embedded:


Quote:

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

I am not sure how to reconcile with:

   Code must be formatted to agreed coding standards.
   [ http://www.extremeprogramming.org/rules/standards.html ]

   We all code to the exact same standards.
   [ http://www.xprogramming.com/Practices/PracCodingStandards.html ]

   Develop and adopt formal style standards.
   [ http://c2.com/cgi/wiki?FormalStandards ]

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

But what about methodologies? How does Ruby help (or hinder) me there?

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

Any and all languages do both. And by being "pure"-OO does that not
restrict to a particular paradigm?

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

thanks!! <<q

------------------------------
Service guarantees Citizenship
Would you like to know more?



Sat, 19 Jun 2004 12:48:07 GMT  
 Ruby/Python: Software Engineering
Hi,

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

|  Is there any resource which explains how Ruby helps me write better code from the software engineering / methodology perspective?

I'm not sure how languages can help you write better code "from the
software engineering / methodology perspective".  You can do any
software engineering / methodology using any language.

But conciseness and naturalness of Ruby help you accomplish more with
less code, so that it leaves you extra time to make your code better
(probably using software engineering / methodology).

                                                        matz.



Sat, 19 Jun 2004 14:45:50 GMT  
 
 [ 43 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Python Software Engineers

2. Python/Zope Software Engineer Position available

3. Python for Software Engineering

4. US-WA-Vancouver-Senior Software Engineer-C++,Python,Internet,Web,Unidata

5. Software Engineering Applications of Python?

6. JOB OPPORTUNITIES - Embedded Software Engineers & Systems Engineers

7. Job-Vermont-Software Reuse Team - Software Engineer

8. ruby-python, vpython or 3D in Ruby

9. France, Paris : jobs offered : Smalltalk Senior Software engineer/Chief architect

10. FRANCE, PARIS : JOBS OFFERED : OO(C++, OMT) PROJECT MANAGER AND SENIOR SOFTWARE ENGINEER

11. Software Engineer - IBM Visual Age Smalltalk, Perl, Informix

12. US-TX-Irving Software Engineer - IBM Visual Age Smalltalk, Perl

 

 
Powered by phpBB® Forum Software