From: noone <nanotech@...>
Date: 2002-01-03T04:53:36+09:00
Subject: [ruby-talk:30073] Re: Ruby/Python: Software Engineering

Matz/All:

Ah! So I am misunderstanding, to some degree ... thanks for helping to clear this up ....

Embedded:

On Thu, 3 Jan 2002, Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "[ruby-talk:30056] Re: Ruby/Python: Software Engineering"
>     on 02/01/03, Quentin Crain <nanotech@europa.com> writes:
> 
> |   Methodologies and Tools exist independently; completely.
> 
> This statement is misleading.
> 

Ok, I misunderstood your statement; sorry about that.

> I feel like methodologies belongs diffrent level of abstraction.
> Languages (and their features) are tools, and software engineering and
> methodologies are how to use tools.
> 

When this is said, I hear that a separation exists ("different level
of abstraction").
To what degree are they separate? Are languages interchangable without
affecting how I do my work (the process)?

> If you didn't use the terms like "software engineering" or
> "methodologies", things were far easier.  Are you interested
> particularly in those terms?  Or what language characteristics
> help you write better code?
> 
> 							matz.
> 

Trying to stay away from those terms <grin!> ...

I believe I am interested in "better code" because I believe this leads to
greater productivity. But "better code" extends (IMHO) beyond my time
in-front of my text editor writing/executing. I need to take the program's
requirements as I understand them and realize them in code; how does Ruby
help? I need to test my code; how does Ruby help? I or someone else needs
to maintain my code; how does Ruby help? (Note, I also asked for
documents/links so as to read up on this and not annoy the list too much!
I seem to not have accomplished this though ... <grin!>)

Going further, since tools are intimate in the process, what constructs
was Ruby design with in mind, which are inherent in the language? This is
where/when I bring in *an* example from Python: indention. I do not mean
to suggest it is the "right/correct" way to do things (well .. indention
does seem like a "natural" thing <wink!>), but as an example of a design
decision mainly/solely for readability/understandability and not
functionality/expressiveness/power etc. I just wonder why these aspects
of language design are usually and for the most part ignored (even in
Python)?

thanks again! <<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.