- The inappropriate link to Talk:PL above is because of a technical restriction. —Preceding unsigned comment added by 188.8.131.52 (talk) 18:44, 13 October 2010 (UTC)
|WikiProject Computing / Software||(Rated C-class, Mid-importance)|
- 1 Early discussions
- 2 SABRE
- 3 Case insensitive
- 4 History
- 5 Retrospective
- 6 Year developed
- 7 Subpage
- 8 PL/I newsletter
- 9 PL/I and C
- 10 Lost text?
- 11 IBM System/360
- 12 "powerful" vs "ambitious"
- 13 Was PL/I the first commercial language to compile itself?
- 14 First commercial compiler
- 15 PL/I AREAS
- 16 other drawbacks
- 17 Typo in examples
- 18 Reference to criticism
- 19 Criticism of Criticism
- 20 Dataypes
- 21 Some of the history section needs clarification
- 22 Replacing Sections - Retrospective (Design and implementation issues, Programmer preference issues, Improved features), Variables, Storage classes
- 23 Language Summary and C++
- 24 Criticism Section
- 25 Implementations Section
- 26 RETURN from ON-units
- 27 Why PL/I failed
- 28 It's the customers' fault
- 29 Online compiler links
- 30 Implementation issues - undeclared variables
- 31 FORTRAN vs. Fortran
- 32 Object orientation
- 33 Positive? I'm not so sure
- 34 Citation in first paragraph
- 35 Syntax highlighting
- 36 Standardization issues
- 37 Array expressions
I deleted the following, which is not true:
- The original IBM mainframes used the same symbol 'I' for both the letter 'I' and the number '1'. Thus, the way that it is commonly written and normally spelled are different.
- Thank you. That's what I thought, too, but wasn't sure enough about 3 decade old memories to make the change. --Buz Cory
- I did more research and I hope this clarifies what I meant to say:
I was trying to make a distinction between the character and the font. Unfortunately, I used the wrong symbols. It was the small "L" and the number "1" that used to identical font symbol (i.e., l and 1 look the same - more or less - even though I typed the "el" character first, and the "one" character second).
I was not intending to say that the characters were identical (i.e., had identical values in EBCDIC), merely that they looked the same. This was true for the Courier font ball used in IBM Selectrics, which were also used as operator terminals in some S/360 installations, and the font symbols may have been identical in the print cylinder in the 1403 printer. Because I don't have the original context - or don't know how to get my original contribution for the context, I'm not sure why I even brought up the character confusion thing...
Cheers --17:29, 31 December 2006 (UTC)RSzoc
The bit about SABRE is from personal experience. I was offered (and turned down) a position with the SABRE project ca 1965. Don't know if they stayed w/ PL/I or changed to a different language.
The (military/aerospace) project I was on at the time would have used PL/I if it had been useable early enough. We went through major contortions to do a real-time/multi-tasking system requiring dynamic allocation of records (structs to you C weenies) in FORTRAN IV. Further, FORTRAN required 512K of RAM to compile, the PL/I compiler would work in 128K. --Buz Cory
Evidently, the SABRE folks didn't get a really solid PL/I compiler for their platform until the early 1970s. They may have wanted to use PL/I earlier than that, but I can vouch that at least the portions of the system that American Airlines dealt with were almost entirely 7090 assembler before the early 1970s. (Working off my father's notes on this one; he wrote the compiler, so there's a chance his history is biased, of course.) --Cliff Biffle
Not so sure about that "case insensitive" part. At that time virtually all work was done entirely in upper case due to hardware limitations. --Buz Cory
- I don't know about others, but most of OS/360 is upper case only. The JCL intepreter, and all the OS/360 compilers I know, are upper case only. It is usual for printers to map lower case to upper case, making this problem harder to find. Gah4 (talk) 02:36, 17 May 2017 (UTC)
Nice job on the history. Some references to written documents (which I understand may not exist) would be nice. If its personal experience, then say so. --drj
- The parts of the history that I wrote are personal experience. If one can find copies of Datamation from ca 1965, the arguments that I mentioned about not using PL/1 are in there. The part about NELIAC is from a book I read ca 1962 whose name and author I cannot recall.
- The part above about system requirements for FORTRAN and PL/1 is also personal recall. --Buz Cory
Most of the history stuff I added is purely from memory. I read it somewhere. I wasn't even alive when PL/I was being developed. -- Simon J Kissane
A couple of inaccuracies in the "Retrospective section".
First, it states that the "user wouldn't know whether a statement was a declaration or a executable statement until one saw the period at the end. " The truth is that PL/I uses (and has always used) the semi-colon as a statement terminator. COBOL is that language that used periods. Additionally, a declaration statement ALWAYS begins with the keyword "DECLARE" or "DCL", so it's easy to figure out what kind of statement it is. Also, "format free" languages that could be spread along a number of lines before being terminated had been around since at least the early 1960/61 if not earlier. Even assembly language could span multiple lines if one put a "continuation" character in Column 72 of the "card".
Second, the article states that "the decision to make spaces unimportant, as in Fortran" (I paraphrase) is simply not true. In Fortran, spaces were truly irrelevant. Thus, one could write an "do statement" as follows:
DO I = 1, 10 or DOI=1,10
Both were considered to be the same (this is the Fortran for the time of the late 60's early 70's).
In PL/I spaces did matter. Taking the same example above:
DO I = 1 to 100; OR DOI=1 to 100;
are very different statements; I think the second one won't even compile.
Perhaps you are thinking of Keywords. Like all languages, PL/I has keywords, (such as DECLARE, DO, IF, END, and so on), but, because PL/I had so many keywords, the language designers decided that none of them were to be RESERVED. Going to the Fortran example above, the word DO is a keyword AND is reserved, and cannot be used for any other purpose but in a DO statement. In PL/I, one can use DO in a do statement and also as a variable. The "headache" in writing a PL/I compiler was the requirement that it had to figure out from the context whether a word was being used as a keyword or not.
The example that I remember from back in the day was this. The following is a perfectly valid PL/I statement (because no keywords are reserved):
IF IF = EQUALS THEN THEN = ELSE; ELSE ELSE = IF;
Cheers RSzoc 01:02, 26 November 2006 (UTC)
Adding to our understanding of the name (I would rather PL/1, since that was intended), "A Genealogy of Computer Languages" by James Haddock says "In 1964, IBM was developing its System/360. Never happy with ALGOL, they wanted to have a dialect of their own as a system implementation language, but with the ability to handle COBOL style applications. The result was PL/1 (they also copyrighted the names PL/2 through PL/100 just in case)."
- I added to the article that PL/I was used at MIT in 1964, which was the oldest reference that I could find. Morris 23:02, Apr 12, 2005 (UTC)
- See Fernando J. Corbató#Further reading for the PL/I As a Tool for System Programming reference, which probably gives a lot of detail on this. Might we worth including that as a reference here too. Noel (talk) 18:55, 13 Apr 2005 (UTC)
The PL/I language specification was still being developed in 1964, and there was no PL/I compiler available from IBM when S/360 and OS/360 were released. Documentation for S/360 and OS/360 was available in 1964, but the first systems - at the lower end - did not begin shipping till 1965. My personal recollection is that IBM's production of system 360s didn't begin in high volume until 1968 or so. RSzoc 01:08, 26 November 2006 (UTC) ---
I was working on PL/I for IBM in England in 1964-1965, and I recall writing assembler language interrupt processing routines for the "Tape Operating System" TOS, that was available for the machine before OS/360, but of course not for release.
The 'F' in PL/I F refers to the fact that it was intended to run on a machine with only 64K (64 Kib in the ugly new abbreviation) of 'core', which was our random access memory. That's with an OS as well, of 20 K.
The '360' of System 360 was intended to imply completeness, as in a full circle of 360 degrees, which makes the same nonsense of S/370 and S/390 as "I support you 110%".
We had an apocryphal story that IBM UK was warned by the National Physical Laboratory that if they did not drop the NPL name, the real NPL would publish a standard or something called Infernal Bloody Mess, to be known by its initials. As for the reluctance to adopt PL/I, there was a feeling at Hursley that part of the reluctance was the "Not Written Here' attitude of IBM USA. DaveyHume (talk) 18:04, 9 March 2016 (UTC)
As for Multics and MIT, the web site of http://www.multicians.org/pl1-raf.html states that "Multics PL/I" was based on an IBM language spec that was not available until 1968. Again, I believe the difference is the time difference between when specifications are made (e.g., 1965 in the case of Multics) and when a final software product containing that specification is actually produced. The above referenced Web site states that the Multics PL/I compiler was developed in 18 months. If we take March, 1968 as the starting point - when the PL/I language spec used by MIT was available, and add 18 months, we get September 1969 as when Multics Pl/I compiler was actually available. MPearl - what is your reference for the 1964 date??RSzoc 01:08, 26 November 2006 (UTC)
As an aside, UNIX was named as a form of word play for Multics. Because the Multics OS was so big - many computer types felt at the time - Dennis Ritchie and Ken Thompson at Bell Labs named their OS Unix, implying small and lean.
Now, of course, all OSes are pretty much out of control, with nothing begin small and lean, except for maybe whatever drives microwave ovens (that last sentence is an editorial comment by me - feel free to snip it out)... RSzoc 18:52, 18 November 2006 (UTC)
The first ship of PL/I F by IBM was definitely 1966. I have added the chronology of the 5 releases of PL/I as they show some interesting PL/I history. F had the advantage that the language manual was being written on the floor above the one John Nash's F compiler team inhabited in "B block" in Hursley. There was an advertised DIgitek compiler that claimed to have shipped ahead of F - but the Multics team thought it was still vapourware, hence doing there own thing PL/I. EPL has been quoted as 1964, but it cannot have been a PL/I at this stage. I suspect it was a special purpose language initially and was adapted to PL/I as the PL/I Spec appeared in 1965/66,
—Preceding unsigned comment added by RogerofRomsey (talk • contribs) 16:06, 2 February 2010 (UTC)
The paragraphs on Multics and year implemented are still just plain wrong. The text states and implies that multics PL/I (or EPL) compiler was used in 1964. However, this reference (http://www.multicians.org/pl1.html) shows that EPL is still not available as a working product even in 1966-1967. The other references for multics refer to the IBM Language Specification document in 1968 as the relevant language definition. So, my suggested timeline still holds. Until, at least, we get a statement from someone who was there and can state that:"We had a fully operational PL/I compiler in 196.... ". The other references cited in the section on Multics state things like: "The compiler implemented most features except for ... input and output... "... Which seems like a severe "to-do" item to make it usable... RSzoc (talk) 01:45, 18 July 2010 (UTC)
Perhaps this isn't really important, but this article is actually a subpage: the subpage "I" of the article "PL". This obviously isn't the intention, but it seems to work alright. Deco 00:37, 17 Nov 2004 (UTC)
PL/I and C
This page contains the claim (in the "External links" section) that "The C programming language was heavily modelled after PL/I". Alas, this is untrue. The C Progamming Language (by Ritchie, Johnson, Lesk and Kernighan, 1977) says that "Many of its most important ideas stem from ... BCPL", and there is no mention of PL/I. As for BCPL, the BCPL Reference Manual (by Richards, Evans and Maybee, 1974) says that "BCPL is related to CPL", and again no mention of PL/I. (The CPL documents cited date from 1963/65, making it impossible for CPL to have been influenced by PL/I.) So I am going to remove that claim. Noel (talk) 22:20, 12 Apr 2005 (UTC)
- I see still that the article has a statement that PL/I influenced the development of C. I've never seen anything anywhere else that states such. Although it is possible that PL/I served as a good example to K&R of what not to do if you want to develop a compiler capable of running on a system with limited memory, influencing them that way. --184.108.40.206 (talk) 03:29, 7 February 2009 (UTC)
- Kernighan and Plauger, in their superb "Elements of Programming Style", illustrate their principles with examples in both the Fortran and PL/I languages. They are of course far more widely applicable. This shows that K was fluent enough in PL/I.
- But the C language was designed in such a way as to be able to write a C compiler in its own language. Much as I prefer PL/I to Cobol and Fortran, I would run ten miles before I'd attempt to have a PL/I compiler written in PL/I. It has been said that "whereas Fortran has absurd restrictions, PL/I has absurd generalizations".DaveyHume (talk) 18:26, 9 March 2016 (UTC)
- The Iron Spring PL/I compiler and runtime are all written in PL/I, with a bit of assembler. This was ported from System/z to x86 with only a few lines of modification to the compiler (and, of course, a new code generator module). The Multics PL/I compiler was written entirely in PL/I. I would walk 100 miles before I'd have written it in C, but of course everyone has a favorite language. The nice thing about the absurd generalizations is that the compiler will usually take whatever you write, as long as it's syntactlly correct, and do something sensible with it.Peter Flass (talk) 23:28, 9 March 2016 (UTC)
- Consider yourself lucky that you didn't work for General Electric. (And it ran on an operating system primarily written in PL/I.) Guy Harris (talk) 19:01, 9 March 2016 (UTC)
A large block of text was lost here during a spam/vandalism spree earlier this year. Assuming that this removal was an error, I have added it back, and done some copyediting to remove duplicate material that was added after that piece was lost; I also attempted to organize the material a bit better. Noel (talk) 19:40, 13 Apr 2005 (UTC)
I know it's nitpicking, but IBM didn't refer to System/360 as the System/360. It was just System/360. My reference is a 1964 copy of the IBM Systems Journal where the entire architecture of the machine was described in Iverson notation. Shoaler 5 July 2005 17:22 (UTC)
"powerful" vs "ambitious"
I think I disagree with the revert done to my change of the adjective "powerful" to "ambitious." I appreciate the differences between PL/1 and C, but both are NP-complete languages, and I think the use of the word "powerful" in this context is misleading; it gives a false impression, and is (in my opinion) a bit too cheerleading of a word to lead off an article with.
I prefer "ambitious" because it more accurately captures the scope of PL/1 as a featureful language, without reference to the perceived "power" of the language (which really, could mean anything).
Thoughts? I'm also open to other suggestions. As a test, I've changed powerful to "feature-rich", which I think also captures the true nature of the distinction.Nandesuka 15:27, 15 July 2005 (UTC)
- I like "feature-rich" (or maybe some other more grammatically correct adjective with the same meaning). I think that "powerful" is too vague with regards to a programming language. JYolkowski // talk 21:30, 15 July 2005 (UTC)
- The words “power” and “powerful” have long been associated with PLI. (Remember the Black Panther logo). You can achieve a great deal in a single PLI statement. Just as other languages can claim flexibility, portability, ease-of-use, easy-to-learn, and so on.
- A possible issue with “feature rich” is that it could refer to graphics or other features absent in PLI
- Perhaps “powerful” should be explained and an example given.
- (speaking of examples, I’m removing the hello world with the infinite loop)--ClemMcGann 23:27, 15 July 2005 (UTC)
Was PL/I the first commercial language to compile itself?
The article reads: PL/I was probably the first commercial language where the compiler was written in the language to be compiled.
- (moved posts from talk pages here) -- ClemMcGann 01:08, 6 August 2005 (UTC)
- I am of the opinion that Burrough's Algol was before PL/I (compiler written in its own language)
- (and Burrough's PLI for the B6700 was written in Algol)
- --ClemMcGann 13:13, 5 August 2005 (UTC)
First off, thank you for getting back to me. I guess the easiest way to bring up concerns about factual information like that is to bring it up in the discussion pages, but the way you removed the line without a clear comment did make it impossible to know that you were doing so to dispute the timeline.
I suppose that some of this is my fault for confusing two languages. I could have corrected the error when I first saw it. I actually had a counter-example from NELIAC, which was first publicly announced in 1958, based on publications from the Naval Research Laboratory. What year was the compiler that you were refering to written?
- Huskey, H. D., Halstead, M. H., and McArthur, R., "NELIAC- A Dialect of ALGOL" in ACM/ CACM 3(08) August 1960
- JOHNSEN, R. L. JR. Implementation of NELIAC for the IBM 704 and IBM 709 computers. NEL Tech. Mere. No. 428, Sept. 1960.
- HOPL entry for NELIAC which is the source of the following quote:
- Significant in that it provided the first ever bootstrap implementation, and the standard reference for NELIAC (Halstead's book) was for many years the primary reference for such compilers.
- Ok, I just re-read what I wrote on PL/I. It's odd that you deleted what you did, since your delete did not argue the point specifically. That is, you removed one of three sentences in that paragraph, the only one that did not claim PL/I was the first commercial (and this is a key point) language designed this way.
- That said, I think the idea here is that BALGOL was a research language used in commercial settings, much like C was at first. PL/I was designed to be a commercial language. At least that's how I read it from the source I got that from. Now, of course, I can't find that source. Stupid me, I should have put it in the article, but not being a PL/I guy, I just assumed that it was common knowledge.
- Easy things first: do you dispute the dates involed? E.g. do you dispute that NELIAC came before BALGOL or that PL/I came (about 8 years) after both of them? Of not, then I think we can move on too the question of if PL/I can claim to be the first commercial bootstrapped language, no? -Harmil 22:57, 5 August 2005 (UTC)
- I only expressed a doubt, not a certainty.
- That doubt was based on comments made last year in alt.folklore.computers, It was a long thread.
- The claim “Suspect Algol on Burroughs mainframes might have compiled itself first and done it very well.” Is here 
- A reply “Multics PL/I was written in PL/I, though it was bootstrapped via a temporary compiler (EPL) not written in PL/I.” 
- I do not dispute that “NELIAC came before BALGOL or that PL/I came (about 8 years) after both of them?”
- Actually I don't dispute anything, I just expressed a doubt.--ClemMcGann 01:08, 6 August 2005 (UTC)
First commercial compiler
The first commercial version of the PL/I compiler by IBM was the (F) level compiler. In those days, IBM identified many of its software development/system applications with the letters E, F, G, and H. Each letter specified the minimum S/360 memory configuration needed to run that software. The memory configurations for the different letters were:
Level E: 32KB Level F: 64KB Level G: 128KB Level H: 256KB
(Source: IBM System/360 Operating System Introduction Release 21, IBM Publication number GC28-6534-3 avaiable from www.bitsavers.org).
Thus the PL/I (F) level compiler needed a minimum of 44KB to run(Source: IBM System/360 Operating System, PL/I (F) Compiler Program Logic Manual, IBM Publication Number Y18-6800-3, available from www.bitsavers.org).
For comparison purposes, when I run Microsoft's Outlook in Windows XP, it takes up about 14,604KB to sit there waiting for email to come in. This is about 331 times (33,100%) more memory) that the first IBM PL/I compiler.
I also have the code for that first compiler, (available for a small fee to cover cost of media from cbttape.org) and it is most definitely in assembly language. The PL/I (F) compiler is comprised of about 270 source files and about 385,000 lines of IBM assembly language code. This figure does not include code for the libraries, built-in functions, I/O functions and all that.
Now perhaps the PL/I Optimizing Compiler was written in PL/I but I doubt it very much, because the PL/I (F) compiler had a reputation as being a real dog, and one would not use something with that reputation to write an arguably "better" compiler. I used both compilers "back in the day", and there was no way one could shoehorn a compiler of such a massive language as PL/I into 44KB using a high level language.
However, it has been documented that the PL/I "Checkout" compiler WAS written using the PL/I "Optimizing Compiler", the arguably much improved compiler that came after the PL/I (F) level.
The following quote from an article from 1978 summaries the systems that PL/I was used to program:
PL/I, and a variant for systems programming, has been used successfully to program several large operating systems and compilers (notably MULTICS, OS/VS Release 2 Version 2, the PL/I Checkout compiler).
This is from The Early History and Characteristics of PL/I by George Radin, ACM SIGPLAN Notices, 13(8), 1978 RSzoc 18:34, 18 November 2006 (UTC)
- The PL/I optimizing compiler required the PL/I runtime library to execute. Of course, this was rarely a restriction, but it was possible under VM to locate the two on different minidisks, which could mean access to one and not the other. Robert A.West (Talk) 08:26, 30 December 2006 (UTC)
Can we insert something about notable/novel features in PL/I, in particular I am curious about AREAS.
NevilleDNZ 21:50, 23 May 2007 (UTC)
- What's notable or novel about it? Seems to be similar to FORTRAN COMMON areas, and COBOL Segmentation, both of which preceded PL/I. T-bonham (talk) 05:01, 30 August 2008 (UTC)
- As I remember it, an area is an unstructured space in which based variables (usually structures) can be allocated. These are referenced through the use of an OFFSET variable defined with respect to the area. The offset is like a pointer, except safer because out-of-bounds errors can be diagnosed at run-time. The offset must always point within the area. I'll have to check my PL/I (F) Reference Guide when I get back to my office.CSProfBill (talk) 17:08, 13 August 2009 (UTC)
Also, AREAs can be read or written as a block, and the offsets will still be valid. Additionally they make it easy to clean up storage by just deleting the AREA, rather than having to delete lots of separate data items individually. Peter Flass (talk) 21:13, 20 August 2011 (UTC)
As an ordinary programmer who has read up on PL/1 after learning C and Pascal, I would like to suggest 3 more reasons that the language is not more widely accepted. (1) The requirement that a subprogram could be embedded ANYWHERE inside a parent routine put another burden on the compiler writer, who would potentially have to save off data on the parent routine and then restore it when the subprogram finished. The feature itself was overkill; Pascal (and later ADA) confined subprograms to the declaration area with no loss of power.. (2) Although amazingly full of built-in data types, the language design completely missed out on the concept of the user-defined datatype, a very hot topic in the '70s. The only way that a programmer could declare two variables of the same complicated type was to use a clumsy "A LIKE B" mechanism, which would be a maintenance headache -- suppose B turned out to be obsolete during a later revision? (3) Wierd rules such as writing TRUE as '1'B, when both COBOL and FORTRAN already had much clearer syntax. CharlesTheBold 03:28, 30 July 2007 (UTC)
- Well, as someone who wrote PL/I programs in the 1970s, I can tell you that none of these were problems at the time.
- While PL/I can certainly be accused of overkill, this wasn't an egregious example, and certainly wasn't the biggest imposition the language made on the compiler writers. If you want to find the part that made them go nuts, you only need to look as far as the macro language.
- The PL/I "structured data" type is exactly a "user-defined datatype", and it predated the C
record. This was a very common concept in the 1970s, and no serious language lacked it. PL/I even had C's
BASED(pointer), which was uncommon for a HLL of the time (of course, Assembler programmers used DSECTs for exactly that all the time). And nobody coded
DECLARE A LIKE B;unless B was a structure and existed solely for that purpose.
- How hard is it to
DECLARE TRUE BIT INIT('1'B); DECLARE FALSE BIT INIT('0'B);? And from a boolean perspective, C's "true is 1, false is anything else" concept is just wacky.
- RossPatterson 00:57, 31 July 2007 (UTC)
Thank you for the historical perspective. I was of course evaluating the language from the point of view of 2007. I can tell the language was a powerful tool in the 1970's when compared to COBOL and FORTRAN. I understood about PL/1 structures, my point being that PL/1 seemed to operate by cloning a sample structure rather than instantiating a template -- this is a theoetical point which probably didn't make much practical difference in writing programs. CharlesTheBold 03:08, 10 August 2007 (UTC)
- My opinion is that C and Pascal won out over PL/I largely because programmers weren't all that much productive using PL/I versus C or Pascal. C and Pascal's big advantages were that they were quick to compile and compileable on machines with only around 64K or 128K bytes of memory. All three languages provided large productivity increases over FORTRAN (and COBOL, I suspect). —Preceding unsigned comment added by 220.127.116.11 (talk) 04:13, 7 February 2009 (UTC)
- Neither your nor my opinion matter for this article, since we're not citing sources, but I disagree. PL/I, FORTRAN, and COBOL were all compilable in 64KB or memory in those days - remember, we ran a bunch of programs in memory at the same time, and 1MB was considered a large-memory system. As noted above, IBM's "F Level" PL/I compiler ran in 64K, and it was a full-blown implementation of the language. And we defined programmer productivity differently at that time, when it was considered wasteful to compile a program that had syntax errors - programming wasn't largely typing at that time, most programs were still initially written by hand on paper.
- What C and Pascal benefited from wasn't that they were better, it was that Computer Science had a change of heart. In the early 70s, CompSci programs taught PL/I dialects to undergrads, XPL was the cutting edge in compiler research, and the only other contender was LISP (but for grad students and profs, not undergrads). Fast forward 10 years and almost every CompSci program had become a Unix fandom, rightly or wrongly, and had started teaching C instead of PL/I, in part because there was no Unix PL/I. Just as C++ and now Java have replaced C because of what the schools teach today, so C replaced PL/I (and PL/I replaced FORTRAN, at least outside the Engineering schools). But COBOL, like cockroaches and crabgrass, will be with us forever :-) RossPatterson (talk) 05:14, 7 February 2009 (UTC)
- The terrible "Year 2K threat" to ancient programs was caused by the two digit year embedded in so many COBOL programs, I'm not sure about Fortran. But most of it was the ignorance of management people.
- I myself, working for an office regulating gas pipelines, asked why a pig in a pipe would need to know the date? Pipelines transporting oil or gas can put in a sort of moving partition, called a pig, for various purposes. If it has electronic intelligence aboard, it should only need to know the time elapsed since it was launched.DaveyHume (talk) 19:23, 9 March 2016 (UTC)
I worked for IBM on the mathematical library subroutines for the PL/I library, when hardware floating point didn't have exponential and trigonometric functions. I think I keypunched cards from my own handwritten programs. It could cost you a day to submit a program to the machine, and have it come back with syntax errors. It is now more economical of a programmer's time to let the computer report them in less than a minute.
- But note that the compiler itself was written as loadable 4096-byte segments, in order to run code that consisted of megabytes of data. So the vast generality of the language tended to make it slow.
- Nevertheless, the team that devised both C and Unix was tighter and therefore more agile, quite probably smarter, than the IBM consortium that defined PL/I. I'm not quite sure that one could write an OS in Pascal, but Niklaus Wirth is certainly a genius.
- C and Pascal are better languages than PL/I, having the advantage also of being invented more recently. Unix is a better OS than anything earlier.
- Writing Perl or Python programs to run on a machine with gigabytes of RAM is dead easy. The machines are fast enough that you rarely have to care whether it's compiled or just interpreted.DaveyHume (talk) 19:07, 9 March 2016 (UTC)
Typo in examples
Reference to criticism
The 3rd paragraph, "PL/I is considered by some..." was flagged for fact. I edited in a reference that demonstrates that Edsger Dijkstra (at least) made that criticism. That's still not a particularly good reference because it is merely an example of a famous person making the claim, rather than something that states authoritatively that several people made that claim. It's just something that I had just come across and could easily reference. If someone has something better, please fix it again. EMan (talk) 19:21, 5 May 2009 (UTC)
Criticism of Criticism
As modified, the 3rd paragraph reference does not support the criticism to which it is attached. While I believe the statement is true, it is unsupported by a fact. In denial of the creation and existence of ADA, some people do think PL/I was a turning-point. In the reference (to Dijkstra's Turing Lecture), Dijkstra does lambaste PL/1 for its feature-full nature, but nowhere describes it as a turning-point. Furthermore, in the same article he also says that "Algol 60 is expensive to implement and dangerous to use" and that he sees "a great future for very systematic and very modest programming languages. When I say 'modest' I mean that, for instance, not only AlGOL 60's 'for clause', but even FORTRAN's 'DO loop' may find themselves thrown out as being too baroque." It is rather unfair and non-NPOV to throw such a pot-shot into the introduction of the article.
The trade-off between adding complexity to a language where a documented, common function is available to all and asking each developer to create or find a function implementation for themselves is a complex and contested discussion. Perhaps the view that Guy Steele ("Growing a Language") expresses about growth of language from primitives and embedding features in libraries rather than language represents the proper comprimise. But the point is that if made, such a discussion should be confronted directly, later in the article where it can be presented in full form and not as a rhetorical comment without anything other than an appeal to authority (for which counter-authorities can be found as well). As far as I know there are NO actual studies to illustrate the value trade-offs. The statement should be removed and anyone wishing to discuss the issue in greater depth should please do so - preferably in a context in which it doesn't appear to apply to one programming language among many.
- It would be a big table - about 60 entries ClemMcGann (talk) 22:53, 22 October 2009 (UTC)
- I've added this, to the level of the Standard. PL/I Optimizer had a few more, e.g Normal/Abnormal, Event and Task.Haven't decided what to do about the Latest IBM PL/I for Z/os - long after my time! RogerofRomsey (talk) 22:20, 21 January 2010 (UTC)
Some of the history section needs clarification
Parts of the history section sound extremely suspicious when you add them together, for instance it says that PL/I was developed in Europe, but later "PL/I was designed by a committee drawn from IBM programmers and users drawn from across the United States".
While it is possible that the language was "designed" in the USA with input only from USA and then implemented in Europe that sounds a) like a roundabout way of doing thins b) very unlike IBM c) means that the implementers had no input on the language etc etc etc
- I was in the PL/I language group in those years. Compilers were done in UK and Germany. Language was initially in New York then transferred to Hursley in 1967, with the language group working on one floor of "B-Block" and the F Compiler and Library groups on the next floor. I am working with "fabulous flowers" preparing an edit of the history section.
Replacing Sections - Retrospective (Design and implementation issues, Programmer preference issues, Improved features), Variables, Storage classes
The sections do not relate well to the structure of the articles on PL/I's fellow languages Algol, Cobol, and Fortran. There is excellent debating material, but it does not have the perspective of an Encyclopedia.
I have already rewritten the History section to deal with PL/I's failure to displace Fortran and Cobol and its being overtaken by C for systems work, and the goals section to say that PL/I was bound to be large and complex. I will be removing material from the subject Sections that has been dealt with in History and Goals. Some paragraphs that are significant issues of opinion will be moved to footnotes. Less contentious points will be retained under Implementation Issues, Programmer Issues, Special PL/I Topics.
The language summary is keyed to the Standard to avoid contention. But there were important elements missed out in the standard, and significant developments have occurred since. To capture these I am adding an Evolution of the language section. —Preceding unsigned comment added by RogerofRomsey (talk • contribs) 15:25, 28 January 2010 (UTC)
The Variable names section is redundant - the fact that there are no reserved words in PL/I has been made already, and this example doesn't add anything to that. I would expect most compilers to warn the user when IF,THEN,ELSE, and DO are used as identifiers. Let's not tempt people to write bad programs.
RogerofRomsey (talk) 16:20, 2 February 2010 (UTC)
Language Summary and C++
The "Language Summary " section cites SGML and C++ as Special Purpose languages. This seems to be not precise enough. SGML is a "language" of sorts - ok, it's part of the name - , but not a Computer Language in the same sense as Algol, Fortran, PL/I, JOVIAL, etc. It's more of a specification. C++ is (really) a general purpose language. I've NEVER heard of it being described as a special purpose language. If special purpose, then what is that special purpose? Other example languages should be chosen as special purpose examples, no? RSzoc (talk) 01:53, 18 July 2010 (UTC)
- Agreed, that sentence is a load of rubbish. I have just removed C++ and tagged it as OR. 18.104.22.168 (talk) 02:56, 20 July 2010 (UTC)
Currently, though the article has lots of criticism, it has no section called that. Perhaps it got lost at some stage. Cobol and Fortran do have such a section. I am moving the current content - Implementation Issues and Language issues into the section. It will need thinning to reduce it to attributed criticisms, Dijkstra and the like. RogerofRomsey (talk) 17:01, 29 January 2010 (UTC)
I have elevated the material to a section and divided it into a subsection per "major" compiler, a subsection on other subsets, and one on dialects. A major compiler is one that had a substantial impact on the development of the language and its general usage; interesting single customer compilers are not major, however interesting.
At this stage I am gathering data and descriptions - platform, year of release or announcement,subset/dialect level. I have added Micro Focus Open PL/I, CDC compilers, PL/I for OS/2, Stratus and Honeywell as Multics derivatives, IBM Series 1 PL/I.
RogerofRomsey (talk) 18:43, 1 February 2010 (UTC)
I have put in further substructuring to help make sense of the lists of compilers
- 5.5 Conversational teaching subset compilers
- 5.6 Other Mainframe and minicomputer compilers
- 5.7 PL/I compilers for Personal Computers and UNIX
- 5.8 Special purpose and system PL/I compilers
- 5.9 PL/I dialect compilers
I have added a large section on the current (2010) IBM PL/I compiler - a beast with several names and supporting all IBM platforms including AIX, Linux and Z/OS. The section risks dominating the implementation section, but I see no alternative as it is the main IBM vehicle and there is so much new function in it. There is no Standard for the added functions, so the extensions have been placed in the Implementation section. It would help if the major extensions to PL/I made by Kednos and Liant/MicroFocus were included. Anyone have any material?
RETURN from ON-units
I removed the following inline text by RogerofRomsey from the "'On' block error trapping" section of the article:
- /* Not true. ON-units cannot be terminated by RETURN statements for some good reasons. Would the writer please revise this recently added section. */.
I also adjusted the text a bit to reflect his point. The section still needs work, though. — (talk) 18:43, 19 April 2010 (UTC)
Why PL/I failed
I'm putting this here in the talk page because I don't know what else to do with it. It isn't really encyclopedic, but on the other hand isn't any less so than what is in the article under "Usage".
One significant reason that PL/I failed is sheer inefficiency. In particular (and I recognise this is a very very nerdy point) the implementation of the Static Back-Chain Pointer through register 4 in the Optimising Compiler added 14 machine instructions to each procedure call on the off-chance that someone would call a procedure with a another procedure as a parameter - something that no relatively sane person in the commercial world would consider doing even by accident.
In effect (on one program I wrote way back when) this meant a program that in Cobol took two hours to run took 23.5 hours when translated to PL/I (environment specific obviously). So everybody wrote PL/I as if it didn't have procedure calls at all and it might as well have been Cobol.
That seems to me a fundamental design flaw in at least the compiler, if not in the language. And it scares me a bit that after nearly thirty years that register number and the reason for it is still seared on my brain. PL/I might have been a marvellous language (and PL/S was, since it did without this nonsense) but it failed by trying to do everything for everybody and not doing it particularly well for any of us.
But it is a bit of a moot point whether it was the language design or the implementation that was at fault. Blowed if I can find any reference for this other than my own experience though. Would welcome feedback from others. Phisheep (talk) 01:56, 1 March 2011 (UTC)
- I'm skeptical that 14 additional instructions per procedure call could increase run time by 1175%. Did you try compiling with some optimization compiler option, perhaps one that specifically disabled the extra procedure call overhead? In any case, you can't extrapolate one example, or even one implementation, to explain why PL/1 failed to retain its (or grow in) popularity as a programming language. — Loadmaster (talk) 04:07, 1 March 2011 (UTC)
It's the customers' fault
Seems biased against the customers, using weasel words to describe their views and blaming them for the language's faults:
• "Many programmers were slow to move" // were they slow or did they decide not to move?
• "a perceived complexity" // so it's the programmers' fault, or is it complex?
• "Programmers were sharply divided ... with significant tension and even dislike between the groups" // it's the programmers again
• "Both COBOL and FORTRAN programmers ... were somewhat intimidated by the language and disinclined to adopt it." // more weasel words
• "jaundiced view of PL/I, and often an active dislike for the language." // ditto
- Having been a programmer at the time, in a commercial shop, with a non-IBM machine, allow me to comment on the above points:
- There was no PL/I compiler available to a programmer until the first IBM/360 was installed. When it was installed, the programmers needed to get busy. Moreover, the management was reluctant to retrain their Cobol or Assembler programmers in an unknown language and face subsequent maintenance in more languages than seemed necessary.
- I always maintained that there was a usable subset of the language that was easier to learn than Cobol, of which I had experience. At least one experienced ex-Cobol programmer whom I recruited came back from his PL/I course and said "Now that's what I call a programming language!". However, I could (and did, when interviewing) fox experienced PL/I programmers by showing them a few lines of code that would not compile and ask them how to correct it. The answer was to delete one (syntactically valid) line. Experienced programmers also had problems understanding recursion, but then they didn't need to.
- A working group of technical and commercial programmers from the various divisions of my company agreed that the company as a whole should move towards PL/I as a common language as and when it was shown to fulfill it's initial promise. Management was still held back by the first point above and it never happened.
- Many, but by no means all, of these guys had barely healed scars from learning their first programming language and were in no hurry to learn another.
- This is pretty much the same point as the previous one, though I suspect that there may have been a certain amount of NIH in the States, since the early compilers came from Europe.
- Much as I enthused about PL/I, even so far as to be castigated (anonymously, I'm glad to be able to say) on one occasion by Dijkstra, I have to accept that the comments reflect more or less how I felt at the time, once I realised what we had let ourselves in for. MikeSy (talk) 11:24, 20 August 2011 (UTC)
Recent edits by 22.214.171.124 added links to PHP-based "online compilers" at VintageBigBlue.org. Are these valid links for these WP articles? I tested the COBOL compiler on a simple "Hello, world" program and all it did was return a blank page. — Loadmaster (talk) 20:17, 31 October 2011 (UTC)
Implementation issues - undeclared variables
Default attributes for undeclared variables were put into the language for compatibility with FORTRAN, which of course didn't declare most variables. Should this be added? Peter Flass (talk) 21:32, 3 February 2012 (UTC)
FORTRAN vs. Fortran
The original change wasn't mine, but I believe FORTRAN is correct: "All capitals are naturally used in many abbreviated forms such as NATO, FBI, etc.; see Acronyms and initialisms above." Peter Flass (talk) 19:03, 11 March 2012 (UTC)
- Fortran isn't an acronym. COBOL is. Every letter must stand for something. Most old computer usage was due only to lack of lower-case, and we don't replicate it. Even the current language standard now uses "Fortran" rather than "FORTRAN". Yworo (talk) 19:09, 11 March 2012 (UTC)
- Fortran was a contraction - FORmula TRANslation - not an acronym, but it was written in uppercase because of convention, not limitation. At the time, most proper nouns in computing were written in caps, even when publishing mixed-case academic papers about them (which was, after all, the primary discussion mode of the day). For example, the 1954 Backus et al. report entitled "Specifications for the IBM mathematical FORmula TRANslating system, FORTRAN.". And since the usage in this case is specifically FORTRAN IV, in support of the "PL/I" name, it probably should be shown in this article as such. RossPatterson (talk) 19:42, 11 March 2012 (UTC)
- A good rule of thumb is to see where the Wikipedia article is, it's at Fortran. I removed the comparison as unnecessary. In the Fortran article they choose to make an historical distinction using all-caps for the older versions, Fortran for the newer versions; however, this is explained in the lead of the article. In other articles, we should just use "Fortran", which is the current standard. Yworo (talk) 19:50, 11 March 2012 (UTC)
- Well, you learn something new every day. Fortran is indeed an acronym, in the proper, dictionary sense: a word from the first letters of each word in a series of words. Which doesn't change Yworo's valid point about using the modern "Fortran" form for the language in general. But references to the 1961 dialect should still be "FORTRAN IV" - even the FORTRAN IV section of the Fortran article reads that way. RossPatterson (talk) 10:41, 13 March 2012 (UTC)
- Still violates WP:ALLCAPS. Some definitions include this sort of acronym, some definitions don't. It makes since to distinguish in the Fortran article, and it has an explanatory paragraph in the lead, but do you intend to put an explanatory footnote in every other article that uses the all-caps form? Because otherwise knowledgeable editors will probably continue to reduce to normal capitalization. The only reason FORTRAN IV was in all-caps was that computers of the time did not have lower-case at all! Yworo (talk) 19:49, 13 March 2012 (UTC)
This section is really not about Object orientation or related features. Should be renamed to something like "Data types". Proposals? — Preceding unsigned comment added by Towopedia (talk • contribs) 10:47, 29 June 2012 (UTC)
Positive? I'm not so sure
"On the positive side, full support for pointers to all data types (including pointers to structures), recursion, multitasking, string handling, and extensive built-in functions PL/I was indeed quite a leap forward compared to the programming languages of its time. However, these were not enough to convince a majority of programmers or shops to switch to PL/I."
This makes it sound like programmers would want to use these features. From today's perspective, with most programmers familiar with languages like C and its derivatives, that might seem reasonable. However, from the perspective of thirty or more years ago, when PL/I was competing with lots of emerging languages (some on the newfangled microcomputers), things like pointers were alien to most COBOL and Fortran (i.e. mainframe) programmers. Most PL/I I came across then was little different than Fortran in coding style - pointer use was all but forbidden in some shops (I was forbidden to use recursion until the '90s). The biggest problem I had with most programmers coming onto my PL/I team was getting them to learn and use pointers properly!
Rather than being positive, these things were central to the fear and loathing that most mainframe programmers had for PL/I. IMHO, of course.
- I disagree, but that's also only my opinion. Certainly string functions were a big step beyond Fortran's support for "hollerith" data. Peter Flass (talk) 20:41, 26 February 2013 (UTC)
- I probably should have taken the last two out of the list. But pointers, recursion and multitasking were things they didn't want to deal with. 126.96.36.199 (talk) 23:12, 26 February 2013 (UTC)
- Could be. Most programmers came to PL/I from a COBOL or FORTRAN background; certainly recursion and multitasking, at least, would have been a stretch for them. Anyone with an ALGOL background would have "gotten" recursion. I'll have to look at PL/I for FORTRAN Programmers and PL/I for Commercial Programmers to see what they presented, but I think they tried to map FORTRAN and COBOL features to PL/I features, probably leaving out those things you mention. Peter Flass (talk) 00:08, 27 February 2013 (UTC)
- I probably should have taken the last two out of the list. But pointers, recursion and multitasking were things they didn't want to deal with. 188.8.131.52 (talk) 23:12, 26 February 2013 (UTC)
Citation in first paragraph
I noticed the citation in the first paragraph (, which points to "Sturm, Eberhard (2009). The New PL/I. Vieweg+Teubner. ISBN 978-3-8348-0726-7.") doesn't make sense. The paragraph states the language is in active use as of 2011, but the reference was written in 2011. Does anyone with more knowledge about the language have a better reference? Namnatulco (talk) 08:48, 17 March 2013 (UTC)
Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for PL/I (lang="pli") was unfortunately dropped, as can be seen with the plain text formatting on this page, PL/M, PL/0, IBM i Control Language, SabreTalk, and others such as Do while loop#PL/I , For loop, Record (computer science), Data descriptor, K-mer, Branch table, Stropping (syntax), Gap penalty, Stride of an array, Object composition, Karatsuba algorithm. While_loop, Subroutine and Goto. If you want PL/I syntax highlight support again, it will need to be added to Pygments. John Vandenberg (chat) 02:19, 12 July 2015 (UTC)
Should the article discuss the name change from PL/1 to PL/I, which as I recall happend during the standardization process?