Re: Thou shalt have no other gods before the ANSI C standard
From: rpl (plinnane3REMOVE_at_NOSPAMyahoo.com)
Date: 02/15/05
- Next message: Randy Howard: "Re: Thou shalt have no other gods before the ANSI C standard"
- Previous message: Nora Baron: "Re: A picture?"
- Maybe in reply to: D. J. Bernstein: "Thou shalt have no other gods before the ANSI C standard"
- Next in thread: rpl: "Re: Thou shalt have no other gods before the ANSI C standard"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 15 Feb 2005 11:06:34 -0500
jmfbahciv@aol.com wrote:
> In article <LIGdnbg5oNkLHYzfRVn-iw@comcast.com>,
> "Douglas A. Gwyn" <DAGwyn@null.net> wrote:
>
>>rpl wrote:
>>
>>>If I write it for PC in standard very portable PC-COBOL usage, I haven't
>>>got a snowball's chance in hell (apart from the fact that all the C boys
>>>will be trying for a one-line solution).
>>
>>That proves that you don't understand professional
>>programming. No competent C programmer strives for
>>one-liners.
<... and wearing a tie is not automatically synonymous with COBOL
programmers.>
>
>
> Exactly. I remember the PDP-10 guys having a contest to
> zero all bits in core including the registers. IIRC,
> Dave Gross finally got it down to a single bit set in
> (I think) AC0.
>
> I inherited a COBOL program to maintain where the developer
> "saved code" by calling subroutines which were paragraphs
> in the main body of the flow chart. He assumed that the
> fewer ASCII characters in his source would produce "faster"
> executables.
<hmmph>
</soapbox>
it's called "Structured Programming" and the short version is it makes
for ***much*** more maintainable code in applications programming.
Instead of 10% of your time developing code and 90% patching it up so it
might make it through testing, you spend 90% writing and 10% debugging
(mostly typose).
The long version is the same as the short version...
If two "black belts" use the same S/P methodology then their flowcharts
for the exact same program will look *exactly* the same. As you can
imagine this comes in pretty handy on anything over a couple thousand
lines. If you combine that with departmental naming standards then the
source code will be identical, too. (I'm referring specifically to a
JSP/COBOL sheaf of problemsets, you Yourdonites take way too many
chances as far as I can tell <g>).
Not particularly directly applicable to anything that has to be written
bottom-up though (though I imagine there are definitive techniques for
that as well (Dykstra?) and I'm sure there's overlap)
Think of it as an uber-algorithm.
</soapbox>
Anyways, if it was COBOL (anytime after '68 I think) then those were
PERFORM statements not CALLS (internal flow control, no parameter
passing). Though if subroutines are calling a mainline paragraph then
that's just wrong (possible exception of fatal-error handling; even then
it's sloppy).
Oh, btw, code reuse makes for less swapping as well as "one-stop
shopping" writing/debugging/maintenance. The tradeoff, at worst is a
little extra runtime object code in flow-control (well worth it in
non-time-critical loops).
COBOL problem-set programming is always top-down(start with a customer
need and work your way down)... your guys were bottom-up (start with
hardware and build upwards). I imagine somebody was trying to make a
point of some kind(?)
rpl
(had a student whose company sent along some sample maintenance for him
to do (and for us to administer) on top of our course materiel. Despite
the potential added revenue, both my boss and myself said "No; that
one's a rewrite" and sent it back heavily annotated with choice
comments... it wasn't a test for the student though; we ended up writing
their IS standards.)
- Next message: Randy Howard: "Re: Thou shalt have no other gods before the ANSI C standard"
- Previous message: Nora Baron: "Re: A picture?"
- Maybe in reply to: D. J. Bernstein: "Thou shalt have no other gods before the ANSI C standard"
- Next in thread: rpl: "Re: Thou shalt have no other gods before the ANSI C standard"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
