Tomasz/All:
Embedded:
At 09:05 AM 1/1/2002 +0900, Tomasz Wegrzanowski wrote:
>On Tue, Jan 01, 2002 at 07:06:38AM +0900, noone wrote:
> > > 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?
> > > 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?
> 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.
> > > 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".)
>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?