SCOUG-Programming Mailing List Archives

Date:	Wed, 21 May 2003 16:06:24 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Tier pressure

Content Type: text/plain

What I don't like about C came out what's wrong with "int". I
called it the ""int" factor". I could have as easily called it the
""int" deceit" relative to how it confuses the mapping of the
solution set into the problem set. I do hope, however, that
you can appreciate the difference on a 20-bit binary machine
of saying "fixed bin (20)" instead of "int" when you transfer
the source code to a 32-bit machine. You see the difference
lies is having both source code and data portability.

That's not the portability that K&R had in mind for C. To them
portability meant easing the task of implementing the core
language: writing the compiler. So they designated much of
what was included in "legacy" programming languages as
"unnecessary". This included things like variable precision,
fixed point decimal arithmetic, file i-o, exception handling,
builtin functions, bit strings, and aggregate operands.

These "unnecessary" items complicated, i.e. made more
difficult compiler writing, thus impacting the "porting" of the
language across machines. If you wanted any of these
"unnecessary" items, well, you could add them as separate
library functions. The fact that the implementers of these
non-standard libraries did not port them across machines
made the applications, as well as the data, non-portable.

Now we write applications in a programming language as tools
to increase the productivity of users. We expect a very high
ratio of tool users to tool makers, in this instance the
application programmers. Thus any extra effort, i.e. function,
in the application to ease the task of the user has a multiplier
effect in terms of productivity. In short whatever extra effort
goes into the application is more than compensated by the
increased user productivity.

So we have at least two tiers of tool users, those who use
applications written by those who use the tools to write them.
I hope it equally obvious that an extra effort on the part of
the tool makers to increase the productivity of the application
programmers means reducing the extra effort needed to
increase the productivity of the application users.

Logically then for maximum productivity "upstream", i.e. the
tool and application users, the tool makers should maximise
the included function. K&R in C took the exact opposite
approach. They further bragged about the portability of C,
i.e. the compiler, as if it had the same portability for
applications (or data) written it C. It didn't as a vast horde of
UNIX users discovered to their chagrin, which remains today
despite their getting together in the Open Systems Foundation
(OSF) to standardize C.

The core failure lies in "int", the most copied feature in every
programming language since. Every one of them shares
this mismatch between the problem set and the solution set.
It doesn't take considerable effort to show that the same
mismatch occurs with string variables: instead of mapping the
solution set conform to the problem set we alter the problem
set to conform to the solution set, e.g. the null-terminated
string.

So we have this two-tier system, consisting of a tool tier upon
which an application tier depends. In reality we have two
application tiers as tools themselves exist as applications as
applications exist as tools. As application programmers we
continually improve software to replace or reduce clerical
efforts on the part of our users, thus increasing their
productivity, in a business sense decreasing their per
transaction people cost.

The ease with which we can do this, in essence our
productivity, depends upon our software tools to reduce or
replace our clerical effort. The more effort our tool makers
put into achieving this, the lower the per unit transaction cost,
i.e. less effort and time, we achieve in doing the same for our
users. Legacy systems tools (programming languages)
evolved with this concept of increased productivity. The
introduction of C not only brought this to a halt, but in fact
introduced a regression from which the UNIX community has
yet to recover.

Now C or C derivatives dominate open source development
whether C++, JAVA, PERL, PHP, or Python. We have a need
to understand these in order to provide the fullest open
source support and participation. We need to use our
understanding to improve our tools to increase our
productivity. In so doing we will increase the productivity of
the open source community as a whole.

We should do this by insuring that the solution set conforms to
the problem set. The needs of the problem set determines
the functionality of the solution set. It should in the
applications we write for our users. Equally it should in the
applications written for us, our tools, so that we can transfer
the savings onto our users...even when they turn out to be
us.

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

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 [ 21 | May | 2003 ]

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.