Editing PL/I (section)

==Criticisms==

===Implementation issues===
Though the language is easy to learn and use, implementing a PL/I compiler is difficult and time-consuming. A language as large as PL/I needed subsets that most vendors could produce and most users master. This was not resolved until "ANSI G" was published. The compile time facilities, unique to PL/I, took added implementation effort and additional compiler passes. A PL/I compiler was two to four times as large as comparable Fortran or COBOL compilers, and also that much slower—supposedly offset by gains in programmer productivity. This was anticipated in IBM before the first compilers were written.<ref name="characteristics1978"/>

Some argue that PL/I is unusually hard to parse.<ref>The compiler cannot tell whether a statement is a declaration or a multiple assignment statement until encountering the "=" of the assignment or ";" of the DECLARE—which can be several lines later. The fact that DECLARE/DCL were not reserved is the proximate cause in this example{{snd}} consider the fragment <code>DECLARE(I,J,K),L= </code> vs <code>DECLARE(I,J,K),L;</code>.</ref> The PL/I ''keywords'' are not reserved so programmers can use them as variable or procedure names in programs. Because the original PL/I(F)  compiler attempts ''auto-correction'' when it encounters a keyword used in an incorrect context, it often assumes it is a variable name. This leads to "cascading diagnostics",<ref name=CasD>{{cite web
|url=https://atlas.ion.uwplatt.edu/bitbucket/projects/SB/repos/buildscripts/raw/DotnetCore/sdk/NuGetFallbackFolder/microsoft.codeanalysis.csharp/2.3.1%2Flib%2Fnetstandard1.3%2FMicrosoft.CodeAnalysis.CSharp.xml?at=b1dc21b912b5570ba5f46c5733a261496f6cbf7d
|title=Microsoft.CodeAnalysis.CSharp A Binder converts names
}}{{Dead link|date=May 2020 |bot=InternetArchiveBot |fix-attempted=yes}}</ref> a problem solved by later compilers.

The effort needed to produce good object code was perhaps underestimated during the initial design of the language. [[Program optimization]] (needed to compete with the excellent program optimization carried out by available Fortran compilers) is unusually complex owing to [[Side effect (computer science)|side effects]] and pervasive problems with [[Aliasing (computing)|aliasing]] of variables. Unpredictable modification can occur asynchronously in [[Exception handling|exception handlers]], which may be provided by "{{tt|ON}} statements" in (unseen) callers. Together, these make it difficult to reliably predict when a program's variables might be modified at runtime. In typical use, however, user-written error handlers (the {{tt|ON}}-unit) often do not make assignments to variables. In spite of the aforementioned difficulties, IBM produced the PL/I Optimizing Compiler in 1971.<ref name=OptPLI.1971>{{cite web
 |url=https://www.computer.org/csdl/magazine/an/2013/04/man2013040018/13rRUxBrGiQ
 |title=Early Language and Compiler Developments at IBM Europe
 |author=A. Endres |year=2013}}</ref>

PL/I contains many rarely used features, such as [[Computer multitasking|multitasking]] support (an IBM extension to the language) which add cost and complexity to the compiler, and its co-processing facilities require a multi-programming environment with support for non-blocking multiple threads for processes by the [[operating system]]. Compiler writers were free to select whether to implement these features.

An undeclared variable is, by default, declared by first occurrence—thus misspelling might lead to unpredictable results. This  "implicit declaration" is no different from FORTRAN programs. For PL/I(F), however, an attribute listing enables the programmer to detect any misspelled or undeclared variable.

===Programmer issues===
Many programmers were slow to move from [[COBOL]] or [[Fortran]] due to a perceived complexity of the language and immaturity of the PL/I F compiler. Programmers were sharply divided into scientific programmers (who used Fortran) and business programmers (who used COBOL), with significant tension and even dislike between the groups. PL/I syntax borrowed from both COBOL and Fortran [[Syntax (programming languages|syntax]]. So instead of noticing features that would make their job easier, Fortran programmers of the time noticed COBOL syntax and had the opinion that it was a business language, while COBOL programmers noticed Fortran syntax and looked upon it as a scientific language.

Both COBOL and Fortran programmers viewed it as a "bigger" version of their own language, and both were somewhat intimidated by the language and disinclined to adopt it. Another factor was ''pseudo''-similarities to COBOL, Fortran, and ALGOL. These were PL/I elements that looked similar to one of those languages, but worked differently in PL/I. Such frustrations left many experienced programmers with a jaundiced view of PL/I, and often an active dislike for the language. An early UNIX [[fortune (Unix)|fortune]] file contained the following tongue-in-cheek description of the language:{{Citation needed|date=October 2022}}

<blockquote>Speaking as someone who has delved into the intricacies of PL/I, I am sure that only Real Men could have written such a machine-hogging, cycle-grabbing, all-encompassing monster. Allocate an array and free the middle third?  Sure!  Why not?  Multiply a character string times a bit string and assign the result to a float decimal?  Go ahead!  Free a controlled variable procedure parameter and reallocate it before passing it back?  Overlay three different types of variable on the same memory location?  Anything you say!  Write a recursive macro?  Well, no, but Real Men use rescan. How could a language so obviously designed and written by Real Men not be intended for Real Man use?</blockquote>

On the positive side, full support for [[pointer (computer programming)|pointer]]s to all data types (including pointers to structures), [[recursion]], [[Computer multitasking|multitasking]], string handling, and extensive built-in [[function (computer science)|function]]s meant PL/I was indeed quite a leap forward compared to the programming languages of its time. However, these were not enough to persuade a majority of programmers or shops to switch to PL/I.

The PL/I F compiler's compile time [[preprocessor]] was unusual (outside the [[Lisp programming language|Lisp]] world<ref>{{cite magazine |last1=Hart |first1=Timothy P. |date=October 1963 |title=MACRO Definitions for LISP |magazine=Artificial Intelligence Memos |number=57 |hdl=1721.1/6111 |hdl-access=free}}</ref>) in using its target language's syntax and semantics (''e.g.'' as compared to the [[C preprocessor]]'s "#" directives).