I haven't written a PL/I program since about 1985, but I still have a certain affection for the language. It was a genuine attempt to create a new language that

I haven't written a PL/I program since about 1985, but I still have a certain affection for the language. It was a genuine attempt to create a new language that would be better than Fortran and Cobol (and Algol, for that matter). The designers bit off way more than they could chew; it has the equivalent of threads, but threads weren't understood at all in those days. Even procedures were not understood: because of the multitasking, on procedure entry, the original IBM PL/I (F) compiler used a system call (GETMAIN) to allocate a stack frame, which was freed on exit. This led to the hilarious advice in the (F) Programmers' Guide: “Do not use procedures, they are expensive.” The preprocessor was another problem. Its language was Turing-complete, but programs that used it were essentially undebuggable.You had to look at the preprocessor output (which was generally unreadable) to fix even the smallest mistake in using it. Finally, the language designers followed the Cobol principle of making every pre-defined facility a statement. So there are record I/O statements, stream I/O statements, and on and on. This would all have been much better done with comprehensive library facilities, which were not well-understood in those days. With all of that said, if I were to find myself required to write PL/I code nowadays, I would find it a tolerable matter. I'm glad, even if it's only for legacy code, that the Iron Spring compiler exists. (And I even managed to get this comment done without mentioning the time that the PL/I (F) compiler produced a box of printer paper, saying “ERROR: COMPILER IS UNABLE TO ABORT”, over and over, double-spaced, for 2000 pages, accompanied by a nasty letter explaining that I was “abusing” Computing Centre services. That really was a rocky time for PL/I programmers.)