sharp@usceast.UUCP (Harry Sharp) (10/19/89)
Since it seems that this slight 'problem' of no reserved words in PL/I has
resurfaced, I feel compelled to ask the question:
"Eventhough the capability to have variables like DECLARE and THEN, why would
anyone ever use this? Wouldn't it be hard even for the programmer to read?"
I would think that this was another 'feature' thrown in by the committee that
designed PL/I. Honestly, the only thing the left out was the spare lawn mower
engine in the garage, and Ada got that!
Harrison
sharp@cs.scarolina.edu
--
[=============================================================================]
USMail : Dept of Computer Science, USC, Columbia, SC 29208
E-mail : gatech!hubcap!usceast!sharp sharp@cs.scarolina.edu
GO COCKS! You can't lick our cocks! Univ. of South Carolinafirth@sei.cmu.edu (Robert Firth) (10/19/89)
In article <2958@usceast.UUCP> sharp@usceast.UUCP (Harry Sharp) writes: >"Eventhough the capability to have variables like DECLARE and THEN, why would > anyone ever use this? Wouldn't it be hard even for the programmer to read?" Good grief, I'm about to defend PL/I. The problem the designers set out to solve is one very familiar to maintainers of Cobol programs. If the language words are reserved, then any subsequent language enhancement that adds more reserved words will invalidate a large number of existing programs that use those words as identifiers. I well remember a Cobol upgrade that added over 40 (!) new reserved words. That sort of thing leads to coding standards that say Every identifier shall begin with "ZZ_" in the hope that the result will be upgrade proof. One alternative is not to reserve language words - not so that silly people can use THEN and DECLARE as identifiers, but so that sensible people who have used METHOD as an identifier won't be blown out of the water by object-oriented PL/II. Another, and I believe better, alternative is to use a separate font or shift for language words, as was the practice with Algol-60 and many of its descendents. This alternative was unacceptable in North America because programming languages had to be endorsed by manufacturers of obsolete peripheral equipment. Even Ada suffers from this disease. Finally, one can always avoid enhancing languages. (And yes, I too prefer Fortran II to any of its descendents.)
gjditchfield@watmsg.waterloo.edu (Glen Ditchfield) (10/19/89)
In article <2958@usceast.UUCP> sharp@usceast.UUCP (Harry Sharp) writes: >"Eventhough the capability to have variables like DECLARE and THEN, why would > anyone ever use this? Wouldn't it be hard even for the programmer to read?" PL/I has a large number of keywords, many of which are used rarely, and many of which have abbreviations. If they had all been reserved words instead of keywords, picking names for variables would have been more difficult. You couldn't have a string variable called "title", because that's an option on the DOS version of the OPEN statement. Glen Ditchfield gjditchfield@violet.uwaterloo.ca Office: DC 2517 Dept. of Computer Science, U of Waterloo, Waterloo, Ontario, Canada, N2L 3G1 Moof! is a trademark of Apple Computer Inc. Really!
peter@ficc.uu.net (Peter da Silva) (10/20/89)
In article <4560@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: > Finally, one can always avoid enhancing languages. (And yes, I too > prefer Fortran II to any of its descendents.) You can also put new symbols into a new or restricted namespace, as X3J11 did with #pragma and __STDC__. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "You can tell when a USENET discussion is getting old when one of the 'U` participants drags out Hitler and the Nazis" -- Richard Sexton
perry@apollo.HP.COM (Jim Perry) (10/20/89)
In article <4560@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >In article <2958@usceast.UUCP> sharp@usceast.UUCP (Harry Sharp) writes: > >>"Eventhough the capability to have variables like DECLARE and THEN, why would >> anyone ever use this? Wouldn't it be hard even for the programmer to read?" > >Good grief, I'm about to defend PL/I. Don't worry, you're in good company :-) > [it protects you from changes to the language] True, but it's also the case that compilers haven't had to rely on reserving keywords for years, and there's no good reason for it. PL/I defines a huge number of keywords, in part because it provides synonyms for many of them. I, who tended to be a good do-bee and spell out most keywords, e.g. "pointer", might choose "ptr" as a simple list index, and would not be impacted (although "ptr" is also a keyword). Similarly, lots of programmers might elect to call a pointer to the previous record "prec", although this is one spelling of "precision", an attribute of variables that is almost always defaulted. The fact that some bozo might elect to write something like if if = then then then = else; else else = if; opens the door to abuse, but this is true in many languages, and I'll just point out that nobody's ever held an "obfuscated PL/I contest" or written a "PL/I puzzle book". >Another, and I believe better, alternative is to use a separate font >or shift for language words, as was the practice with Algol-60 and >many of its descendents. This alternative was unacceptable in North >America because programming languages had to be endorsed by manufacturers >of obsolete peripheral equipment. Even Ada suffers from this disease. Hm, maybe today you could get the right font effect, but in practice all the efforts I've seen at this tended to overemphasize the keywords, e.g. by boldfacing them (crudely simulated by uppercasing) -- IF dire_condition_prevails THEN die_horribly the "if" and "then" in that statement are not the most interesting or important parts. This scheme also breaks down in modern languages with redefinable types -- a declaration block or parameter list may contain a long list of undifferentiated type names defined by your window manager or whatnot, with an occasional boldfaced/italicized "integer" thrown in. The fact that this word is meaningful to the compiler, and "window" isn't, just doesn't interest me. Jim Perry perry@apollo.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.
peter@ficc.uu.net (Peter da Silva) (10/21/89)
In article <465396f5.20b6d@apollo.HP.COM> perry@apollo.HP.COM (Jim Perry) writes: > point out that nobody's ever held an "obfuscated PL/I contest" or written > a "PL/I puzzle book". If there were as many PL/I programmers as C programmers, then this might change. But PL/I doesn't run on any interesting machines, and hasn't for many years. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "You can tell when a USENET discussion is getting old when one of the 'U` participants drags out Hitler and the Nazis" -- Richard Sexton
perry@apollo.HP.COM (Jim Perry) (10/23/89)
In article <6614@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <465396f5.20b6d@apollo.HP.COM> perry@apollo.HP.COM (Jim Perry) writes: >> point out that nobody's ever held an "obfuscated PL/I contest" or written >> a "PL/I puzzle book". > >If there were as many PL/I programmers as C programmers, then this might >change. But PL/I doesn't run on any interesting machines, and hasn't for >many years. Substitute any sufficiently common programming language you choose, e.g. BASIC, PASCAL, or FORTRAN, only C (and APL) of common programming languages lends itself by design and convention to intentionally cryptic and maximally terse coding. There were, in its time, plenty of PL/I programmers, it's just not the trendy language today. I'll take exception with "doesn't run on any interesting machines"; I'll grant you that there's no UNIX implementation that I'm aware of, and that may have killed it. - Jim Perry perry@apollo.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.
diamond@csl.sony.co.jp (Norman Diamond) (10/24/89)
In article <4666d281.20b6d@apollo.HP.COM> perry@apollo.HP.COM (Jim Perry) writes: [about someone's opinion of PL/I] >I'll take exception with "doesn't run on any interesting machines"; I'll >grant you that there's no UNIX implementation that I'm aware of, and that >may have killed it. Sure, the lack of a Unix implementation helped kill it (and maybe we'll see the death of ANSI magnetic tape formats too). However, surely PL/I killed itself. Would you really specify precisions on your integers? If so, maintenance will kill you. This is one of the things Wirth got perfectly right. -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) Should the preceding opinions be caught or | James Bond asked his killed, the sender will disavow all knowledge | ATT rep for a source of their activities or whereabouts. | licence to "kill".
peter@ficc.uu.net (Peter da Silva) (10/24/89)
In article <4666d281.20b6d@apollo.HP.COM> perry@apollo.HP.COM (Jim Perry) writes: > Substitute any sufficiently common programming language you choose, e.g. > BASIC, PASCAL, or FORTRAN, only C (and APL) of common programming languages > lends itself by design and convention to intentionally cryptic and > maximally terse coding. DO 10 I = 1.10 -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That particular mistake will not be repeated. There are plenty of 'U` mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)
barmar@kulla (Barry Margolin) (10/25/89)
In article <10994@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes: > Would you really specify precisions on your integers? >If so, maintenance will kill you. This is one of the things Wirth got >perfectly right. Hmm, when I was a Multics programmer I always specified precisions, and didn't notice much effect on maintenance. Where a C programmer would say "short" we'd say "fixed bin (17)", and "fixed bin (35)" was equivalent to "long". And just plain "fixed bin" is like "int" in that the compiler chooses the most efficient size (on Multics this was 17, a half word, since arithmetic can be done without overflowing). The main problem with PL/I precisions in systems programming is that they tended to be machine dependent. Had we ever ported Multics to a 32-bit machine, we'd have had to do lots of global replacements to convert all the 17's and 35's to 15's and 31's. In applications programming the precisions are more likely to be related to the problem domain rather than to the architecture, so it's probably not as much of a problem. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
cliff@hq.af.mil (Cliff.J.Bamford) (10/25/89)
No PL/I equivalent to Obfuscated C? Humph. We used to have Palindromic PL/I
contests:
;
x->y=w<-o->w=y<-x
;
The rule was that the palindrome hadda pass unscathed under
the Pessimising Compiler. Then there were things like:
do do = go to label by name;
and...
%dcl a char(*) init (''''''''''''''''''''''); /* that's 22 quotes */
dcl b char(*);
put string(b) data(a);
/* what's the value of b? */
You whippersnappers think C can be obfusc? PL/I INVENTED the concept.perry@apollo.HP.COM (Jim Perry) (10/26/89)
In article <618@hq.af.mil> cliff@hq.af.mil (Cliff.J.Bamford) writes: >No PL/I equivalent to Obfuscated C? Humph. We used to have Palindromic PL/I >contests: Sure, you can do obscure things in any language (the old "self-writing" program, for instance). C just lends itself particularly to arcane coding, what with side-effects operators, the preprocessor, and so on. Anyway, try this: write a program in PL/I to compute and print the Fibonacci numbers less than 100 (1,1,2,3,5...). This program should contain at most one letter 'e' (case insensitive, of course) and no preprocessor-style %directives (easy hint: it's in the "end" statement for the main procedure). PL/I being what it is, there are a number of ways of doing this, from the elegant to the less-so. - Jim Perry perry@apollo.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.
perry@apollo.HP.COM (Jim Perry) (10/26/89)
In article <10994@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes: >In article <4666d281.20b6d@apollo.HP.COM> perry@apollo.HP.COM (Jim Perry) writes: > >[about someone's opinion of PL/I] > >>I'll take exception with "doesn't run on any interesting machines"; I'll >>grant you that there's no UNIX implementation that I'm aware of, and that >>may have killed it. > >Sure, the lack of a Unix implementation helped kill it (and maybe we'll >see the death of ANSI magnetic tape formats too). However, surely PL/I >killed itself. Would you really specify precisions on your integers? >If so, maintenance will kill you. This is one of the things Wirth got >perfectly right. PL/I, despite its best intentions, is not as portable as it might be, and fell into disfavor on that account. Also, it's large enough that few people actually bother to learn to use it, and condemn it in ignorance. Before the UNIX/C/Open systems bandwagon, PL/I subset G was gaining acceptance. It's not the greatest language in the world, but it's not the worst either. I'd rather use a good PL/I than C, for instance. Besides, it's hardly dead... I'd specify integers as "fixed binary", which means "integer" (OK, so PL/I just *HAD* to use bizarre names). The compiler decides the best size for this machine. - -- Jim Perry perry@apollo.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.
diamond@csl.sony.co.jp (Norman Diamond) (10/26/89)
In article <31036@news.Think.COM> barmar@kulla (Barry Margolin) writes: [in PL/I] >Hmm, when I was a Multics programmer I always specified precisions, and >didn't notice much effect on maintenance. Where a C programmer would say >"short" we'd say "fixed bin (17)", and "fixed bin (35)" was equivalent to >"long". Yes, and suddenly some object size grows from <whatever> to <whatever>, passing the 2**17 boundary. That kind of thing takes a lot of searching. >The main problem with PL/I precisions in systems programming is that they >tended to be machine dependent. Well, systems programming is always machine dependent. You deliberately choose halfwords and fullwords, so when you convert, you know what to convert to what. I'd say this is the easy case. >In applications programming the precisions >are more likely to be related to the problem domain rather than to the >architecture, so it's probably not as much of a problem. I'd say this case is much harder. Wirth got this one right. -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) Should the preceding opinions be caught or | James Bond asked his killed, the sender will disavow all knowledge | ATT rep for a source of their activities or whereabouts. | licence to "kill".
barmar@kulla (Barry Margolin) (10/27/89)
In article <11012@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes: >In article <31036@news.Think.COM> barmar@kulla (Barry Margolin) writes: >[in PL/I] >> Where a C programmer would say >>"short" we'd say "fixed bin (17)", and "fixed bin (35)" was equivalent to >>"long". >Yes, and suddenly some object size grows from <whatever> to <whatever>, >passing the 2**17 boundary. That kind of thing takes a lot of searching. If you compile with size checking enabled during testing you'll find it easily. >>The main problem with PL/I precisions in systems programming is that they >>tended to be machine dependent. > >Well, systems programming is always machine dependent. You deliberately >choose halfwords and fullwords, so when you convert, you know what to >convert to what. I'd say this is the easy case. Well, it's even more machine dependent than it needs to be. Unix gets by without requiring the systems programmer to specify exact precisions most of the time. Has Unix been ported to machines with different sizes of integer types? >>In applications programming the precisions >>are more likely to be related to the problem domain rather than to the >>architecture, so it's probably not as much of a problem. >I'd say this case is much harder. Wirth got this one right. You keep saying this. Wirth has designed at least two languages; which one are you talking about? Pascal and Modula-2 both have range types, which are very similar to PL/I's precision option. FIXED BIN (n) is the same as the range -2^n .. 2^n-1, and FIXED BIN (n) UNSIGNED is like 0 .. 2^n-1. Yes, the newer languages permit you to specify more specific ranges, but they're generally implemented the same as the above two classes of types. You have the same problem with overflow as in PL/I. What PL/I is really missing is user-defined types. Some of this can be done using a preprocessor, and some other cases can be handled using LIKE, so it's not a major stumbling block (unfortunately, we didn't have a preprocessor in Multics PL/I, so we only used the LIKE feature). X3J1 almost proposed some major additions to PL/I a few years ago. They were going to standardize a CASE statement, as well as some of the other glaring omissions from the language (I don't know any details). But they ended up just reaffirming the old spec. There probably wasn't enough new PL/I compiler development going on. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
murphy@mips.COM (Mike Murphy) (10/31/89)
>>In article <4666d281.20b6d@apollo.HP.COM> perry@apollo.HP.COM (Jim Perry) writes: >>>I'll take exception with "doesn't run on any interesting machines"; I'll >>>grant you that there's no UNIX implementation that I'm aware of, and that >>>may have killed it. I'm not going to defend PL/I, but I want to point out that there are some UNIX implementations of it. One implementation is on the MIPS machines, which are RISC UNIX boxes. However, it is true that PL/I compilers are not as widespread as C or Pascal compilers; that's probably because PL/I compilers are harder to write. There's a cyclic problem here in that complicated languages are less likely to be implemented, and fewer implementations mean fewer users which means fewer implementations.... To overcome this hurdle you need a strong initial demand for the language (as Ada has because of DoD mandates).