Conversation about PL/I, history, future etc.
WRowe0521
This was originally intended to be a comp.lang.pli discussion in the
"History of PL/I Maybe" thread, but it accidentally became a private
conversation. We thought it might be generally interesting, so we edited
it into a dialogue and posted it.
Robert Barnes, Bill Rowe:-
Bill (WRow...@aol.com):
"Ironically, the language became popular in Great Britain because that
country is always a couple of years behind the US (at least in those
days), so projects there got the debugged compiler (note that many
contributors to this newsgroup are from the UK.) Here in the US, I think
most of you will agree, PL/I has never attained the popularity it
deserves. The fault lies not in the language, but in its early failure to
establish itself as the natural successor to COBOL."
Robert (Rob...@voyager.co.nz):-
"This is consistent with my belief for the reason that COBOL beat out
PL/I.
"In the early 70's, and once the early PL/I-F compilers had receded into
memory (halleluiah) there is little doubt that PL/I was technically
superior to COBOL for those working on IBM S360-370 systems, having most
(but annoyingly, not all) of COBOL, Fortran, and Algol within its scope.
There were studies claiming between 1.5 to 10 fold productivity
improvement (compared to what I'm not sure), and I believe that with new
programmers you'd usually get improvements cf COBOL of about 1.5-fold for
"COBOL-domain" problems, on top of the 3-5 fold improvement from Assembler
to a 3GL. This could be sufficient to persuade you to switch from
Assembler to PL/I rather than from Assembler to COBOL, but if your company
already had an investment in COBOL it was insufficient to justify the
introduction of another language with all the incompatibilities and
duplications that this would imply. Because the US was ahead of the UK in
the use of computers, within the UK PL/I was available (and not TOO buggy)
before there was a substantial COBOL investment."
Bill:
"Judging from my experience as a long-time PL/I contract programmer in the
business world, the reason may be that COBOL is not really a 3GL, in the
sense in which PL/I, C, FORTRAN and Pascal are, so the move to PL/I is
traumatic. Most COBOL programmers who make the transition treat PL/I as if
it were another form of COBOL, as though its designers didn't really know
what they were doing. For this reason I would regard comparative
productivity figures with great scepticism, since you will only get the
benefits if PL/I, or any other language for that matter, if you use it as
intended. I have run into PL/I people who are surprised to learn that
variables can be declared within procedures and functions, and have had to
have PL/I's scoping rules and the difference between STATIC and AUTOMATIC
explained to them; I doubt that most of them know the difference between
call-by-reference and call-by-name, and in any case could not say which of
those was implemented in PL/I. I have met PL/I programmers who don't
believe that recursion is possible."
Robert:
"Sad, isn't it? There is so much in the language to make life easier, and
yet it's largely ignored.
"A few years ago it was very popular to train people on Pascal as their
first language. I had hoped that this would address exactly this problem,
leading to a cadre of programmers who understood scope and data modelling,
and so adapted to PL/I very easily and used it well when they left college
and needed a real language. This has not happened
"It's not only ex COBOL programmers who are guilty of abusing PL/I. In the
early days IBM produced a series of manuals "PL/I for the Scientific
Programmer" and "PL/I for the Commercial Programmer" which were designed
to ease Fortran and COBOL programmers into PL/I. Naturally they promoted
the writing of Fortran or COBOL within PL/I syntax. I have also seen
Algol programs written in PL/I."
Robert
"To achieve good results in ANY programming system (including a 4GL but
especially an OOPS) it is vital that the task be properly segmented. This
is not just avoiding GO TO and putting code into procedures, but ensuring
coherency of the procedures with minimal (and well defined) data
relationships with the rest of the world. The key is MINIMAL INTERACTION -
not only single entry/exit, but more importantly the minimum amount of
data communication. External procedures are better than internal
procedures: internal procedures should have as much as possible local.
Bill:
"I couldn't agree more; this is a far more important principle than 'don't
use GOTO', which is repeated endlessly like an invocation to ward off
evil, even though GOTO-free programs repeatedly turn out to be bug-ridden
and difficult or impossible to maintain. I would argue that minimal
interaction is not a technical necessity, but a psychological one.
"If you knew that you were about to write a program that, once compiled
and tested, would never go wrong and never need to be changed, then it
wouldn't matter what style you used (as long as efficiency were not a
factor). But this never happens. Understanding an unfamiliar program,
even one of one's own, for the purpose of debugging or enhancement, is a
central activity of all programmers' lives. And because of the failure of
project leaders to impose sensible coding standards from the outset,
including adequate documentation, it is the greatest time-waster. I've
given up trying to explain this to project leaders".
Robert:
"Yet I remember a heated argument with a project leader who wanted to keep
everything as one compile unit "so that everything was kept together".
Only the fact that compile times started heading towards 30 minutes when
they were about 1/4 of the way through the coding persuaded them to go
external. BTW, the macros given in my book (LISTBUILD etc) were developed
to save this particular project - they were developing their (by now
external) list management routines by copying code from the first routine
and editing it. Shame that it was incorrect!
Bill:-
"I take your book with me when I go on contract (right now I am resting
between contracts) but for the most part use it only to play around with
PL/I's interesting features, most of which I could not include in my
programs without causing grievous mental confusion to some of my
co-workers.
"I would go as far as to speculate that the theory behind COBOL, that the
average Joe who can write a page of English can master programming, has
had a deleterious effect on the whole industry, turning what should be a
technical profession into a glorified clerical occupation, with
consequences we are now seeing in the great difficulty some shops are
having making the transition to C/C++."
Robert:-
"The trick is to choose a data model that closely fits the situation, and
then use programming techniques that support that data model. If you
really do have a recursive, or list, data structure, then programming with
COBOL-like techniques will be very difficult, and will build in errors
(for example, filling your program with "magic numbers" such as array
bounds). My belief is that it is easier for a programmer to learn an
advanced technique and apply it, than to kludge (can "kludge" be "verbed"?
Can "Verb" be made into a verb?) an inappropriate technique. The real
skill is in knowing which technique is appropriate. Of course many of us
have been guilty of using fun techniques when they are quite unnecessary
(mea culpa). C++ shows us that nothing has changed."
"My own experience was that PL/I would make a good programmer more
productive, but the programmer who had struggled through their COBOL
course and could barely cope with that became almost completely
unproductive. I'm aware of many nightmares of the time, and they seem to
be equally split between COBOL and PL/I."
Robert:
"My impression is that the reason why PL/I's popularity suffered was
primarily because it was not widely available. PL/I wasn't even available
on all IBM systems, so that if you needed, even potentially, to work on
systems other than MVS and DOS/VSE (or their forerunners, OS/360 and
DOS/360) then PL/I was simply not a viable choice. For example, I seem to
remember that Kodak were initially PL/I users when they used my (then)
company as a bureau, but then when they put in their own computer, a
System/3, they had to use RPG. With the advent of 4GL's less and less
application development was done in either COBOL or PL/I, and most
packages were written in COBOL, hastening the demise of PL/I except in a
few large mainframe users where the flexibility of PL/I has allowed it to
retain a niche in some legacy applications.
"(BTW: a legacy application is "any application that has actually been
successfully implemented")
"Here in New Zealand there has been a substantial abandonment of PL/I, and
COBOL too is dying. Yet we still lack a language with the scope
(Commercial, Scientific, System programming) of PL/I, and I see nothing on
the horizon. Today's imperative is to be able to program client/server
systems with GUI interfaces: we seem to be forced to use an uneasy mixture
of Visual Basic, C++ (yetch!!!), and various 4GL languages, as there is no
adequate language which is available across the range of platforms
involved in a client-server system. If IBM's Visual PL/I were good enough
to compete with Microsoft's Visual Basic within a Windows environment, and
yet also be available across a range of platforms and be supported by
enterprise-level development tools, then it could become quite exciting
again."
Bill:
"In the comp.lang.pl1 newsgroup there appears to be the general belief
that PL/I is on the verge of a renaissance simply because new compilers
are being written. This alone will not guarantee success; even with IBM
behind it, OS/2 has always played second fiddle to Windows, despite being
well-regarded by its users, and receiving favourable reviews in
Computerworld. I wish they were right, but there is no sign that they are,
on the contrary, according to Computerworld (survey of 1,700 companies,
Jan 2, 1996), 59% of PL/I shops in the US and Western Europe are planning
to move elsewhere, and only 23% declare themselves satisfied with the
language.
"Take a look at http://www.mey.nl/eyrep/survey.htm. This is the web site
of a Dutch firm that makes a PL/I to COBOL converter, and uses the study
to justify its product to clients; if you email them they will send you a
copy of the survey, so they say; I tried it, but nothing has arrived so
far. Maybe you have to declare yourself a project manager. This is what I
found on the website:
"Neaman Bond Associates (the marketing services partner of Butler Bloor
Ltd.) has conducted an independent survey regarding the usage of PL/I and
its future within over 1700 PL/I sites in Europe and North America.
According to a recent market survey by Neaman Bond Associates, 59% of
PL/I users intend to move away from PL/I.
"Mail:
Ernst & Young RE Products bv
P.O.Box 3101
3502 GC Utrecht
The Netherlands
Tel: +31-30-2588345
Fax: +31-30-2588747
E-mail: ey...@mc.mey.nl
"Judging by the COBOL to PL/I example they give, you would think their
customers would decide to stay with PL/I (though this may be an artifact
of the conversion process)."
Robert:
"I agree with you, unfortunately. Thanks for the survey results: it helps
me to make up my mind that it would not be cost-effective to produce "PL/I
for Windows Programmers" as a sort of second edition to "PL/I for
Programmers."
"I have been a bit depressed with the comp.lang.pli dialogues. The
discussions are mainly at a very low level of language detail, and it
rather feels like discussing how many angels can dance on the head of a
pin while all around the church is crumbling. PL/I has a foundation on
which something really exciting could be built, but we buy houses, not
foundations, and I don't see the plans for the mansion it could be.
"I tried to spark a debate on "where is PL/I going" in comp.lang.pli to
see if others agreed with me, but most of the replies that I got were
quite low level. Some programmers even seemed to object to my assertion
that PL/I should have a DATE data type - perhaps they felt that
flagellation and wearing hair shirts is good for the soul!"
"PL/I could be competitive with Visual Basic and Powerbuilder, if IBM (it
has to be IBM - only IBM and Microsoft have the resources and credibility)
were to
1/ Make Visual PL/I widely available (Windows/NT, W/95, UNIX, as well
as OS/2). It has to be not only the language of choice for client/server
systems spanning MVS and Windows, but also the language of choice for
simple PC-only systems.
2/ Make it compatible with VB etc, so that the VBX's and OCX's
developed for VB, Delphi, and C++ systems can be used. There is simply
too much investment in these add-in controls (grids, graphs, outlines,
etc) to ignore.
3/ Provide a programming environment with editors, test managers,
debuggers, etc, that is competitive with Delphi, VB and Powerbuilder
4/ Extend the language, particularly with much better data model
awareness. The EXEC SQL approach, with cursors and appalling (=no)
coupling to the DBMS information, is simply inadequate in the age of
4GL's. PL/I must directly use the Database description.
5/ Mount a significant promotion to establish PL/I as the best tool
for developing C/S and stand-alone applications.
"#1 is there (although I don't think Visual PL/I is available in Windows
yet), but I don't know about the rest.
Bill:
"Of the 5 points you make, #5 seems to be the most important i.e. putting
PL/I on the map; but how can they do it now if they couldn't do it for MVS
PL/I 25 years ago? In the Computerwold article I quoted in my earlier mail
PL/I was described as 'An early IBM language', as though the only place
for it is a museum. That is the public perception that has to be
overcome."
++ robin
wrow...@aol.com (WRowe0521) writes:
>This was originally intended to be a comp.lang.pli discussion in the
>"History of PL/I Maybe" thread, but it accidentally became a private
>conversation. We thought it might be generally interesting, so we edited
>it into a dialogue and posted it.
>Robert Barnes, Bill Rowe:-
>Bill (WRow...@aol.com):
>"Ironically, the language became popular in Great Britain because that
>country is always a couple of years behind the US (at least in those
>days), so projects there got the debugged compiler (note that many
>contributors to this newsgroup are from the UK.) Here in the US, I think
>most of you will agree, PL/I has never attained the popularity it
>deserves. The fault lies not in the language, but in its early failure to
>establish itself as the natural successor to COBOL."
---It has already been mentioned in this group that a possible
reason for PL/I being used in Britain is that PL/I had
facilities for English currency L-S-D.
There's no reason why the PL/I-F compiler developed
at Hursley would have been released only in Britain, or earlier
in Britain than in the U.S.
Robert Barnes
++ robin wrote:
>> wrow...@aol.com (WRowe0521) writes:
>
> >Bill (WRow...@aol.com):
> The fault lies not in the language, but in its early failure to
> >establish itself as the natural successor to COBOL."
>
> ---It has already been mentioned in this group that a possible
> reason for PL/I being used in Britain is that PL/I had
> facilities for English currency L-S-D.
>
> There's no reason why the PL/I-F compiler developed
> at Hursley would have been released only in Britain, or earlier
> in Britain than in the U.S.Robin, neither Bill nor I suggested that PL/I-F was released only or earlier in Britain.
The point is that it takes a substantial productivity improvement to change the way that you do things. In
every economic sphere, a two or three fold increase in efficiency just improves profits, but a tenfold changes
the way you do things (new applications, businessess, ..) There is simply insufficient gain in going from
COBOL to PL/I: there is however sufficient gain in going from Assember to a 3GL, and from a 3GL to a 4GL.
Hence Bill and I believe that the main reason for PL/I's lack of popularity, and its inability to displace
COBOL, was timing. I question whether L-S-D would be a significant factor - I'd be interested to hear from
anybody in the UK who can say whether this was critical in their PL/I <-> COBOL decision, but it seems a
detail to me, about as relevant as the fact that PL/I didn't support unsigned integers (COBOL did).
The MAIN POINT of our conversation is that a lot has to be done if PL/I is to thrive. Most particularly, it
needs a determination by IBM that this is going to happen, with consequent strong promotion as well as
development of the language in many directions. Perhaps it should become "PL/4" or PL/O ('oh', not 'zero') -
I'd willingly sacrifice strict compatibility for general usefulness and power.
I will become excited by the future of PL/I when it see it being enthousiastically adoped by new programmers
for new applications, not just being defended by old timers like you and I, and when I see it taking on new
languages such as Powerbuilder, Delphi, and Visual Basic in non-legacy situations. My frustration is that I
believe it could - but I don't believe that it will. In the meantime, I'm afraid that technical arguments about
the superiority of the PL/I language (as in the "reasons for failure of Ariane ..." thread) are about as
relevant (as a predictor of PL/I future) as discussions twenty years ago about the technical superiority of the
Burrough's B6700 compared with IBM S/360 were to their relative success.
++ robin
Robert Barnes <rob...@voyager.co.nz> writes:
>The point is that it takes a substantial productivity
>improvement to change the way that you do things. In
>every economic sphere, a two or three fold increase in
>efficiency just improves profits,
---maybe, but of the project is sufficiently large, then
a 2-fold improvement is as good as a 10-fold improvement.
> but a tenfold changes
>the way you do things (new applications, businessess, ..)
> There is simply insufficient gain in going from
>COBOL to PL/I:
---I consider productivity comparisons COBOL vs PL/I
underestimate the gains to be obtained with PL/I.
I rate it 10:1 in favor of PL/I.
For example, I once saved a (programming) customer weeks
of time simply by putting in the following code in the program:
ON ERROR SNAP BEGIN; PUT DATA; END;
>there is however sufficient gain in going from Assember
>to a 3GL, and from a 3GL to a 4GL.
---Some have put PL/I as being a 3.5GL.
>Hence Bill and I believe that the main reason for
>PL/I's lack of popularity, and its inability to displace
>COBOL, was timing. I question whether L-S-D would be
>a significant factor - I'd be interested to hear from
>anybody in the UK who can say whether this was critical
>in their PL/I <-> COBOL decision, but it seems a
>detail to me, about as relevant as the fact that
>PL/I didn't support unsigned integers (COBOL did).
---But what about Date arithetic? Weren't you promoting that
as a significant improvement for PL/I?
>The MAIN POINT of our conversation is that a lot has to
>be done if PL/I is to thrive. Most particularly, it
>needs a determination by IBM that this is going to
happen,
---It seems that they have done this already, with the release
of PL/I on 3 new platforms in the past 10 months -- AIX,
and Windows 95 and Windows NT.
But let us not overlook that Liant's PL/I is available
on a range of Unix systems as well as the PC.
Also, UniPrise PL/I's compiler released last December
is available for DEC Unix systems.
It's clear that there's supplier development for PL/I,
and that's on account of there being strong demand for
the product.
>with consequent strong promotion as well as
>development of the language in many directions. Perhaps
>it should become "PL/4" or PL/O ('oh', not 'zero') -
>I'd willingly sacrifice strict compatibility for general
>usefulness and power.
>I will become excited by the future of PL/I when it
>see it being enthousiastically adoped by new programmers
>for new applications,
---Recent postings in this newsgroup indicate that PL/I
is being used for new development work.
Robert Barnes
++ robin wrote:
> Robert Barnes <rob...@voyager.co.nz> writes:
> >The point is that it takes a substantial productivity
> >improvement to change the way that you do things. In
> >every economic sphere, a two or three fold increase in
> >efficiency just improves profits,
> ---maybe, but of the project is sufficiently large, then
better to have a ten-fold improvement on this project.
> > but a tenfold changes
> >the way you do things (new applications, businessess, ..)
> > There is simply insufficient gain in going from
> >COBOL to PL/I:
> ---I consider productivity comparisons COBOL vs PL/I
> underestimate the gains to be obtained with PL/I.
small part of the task, or for a specialised type of problem. For example, we wrote MANASYS in PL/I, but this
would have been quite impossible to write using legal COBOL code (although there are implementation-specific
ways of getting list pocessing in COBOL that might of worked). So, for this task, I guess that you could say
that COBOL <-> PL/I productivity would be 1:<some very large number> for this job. However, anecdotal
figures aren't good enough, as they can be countered by anecdotal evidence to the contrary (yes, I have
encountered situations where COBOL was more productive!)
To be able to substantiate your claim, you need to be able to point to reasonably controlled studies, and for
problems properly within COBOL's domain. It doesn't help, for example, to compare productivity in a
compiler-writing exercise (MANASYS), because you wouldn't have used COBOL for this anyway. What would be
interesting however would be studies of the productivity loss because various techniques are not available: for
example, list processing. The whole picture has to also include the confusion that some of these advanced
techniques can bring.
Your 10-fold increase claim is also suspect because it is not supported by any change in method. Thus going
from 3GL's to a 4GL we not only see substantial productivity gains (provided that they are used within their
proper domain), we see a change in method - from the formality of a waterfall SDLC to prototyping, RAD, etc.
PL/I however is used in essentially the same way as COBOL. Since the empirical rule "10-fold improvement ->
change in the way we do things" is reasonably well established, I'd expect to see PL/I used differently to
COBOL if it was actually that much better.
>
> ---Some have put PL/I as being a 3.5GL.Perhaps, but with a bit more oomph it could be a full 4GL, without loosing anything.
>
> ---But what about Date arithetic? Weren't you promoting that
> as a significant improvement for PL/I?Yes, but the really critical enhancements, and the ones that must be made if PL/I is to compete with 4GL's, is
to give it environment awareness: in particular access to the global dictionary (particularly the DBMS), and to
provide a few powerful facilities, particularly for I/O, that use this dictionary information to reduce error
potential and save work.
This was essentially all that we did with MANASYS. We had two guiding principles:-
"Say it once" - if I had already told the program something, I shouldn't have to repeat it.
"Say it right" - in particular, don't say algorithmically what is really [data] description.
For example:-
PROGRAM (MYPROG);
USE TESTDB;
SELECT CUSTOMER WHERE BALANCE > 1000;
PRINT CUSTOMER.NAME, CUSTOMER.ADDRESS, CUSTOMER.BALANCE;
ENDSELECT;
By saying "USE TESTDB", I have given a complete description of the database - with this the SELECT logic can
work out whether to use an SQL select, a READ, a GETNEXT, or whatever, whether to EXEC SQL START ... or OPEN or
READY, and how to test for "end of file". Similarly, the description gives everything that is needed to lay
out the print line, putting headings at the top of every page, and so on. Even more dramatic code compression
comes with data validation, where:-
PROGRAM (MYPROG2) INSCREEN(SCREENA);
USE TESTDB;
ACCEPT CUSTOMER.*;
will combine the descriptions of the database and the screen to validate the incoming data.
> >The MAIN POINT of our conversation is that a lot has to
> >be done if PL/I is to thrive. Most particularly, it
> >needs a determination by IBM that this is going to
> happen,
>
> ---It seems that they have done this already, with the release
> of PL/I on 3 new platforms in the past 10 months -- AIX,
> and Windows 95 and Windows NT.It's a great start certainly - they/ve done enough to ensure that PL/I will survive. Thriving needs more.
> ---Recent postings in this newsgroup indicate that PL/I
> is being used for new development work.Are there any examples of totally new development - ie where there is no legacy of existing PL/I system? Where
you are developing a new function within a PL/I system (including adding intelligent client logic to a PL/I
mainframe system), I'd expect PL/I to be the natural choice, as I'd expect COBOL, C, POWERBUILDER, whatever,
when you are adding functions to a system in COBOL, C, .... Can anybody give me an example of a TOTALLY new
PL/I development. I'd be even more excited if I could find an example of an installation CHANGING TO PL/I.
++ robin
Robert Barnes <rob...@voyager.co.nz> writes:
>++ robin wrote:
>> Robert Barnes <rob...@voyager.co.nz> writes:
>> >The point is that it takes a substantial productivity
>> >improvement to change the way that you do things. In
>> >every economic sphere, a two or three fold increase in
>> >efficiency just improves profits,
>> ---maybe, but of the project is sufficiently large, then
>> a 2-fold improvement is as good as a 10-fold improvement.
>???? Presumably you're saying that if the project is
>five times as big, then 2*5=10.
---Not quite. What I'm saying here is that 2*somethig big is very big.
I.E., if the cost of the job is $1,000,000, and a 2-fold
improvement is obtained, the cost becomes $500,000, which is
a tidy improvement -- a saving of half-a-million dollars.
> But wouldn't it be
>better to have a ten-fold improvement on this project.
---Even better.
>> > but a tenfold changes
>> >the way you do things (new applications, businessess, ..)
>> > There is simply insufficient gain in going from
>> >COBOL to PL/I:
>> ---I consider productivity comparisons COBOL vs PL/I
>> underestimate the gains to be obtained with PL/I.
>> I rate it 10:1 in favor of PL/I.
>I'd be very interested in the basis for this claim.
>It is quite easy to get anecdotal figures like this for a
>small part of the task, or for a specialised type of
>problem.
---In a previous posting, I gave an actual example, where the
addition of a few lines of code saved weeks of time.
A not insignificant cost
in the development of a project is in debugging.
PL/I has excellent debugging facilities. Trouble is,
folks tend to forget that they are there, and how much they can
save. I've written some large systems in other languages,
in which the only debugging tool has been the
footprint (print "I've been here, value is", etc) Needless
to say, a great deal of time was spent in re-runs etc.
PL/I comes with its own household of tools that,
in my estimation, reduce debug time to a fraction of
the time without such tools.