SCOUG-Programming Mailing List Archives
Return to [ 16 |
February |
2004 ]
<< Previous Message <<
>> Next Message >>
Content Type: text/plain
"Sounds like an argument for spaghetti code. I prefer to
"think high level and implement appropriately."
That's your second reference in these responses with respect
to spaghetti code. I didn't understand your reasoning either
this time or then. Structured programming alleviates, if not
eliminates, spaghetti code regardless of programming style.
The very fact that you have to think inner block, outer block
takes you down from the high level you mistakenly believe
you're operating from.
I have no argument with Greg's code except that it violates in
terms of consistency with his remarks about marking the
beginning and end of code segments associated with a
calculation. You can't use begin-end when you need to carry
results from one marked segment into another. He knows this.
You know this. I know this. However, I seem to be the only
one here willing to say that I have to write code, i.e. program,
with that knowledge in mind. I have to do it regardless of my
background in some other area.
"...Note that he's only using _one_ BEGIN block. ..."
Again he has two calculations, one in a begin-end code
segment another not. Why say you prefer to mark the
beginning and end, which is an admission that you explicitly
know both, do it in one instance and not in another? It's
because it will not work. He knows that. He knows it at
something other than a "high" level as the devil is in the
details.
"...It's more organized. The compiler can catch errors
better. Less housekeeping for the programmer. No chance of
allocating new stuff before deallocating old stuff. ...'
Let's see. Wrong. Wrong. Wrong. Right. There's also no
chance if you 'allocate' instead of 'begin' and 'free' instead of
'end'. There's a difference in readability, however, which only
concerns one of us.
"...List processing is possible but it executes more slowly.
Think about the actual machine code difference between
calculating an index vs. maintaining a B-tree of pointers."
I'm willing to show you what I grow in my garden, if you will
own up to what you've been smoking from yours. An index
assumes a linear sequence of contiguous, fixed-length items
into which no inserts or deletes occur. It's like your use of
begin-end. If you want to live with those restrictions, that's
your business. However, getting from list entry linked to
another is a 'load address from storage'. Other than possibly
an 'add immediate' you haven't a calculation in hell that can
take less time. I find it doubtful that you can complete any
calculation of an index sequentially or randomly in a single
machine instruction.
When I don't know either the order or number of input entries
I use list processing to give me both. I use 'allocate' to insert
an entry and 'free' to delete. I know what I am doing and
when I want to do it. As I would have to know it where a
begin-end might be used, I prefer to use the former as it
works where the latter doesn't. It also reduces the
maintenance needed to accommodate different global logical
changes.
Due to the nature of 'based' variables, essentially their use as
a floating template, I can redefine and reuse allocations
without restrictions. I have no need for the 'union' of C. That
it places a greater responsibility on me is the price you pay
for freedom. I'm not shy about knowing what I am doing. No
lofty perch for me.
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 16 |
February |
2004 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
|