From: johnl@iecc.com (John R. Levine)
Newsgroups: comp.arch.arithmetic,comp.arch,alt.folklore.computers
Subject: Re: Where should the type information be?
Date: 27 Mar 2005 12:22:17 -0500
Message-ID: <d26q49$che$1@xuxa.iecc.com>

>Granted that I may have a vested interest (full disclosure) tell me
>what is wrong with PL/I?  Why does it not fit the bill?

Considering that PL/I was designed by a committee with a short time limit
40 years ago, they did a remarkably good job.

Part of its problem is cultural, it's perceived as overcomplex (the
VDL goop in the standard didn't help) with too many IBM-ish things
like LOCATE and ON KEY.  I agree these are not compelling,
particularly in the era of monstrosities like C++.

The practical problems are that the the type system is out of control,
and the flow of control is stultified.  For the latter, all it offers
is IF, CALL, and the condition system which is so confusing that it's
rare for anyone to use it other than in stylized ways like catching
an EOF on a file.

For the type system, consider this snippet.  (It's been a while since
I wrote any PL/I, so the syntax may be a little off.)

    DCL (A, B, C) CHAR(3);

    A = '111'; B = '222'; C = A + B;

What does C contain?  The correct answer is three spaces, since the
values of A and B are coerced to integers, added, and coerced back to
a default size string '    333' which is then truncated to fit. Oops.

Even though the type system has defaults all over the place, nearly
all of which make sense in isolation, they combine in wacky ways,
programmers don't trust them, and they tend to overspecify their data
by making everything FIXED BINARY(15) or FIXED BINARY(31).  In theory
a diligent programmer should figure out how many bits each datum needs,
in reality nobody bothered.

PL/I also suffered (probably still suffers) from being a language
where they intended that most programmers only know and use a subset.
I learned PL/I from the reference manual and people complained that my
code was unreadable because I wrote mostly Fortran-ish code, but I
used structures and pictures to make my printouts look nice.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

From: johnl@iecc.com (John R. Levine)
Newsgroups: comp.arch.arithmetic,comp.arch,alt.folklore.computers
Subject: Re: fun with PL/I, was Where should the type information be?
Date: 27 Mar 2005 22:25:48 -0500
Message-ID: <d27tfs$t0m$1@xuxa.iecc.com>

> What flow of control do you want?  besides IF, CALL and ON/SIGNAL,
> you have SELECT ...

You do?  It's not in my ANSI PL/I standard.  If we get to add vendor
extensions, then my language can always beat your language.

>The condition handling is one of the most powerful features of PL/I,
>and the one most missed in C.  The idea is that the compiler will
>provide a default handler for error conditions, which the C
>programmer has to check for manually.

Maybe the PL/I programmers you know are smarter than the ones I knew,
but I always found the conditions too baffling to use except in very
simple and stylized way, set and EOF flag to test later or abort on
error.  And I don't think I'm the only one who feels that way.  One of
the reasons that IEEE floating point has NaNs is so that you don't
have to deal with a possible trap after every operation but still have
a way to check for exceptions when you're done.

>> For the type system, consider this snippet.  (It's been a while since
>> I wrote any PL/I, so the syntax may be a little off.)
>>
>>     DCL (A, B, C) CHAR(3);
>>
>>     A = '111'; B = '222'; C = A + B;
>>
>> What does C contain?  The correct answer is three spaces, since the
>> values of A and B are coerced to integers, added, and coerced back to
>> a default size string '    333' which is then truncated to fit. Oops.
>>
>
>Wow, you're right!  I agree this is confusing.  On the other hand, it is
>extremely powerful.  Certainly no one would ever be taught to code like
>that, presumably, if you wrote it, you had a reason for it

It was about 35 years ago, but as I recall I was doing something which
was a counter mostly intended for I/O and I figured that it'd be
easier to keep it as a string.  I later realized that a picture would
do what I wanted, but that's part of the camel-ness of PL/I, you have
pictures from Cobol, and strings with numbers in them sort of from
Fortran, and they sort of act the same and sort of don't.

>I don't think this is true any more.  Most PL/I programmers know at
>least most of the language.  A few years ago, I would have said I knew
>it all, but the more I know, the more I find out I don't know.

Yeah, it has its charms, but it's a sprawling mess, sort of like C++
but sprawling in different directions.

Like I said in my first message, considering that it was a hack job 40
years ago PL/I is a surprisingly good language.  It's not the worst
language I've ever used, not the best, but it's got enough problems of
its own that the only reason I'd tell someone to use it now is if
there's a project with an embedded code base to modify or start from.

I've always claimed that any language where you can write I = I + 1 is
a dialect of Fortran, and none of them are different enough to be
worth worrying about.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.com