Lambda the Ultimate

inactiveTopic Teaching the Fatal Disease
started 8/14/2002; 12:50:19 AM - last post 8/15/2002; 9:18:50 PM
jon fernquest - Teaching the Fatal Disease  blueArrow
8/14/2002; 12:50:19 AM (reads: 1945, responses: 4)
Teaching the Fatal Disease
PL/1 is the most famous early example of programming language feature bloat:

"It is the rare human who is aware of all the features of PL/I. Thus, a programmer can make himself indispensable by using a significant portion of the plethora of PL/I features in his programs. ...indispensable programmers should immediately be fired!"

Dijkstra took a swipe at it too:

"Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language...already escapes our intellectual control. ( Humble Programmer Turing Award Lecture)

He goes on to talk about how one feature addicted lecturer asked for 50 more new features in a one hour talk. PL/I As a Tool for System Programming: five years with a temporary compiler is a post-mortem by a member of the Multics Operating System design team (developed about the same time as Unix, more ambitious, less successful). Software Archeology: Understanding Large Systems tells a PL/1 story of ill-defined semantics beyond a programmer's intellectual control while working for Ross Perot's EDS at General Motors in the early 1980's. The mere act of inserting a debug message solved the bug, so they left it alone. Finally, there is a well-reasoned 1994 defense of PL/1 Power vs. Adventure - PL/I and C in which "the 'old and honest' programming language PL/I seems to grow new blossoms."

Posted to history by jon fernquest on 8/14/02; 12:59:58 AM

Ehud Lamm - Re: Teaching the Fatal Disease  blueArrow
8/14/2002; 5:47:17 AM (reads: 853, responses: 1)
PL/1 is a really disgusting language, with some fun ideas (e.g., a Turing complete preprocessor).

When I used PL/1 I remember a great example. We used a cool feature of the language (array slices and iSUB, see RM chp. 8) to solve some interesting initialization problem using one line of code. The compiler took agaes, only to report something along the lines of "valid but unimplemented use of language feature."

Ehud Lamm - Re: Teaching the Fatal Disease  blueArrow
8/14/2002; 8:00:29 AM (reads: 913, responses: 0)
Just to clarify. It is not that the feaure itself wasn't implemented. It was! Thing is, it allowed you to create constructs so complicated, the compiler didn't know how to handle them.

Ehud Lamm - Re: Teaching the Fatal Disease  blueArrow
8/15/2002; 4:39:40 AM (reads: 762, responses: 0)
One of the nasty things about PL/I is that it is basically untyped. You have "data elements" that seem to be defined according to a type system, but in fact the language will automatically perform very strange implicit conversions between almost any two entities: PL/I converts data when a data item with a set of attributes is assigned to another data item with a different set of attributes. (RM, chp. 4)

This is quite annoying since the conversion rules are not very intuitive, and most conversions result in disasters.

For exmaple, if you try to run until the middle of (an even lengthed) array, you are most likely (if you are no PL/I maven) to end up with an infinite loop. (If you are brave take a look at table 16 page 65 of the RM )

Jarno Virtanen - Re: Teaching the Fatal Disease  blueArrow
8/15/2002; 9:18:50 PM (reads: 755, responses: 0)

It is curious though that Frederick Brooks states in the original Mythical Man-Month, Sharp Tools essay that

What high-level language should one use for system programming? The only reasonable candidate today[1] is PL/I.
...
I myself find it faster to work out algorithms in APL; then I translate these to PL/I for matching to the system environment.

(It is not curious that Brooks makes this kind of statement; it is more curious that the situation was so poor, then ;-) APL is not famous for encouraging highly readable code, either.

[1] That was year 1975.