SCOUG-Programming Mailing List Archives
Return to [ 26 |
February |
2007 ]
>> Next Message >>
Content Type: text/plain
Michael,
Thank you for the reference site on PL/I. I suspect this list
has a number of non-SCOUG members. We welcome them all
and encourage them like you to feel free to participate and
contribute. As someone who has held the role of PL/I
"advocate" (user and instructor) since its public
announcement in 1964, I have too many experiences with
other programming languages which has only enhanced my
appreciation for PL/I. I hope other readers of this list will take
advantage of the referenced site, particularly anything which
does a comparison between C and PL/I. Maybe at some point
they will begin to realise the seriousness of the "int" disease.
In offering a solution you need to understand the problem. In
the message to which you responded I addressed the issue of
backlog, where change requests get queued up and
accumulate because we cannot respond to them on average
as fast as they occur.
Historically we have treated it as either a language or a
process problem. Thus we have move through four
generations of languages, three imperative (first, second,
third) and one declarative (fourth).
For reasons we need not go into at the moment the industry
backed away from the fourth generation to concentrate on
the third and adapt an "innovation" by one of its
third-generation HLLs, Smalltalk: object programming based on
embedding "methods" associated with the processing of data
objects (classes).
This supposedly offered two things. One, the ability to
concentrate data maintenance control so as to reduce the
number of change instances. Two, a higher level of modular
usability, thus moving closer to the plug-and-play of
manufacturing.
Somewhere in all this they introduced the "crippler" which
today we refer to as "inheritance", method inheritance. This
assumed that data objects (classes) often had the same
methods (routines) associations. Rather than provide a means
of associating a given method with all its data objects or vice
versa, i.e. associate a list of data objects with a method or a
list of methods with a data object, they chose instead to
create a class hierarchy in which lower level classes could
"inherit" the methods of their parents.
Actually that's not quite accurate. We had a battle of parents
early on over whether a class had one or two parents and in
some instances even more. Well, the single parent won out.
The effect was that unless two competing class libraries had
the same class hierarchy with the same methods associated
with the same level an incompatibility existed. This as
everyone experienced with the history of IBM and Microsoft
knows lead to a war of class library war.
The experience of this with the C++ arena and the damage it
wrought lead to the standard class library introduced with
JAVA. That solves one problem of incompatibility.
However, in the early stages of OO another problem arose in
the area of analysis and design, the area of CASE tools. Here
three major players with separate methods came to compete.
Fortunately the using community didn't care for this form of
competition and forced the three groups to somehow merge
their methods. They did. The result was UML, the "Unified"
Modeling Language.
I put the quotes around the "Unified" to point out the
difference between it and "Universal", of which UML falls far
short. While it was nice to have one method instead of three,
that method offered 16 different source forms in terms of
documentation. Compare that to the 2 forms previously of
dataflow diagrams with its four symbols: input, output,
datastores, processes and structure charts with its single
symbol of process.
In effect OO with UML increased the upfront effort, thus
increased the cost and time involved in software development.
Instead of helping resolve the backlog problem it increased it.
Thus OO overall has increased software development and
maintenance costs, i.e. lowered productivity. That's the
opposite of what its advocates claimed it would do.
The OO advocates attacked the "classical" waterfall sequence
of the software development process (SDP): specification,
analysis, design, construction, and testing. In retrospect it's
hard to understand why when in effect they adopted it into
their process.
Let's be clear on this point. You cannot argue the SDP, either
its sequence or its components. You can have them overlap
and operate in parallel, have one begin before the other ends,
but the represent the minimal set of activities which must
occur.
What you can argue is who does the activity, people or
software. All imperative languages require that people
engage in all the activities. Declarative languages, those
using logic programming, require that people engage only in
two of them, specification and testing. Even in the instance of
testing two logic methods, causal and predicate, predicate
offers minimal user effort. The use of predicate logic means
the "major" human effort goes into writing (and rewriting) of
specifications. That means the ability to develop and maintain
a single source in a single language, leaving it as software
option to produce any and all of the different possible output
reports from that source once organized by the software.
That's how you eliminate the backlog.
=====================================================
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
"postmaster@scoug.com".
=====================================================
>> Next Message >>
Return to [ 26 |
February |
2007 ]
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.
| 
