SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sat, 1 Jan 2005 23:03:13 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A bit too much to byte

Content Type: text/plain

We have a concept of level of abstraction. That implies that
multiple levels exist, that a lower level offers detail than the
higher level it represents. The expression " a = b + c;" is
deceptive. In C, for example, it is limited to element variables
of the same data type. In PL/I it supports aggregate as well
as element variables with mixed data types.

Basically it says "add b and c, placing the result in a". It says
this regardless of element or aggregate variable or data type.
The aggregate form in C requires introduction of a iterative
control structure which does an element by element detail,
again on identical data types only.

Now Peter would say it "reads" easiest if you have the same
data types throughout and easier if you prefix routine names
to parenthesized variables when data types differ. It certainly
does read differently. It may or may not be clear to the
reader why the bother on data types, if in fact the same
"abstract" pattern occurs. Why do you have to concern
yourself with data types on one and not the other. To
understand why the reader has to refer to some other
reference beyond the expression.

While I may agree that readability counts more than initial
effort, i.e. development, experience that the major cost over
time lies in maintenance. Certainly readability has an impact
on maintenance, but a far greater impact arises from the
globalization of change, the ability to synchronize change and
logic across the routines within an application and across a set
of applications. That cost does not lie within the programming
language used as much as a dependence upon the use of files
for program source, copy books, etc.. That cost arises due to
the inability to compile more than one programming unit at a
time. That's not a language limit, but a historical and artificial
one imposed on the compilation process.

While we dicker over this programming language versus that,
over this programming style versus that, over what's good
code and what is not, we are getting killed by our tool set. It
restricts to maintaining individual files and to compiling
changes on a single, logical program unit at a time. While we
may attempt to reduce this by compiling program units in
parallel, this in itself due to lack of synchronization and
globalization of change can introduce further errors into the
process whose detection and correction introduce delays and
increased costs.

It's not the language. It's the tool set. It's the artificial
restrictions retained from an earlier environment far more
resource constrained than what exists today.

=====================================================

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".

=====================================================

Return to [ 01 | January | 2005 ]

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.