SCOUG-Programming Mailing List Archives
Return to [ 08 |
March |
2007 ]
Content Type: text/plain
On another OS/2 mailing list (Hercules2) I read a response by
Peter Flass who disclosed his ongoing effort to write an OS/2
PL/I compiler. As we have to do essentially the same plus in
our effort I invited him to subscribe to this mailing list. I can
only hope I haven't scared him off with some of the "radical"
aspects of our "single tool effort".
As a career "systems", something more than a "pieces",
engineer I am as concerned with how pieces work together
externally as well as internally. In looking back on IBM's
perceived failure in its AD/Cycle attempt to have proprietary
software vendors provide interfaces to their products it failed
for the simple reason that it might work. The implications of
its doing so became quite clear to the vendors that they
adopted a form of passive resistance, deferring to their
competitors in a "you first, no you first" political "no one first"
effort. Because they didn't produce the interfaces to the data
repository, which was IBM's responsibility to produce, they
turned it from their unwillingness to IBM's inability.
Let's be clear on this point. Users engaged in selecting
products that supported "segments" of the software
development process (SDP) had an implied seamless fit of its
five stages (specification, analysis, design, construction, and
testing) but no corresponding seamless fit among the
available segments. Thus in going from one to the next the
user had to in some manner make the connection. That meant
despite the productivity each tool offered for its segment the
aggregate of any two and particularly the sequence from
beginning to end of the SDP lead to an aggregated loss of
productivity. It took more to mesh the tools than was gained
in their use.
IBM in response to its user community proposed a "voluntary"
means in AD/Cycle to have vendors cooperate in interfacing
their products such that the users could make a "seamless"
choice. That would allow them to aggregate the productivity
of their vendor choices.
However, what the users perceived as a "win" the vendors
quickly came to perceive as a "lose". It opened them up to
competition outside their product segments in addition to that
which they already faced from their existing competition
within their product segment. Depending upon whether you
were licking your chops to expand your segment or afraid of
the possible wounds from those, it developed into an endless
waiting game to see who would venture first.
Notice the different approach IBM has now taken with Eclipse,
guaranteeing protection to proprietary products. Note that
ours is not the only single language approach to offering an
alternative more in line with the goals of AD/Cycle than
Eclipse. Among them are tunes.org and maude
(http://moment.dsic.upv.es/mfw). It makes clearly distinct the
great divide between open- and closed-source perspectives
when you no longer have a divide between users and
developers (vendors).
Now assume that you can have as seamless a fit among
segments as you have by implication among the stages of the
SDP. How much of a stretch is it to believe that among the
set of "seamless" choices lies one whose productivity is
exceeded by no other? That a best choice exists?
Moreover does not the "seamless" also imply a more complete
and single form of IDE inherent, but more efficient, than that
currently underway with Eclipse? Does not that "seamless"
fit allow for further reductions to essentials, to a simplification
of the process, that leads to an even more aggregate
productivity?
Why believe that the Developer's Assistant is any less an
attempt at the most efficient, most productive IDE? It differs
from existing IDEs like Eclipse in that its base lies in logic
programming, the use of a two-stage proof engine, in which
only one source is needed for all possible visual outputs.
Except for the "initial" source specifications by the developer
the remaining global writing (organizing) and rewriting
(reorganizing) along with "selected" visual outputs occurs
through software (not people). You only create and maintain
one source in one language in one library (data
repository/directory) and yet can request all the different
visual outputs (a la flowcharting programs) for which users
now must write and maintain separate source code.
All of this exists today. We have vendors who offer the
ability to produce UML documents from source just as some
vendors early on that it is as possible to generate flowcharts
from source code as it is source code from flowcharts.
Certainly the "seamless" fit of fourth generation HLLs like
SQL, Prolog, Trilogy, et al using logic programming exists
where the software takes on the responsibility for analysis,
design, construction, and testing.
Thus why can we not propose an optimal IDE with maximum
productivity? We're open- not closed-source. We have no
territory to protect. Instead we have an expanded territory
to adopt to our needs. We can make AD/Cycle a reality with
respect to what it logically should have produced: a single
tool which optimizes human software productivity.
There you have the heart and soul of the Developer's
Assistant.
=====================================================
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".
=====================================================
Return to [ 08 |
March |
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.
| 
