SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

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

Content Type: text/plain

Peter,

"It is somewhat difficult to use an unaligned structure
containing interspersed byte-sized values and non-byte-sized
bit strings. To wit,..."

I do not argue the difficulty. I do argue into whose hands do
you want to leave the solution or the possibilities of the
solution, the programmer with his view of the solution or the
compiler writer with his view of what to allow the
programmer.

It's an attitude problem. In defining PL/I (or NPL as it was
called initially) the user community decided to give the
programmer priority over the compiler writer. As in anything
wherein responsibility rests with an individual he can make
poor choices as well as good ones. Wirth in Pascal decided to
limit the poor choices the programmer could make. PL/I took
a chance that you could rectify poor choices based on
experience, but only if you had the full option of good
choices. That means getting beyond the prejudices and poor
choices of the compiler writer.

Beyond that I don't think you appreciate just how systemic I
approach productivity. If we agree that we have a language
for the problem set (textbook language) and another for the
solution set (programming language), why can't we agree
that they have as much in common as possible? Why should
they not visually look the same such that one appears as a
dialect of the other?

Look we are already talking about gaining familiarity with a
number of different programming languages. How is it that
we can have one descriptive language of the problem set and
yet have no equivalent in the solution set? Why should we
have competing and at times incompatible versions within a
language family? Why should we have incompatible class
libraries.

If you look at open source, you have to look at reducing the
barriers to participation. Not everyone can accept the
passivity of a Steven Levine in a willingness to adapt to the
needs of the solution sets. The fact that that's the way
things are does not mean the way they have to remain. It's
reasonable to expect someone after some umpteen years of
public and private education to have some facility in the
descriptive language of the problem set. Is it not equally
reasonable that if one language suffices for one, one damn
near close to it should suffice for the other?

Productivity also arises from the learning curve, first reducing
it for a given language and second in reducing the number of
languages thus minimizing the set of learning curves. In short
why not make it possible for more people to participate by
reducing the barriers to entry?

I don't denigrate other programming languages. Like Steven
or Bob or any number of other SCOUG members I have made
the effort to program in multiple languages. That doesn't
mean that I think it's the right path to pursue for the long
term health of open source.

I agree with you on this master compendium. It's basically
what I have done over the years and most recently in SL/I to
reduce the languages to one without any loss in functionality.
The only things I give up are complication and complexity
while maintaining the most complete and best in functionality.

So I look at productivity at reducing the set of language
learning curves to one. One descriptive problem language
(which is not optional). One descriptive solution language
(which is). Two descriptive languages not far apart in
referents (objects) and references (expressions). Thus I use
the "mandatory" learning curve as the "cover" for the second.

So I reduce what the individual has to master which increases
that aspect of productivity. Then I reduce his tool set to one
tool. One language. One tool. All areas. No incompatibilities.
Minimum of effort for the maximum of output. Productivity.

If it means that one individual isolated in a cave somewhere
can nevertheless enhance his operating system, his
programming language, his tool, and his set of applications
from the simplest to the most complicated and complex, if it
means all that, then (and only then) will open source have
the individual meaning inherent in its purpose: to allow
individual independence in software development and
maintenance.

I have an ongoing career in a profession decimated by
outsourcing. Why? Because it's current tool set has
decreased instead of increased productivity. If you can't get
increased productivity, then you seek out the lower cost
producers. We are not producing applications any faster or
with greater quality, in fact both appear to suffer, but we
have a choice to lower the cost.

Thus when practicioners accept the "status quo" because by
definition that's the way it is, then we see the consequences
in something like outsourcing. They program as inefficiently
as we do with the same tool set only at a lower cost.

So I am willing in the short term to ease the mastery of "what
is" so that in the longer term I can increase the mastering
population by reducing how much needs mastering. I don't se
any sense in taking pride in having to master multiple
programming languages if we can demonstrate that one will
work equally well, if not better.

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

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.