Did I write a good (efficient) program?

In article <57qIj.23163$0o7.2366@newssvr13.news.prodigy.net>,
Michael Mattias <mmattias@talsystems.com> wrote:
>You know, I've always used three tests to decide if code is well-written:
>
>1. Does it work?
>2. Is it *relatively* efficient?
>3. Is it maintainable?
>
>You need a "yes" answer to all three questions to have well-written code.
>
>While 'works' is non-negotiable, I'll often often trade 'ultimate
>efficiency'  for maintainability; e.g., "ultimate" efficiency can often be
>best achieved by using lots of GO TOs; but this comes at a maintainability
>cost I am generally not willing to pay.

Where has this been talked about before... ahhhh... from
<[url]http://groups.google.com/group/comp.lang.cobol/msg/5f032ffb073f4861?dmode=source[
/url]>

--begin quoted text:

(T)hat is a Major Source of Debate, I believe... the more that code caters
to hardware functions the more efficient it is... and the less
structured/maintainable/portable it is.  You makes your choices, you takes
the results.

[snip]

All that aside I rarely concern myself with what others think... no matter
what one does there are those who will say that one is a hidebound
dinosaur and others who will say that one is a slave the the
flavor-of-the-month.  If program-runs perform next-assignment else perform
code-like-hell until damned-thing-works... don't get much plainer than
that.

--end quoted text

DD

On Tue, 01 Apr 2008 12:44:49 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>1. Does it work?
>2. Is it *relatively* efficient?
>3. Is it maintainable?
>
>You need a "yes" answer to all three questions to have well-written code.

Of course, the industry has changed considerably - which has changed
how we grade these.

"Howard Brazee" <howard@brazee.net> wrote in message
 news:qbi4v3lh2qh46k37lsl1v3pg0f4jppaod8@
4ax.com...
> On Tue, 01 Apr 2008 12:44:49 GMT, "Michael Mattias"
> <mmattias@talsystems.com> wrote:
> 
>
> Of course, the industry has changed considerably - which has changed
> how we grade these.

I don't about "industry" but I have always weighed 'maintainability' very,
very heavily: When was the last time you saw a program which NEVER was
upgraded/enhanced/changed?

MCM

On Tue, 01 Apr 2008 16:04:49 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:
 
>
>I don't about "industry" but I have always weighed 'maintainability' very,
>very heavily: When was the last time you saw a program which NEVER was
>upgraded/enhanced/changed?

I weigh it heavily as well - the atomic size of our components
changes.    When maintenance can be done by pulling out one module and
plugging in another, we get an "A" by making that module easy to
access and replace.     Actually fixing that part isn't as important
as it once was.

This process of change is at least as old as interchangeable parts in
the industrial revolution.

Richard <riplin@azonic.co.nz> wrote in message
news:ee588146-8f0f-44cf-9674-51a4037ecdf9@s37g2000prg.googlegroups.com...
On Apr 1, 3:40 pm, Robert <n...@e.mail> wrote: 
told us to stop. We 
> 
> 
needs to be 

>Just you then is it ?

That's uncalled-for.  Any programmer worth his thinking cap does this sort
of thing automatically - for instance, making sure that calculations that
don't beed to be inside a loop are moved outside it; or using a single
variable to hold the results of a complex calculation rather than
reiterating the calculation itself ... and so forth.

PL

"MikeB" <MPBrede@gmail.com> wrote in message
news:408bb0cb-b47e-43b4-b4f0-b604d6c36a3e@p25g2000hsf.googlegroups.com...
> I haven't written COBOL in a number of years and am quite rusty.
> Recently someone asked my help to write some code to display an IP V6
> address in human-readable code. I wrote something, but am not sure if
> I used the best available techniques. Please have a look at what I
> wrote and feel free to comment.

Having taken the time and made the effort to truly
understand the problem and how it may be solved,
I find that the "best available technique" for obtaining
the numeric value of a character is the use of the
intrinsic function, ORD.

As for the balance of your program, I found no
technique that is necessarily better than what you have
done.

> Thanks.

You are welcome.

>>> On 3/31/2008 at 8:40 PM, in message
<c463v3p7pdl8dc6dl5seo7j6u0mfrev3qr@4ax.com>, Robert<no@e.mail> wrote:
> In 1973 everything (except files) was fixed length. We used fixed length
> strings, numbers,
> arrays, records and blocks in files. Now, outside Cobol, most things are
> variable length.
> The next Cobol standard proposes adding 'any length' data items and
> arrays. The Old Guard
> are opposed.

Is anyone here a member of this Old Guard that is opposed to variable length
strings?  I certainly am not.  I would love them.

Frank

"Richard" <riplin@azonic.co.nz> wrote in message
news:ee588146-8f0f-44cf-9674-51a4037ecdf9@s37g2000prg.googlegroups.com...
<snip>

I can't recall _anyone_ claiming that ODO is 'too slow'. In most cases
they were completely indifferent to whether it was faster or slower.
They just made stuff work and left it to the CPU to get it done.

You seem to have this idea that every argument is either black or
white. If they don't flock to follow what you do then they must be
doing the extreme opposite.


<snip>

[Pete]

Robert, I think this is very fair and, for me, goes straight to the nub of
the problem that some people here have with your posts.

I'm not getting involved in your specific argument here, but I definitely
think you could benefit by thinking about this.

I find your posts and ideas very valuable, and sometimes what you post is a
different insight into something often taken for granted. I like the way
that you challenge old ideas and we need that. However, Richard is right on
the button with this observation; inasmuch as you DO seem to see black and
white only, when most of us accept shades of grey.

Certainly, a forthright position has more impact and is often easier to
maintain, but if it makes you overlook the actual responses you elicit, then
it is counter productive.

Think on it :-)

Pete.
--
"I used to write COBOL...now I can do anything."

"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:B2tIj.20982$xq2.2197@newssvr21.news.prodigy.net...
> "Howard Brazee" <howard@brazee.net> wrote in message
>  news:qbi4v3lh2qh46k37lsl1v3pg0f4jppaod8@
4ax.com... 
>
> I don't about "industry" but I have always weighed 'maintainability' very,
> very heavily: When was the last time you saw a program which NEVER was
> upgraded/enhanced/changed?
>
I have dozens of them :-)

They're called "components"...

Each of them represents encapsulated basic functionality that simply doesn't
change. They are building blocks, just like atoms or bricks; you don't
modify the structure of the atoms to make a different molecule; you just
combine different atoms differently (or add some new ones).

Components that access or maintain data are most likely to be "volatile".
That's why I use an n-tier approach to system architecture. Components in
the DB access layer are virtually "cannon fodder" and can be replaced or
extended very quickly. (In fact, I am currently evaluating tools that will
automatically generate these components whenever I change the DB
design...There are some staggering tools available...)

It was this that led me to consider interfaces very carefully. Most of the
time, if you change an interface (maybe add another parameter or parameter
value) it has a serious effect and requires regression testing. If you can
avoid changing the interface you can avoid much of this grief. As Object
Classes can be forced to generate automatic methods for accessing and
setting their internal properties, this means I can change parameters
without changing interfaces. This allows me the option to "activate"
existing functionality that was built in by "up front" design (part of a
GENERAL rather than SPECIFIC solution, or to add new behaviours  by
overiding or extending existing methods in a new subclass. (This allows
"evolutionary" design rather than "up front" design.) I can use either or
both design approaches, and I never need regression testing.

(It would be VERY difficult to implement such an approach, WITHOUT using
Object technology...)

Only the control elements that invoke the new or modified functionality need
to be tested.

Pete.
--
"I used to write COBOL...now I can do anything."

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:65folmF1f605pU1@mid.individual.net... 
> I have dozens of them :-)
>
> They're called "components"...

Applications programmers (eg, moi) don't think in terms of "components";
strangely enough, we think in terms of "applications."

I guess that explains as well as anything why it is 'systems' programmers
are the ones who just couldn't cut it in applications.

MCM