You can find the code they wrote with that compiler (EPL) and more information about Multics here. It's browsable but not in any modern archive though (https://web.mit.edu/multics-history/). And here are some links to a simulator that allows you to boot Multics up (https://multicians.org/simulator.html). That web site also has a bunch of history about the system.
My first paying gig was to write PL/I code for a factory monitoring system on a VAX @ Buick City in Flint Michigan, 1981. Anyone remember DEC and those wonderful VAX systems?
My first paying gig was as a temp worker college freshman and I designed and wrote the link level protocol in PL/M for a Ku band satellite terminal @ Harris in Palm Bay at exactly the same time. The engineers with real jobs @ Harris were in nicer parts of the building and got to work on the network layers and above on VAXen. Those were great times. Yeah we had useless offices literally the size of closets (but we all had offices, ones with walls and doors that closed) but we did everything in the lab, playing music, talking, everyone was a smoker and cigarette smoking in the lab was almost a requirement the air was so thick with smoke. Before I left we fantasized about putting bubble memory into the terminal when bubble memory was a thing. Small world. Thank you for making my afternoon nicer with the memories.
My first project in Fortran (early 80s) involved writing a parser (go figure, what a dumb idea). I had no idea what a parser looked like so someone gave me a printout of a PL/I parser - word wrapped. It made no sense, I went to the library and got some books and got it done somehow.
This article is by the recently deceased Dr. Corbató, who lead the development of early time-sharing systems, such as CTSS and Multics.
It seems that PL/I wasn't a good choice in hindsight, being too complex to implement a compiler quickly, given the memory constraints back in the day.
I posted this because I was interested in a comment about Multics that stated that PL/I's design prevented memory access bugs, because it had variable length arrays/strings(?), and not C's zero-terminated strings. Of course C/unix was a better choice for the memory-limited systems of the day than the relative behemoth that was PL/I/Multics.
PL/I doesn't prevent memory access bugs, but it makes it easier to do good programming. For example, parameters are passed by descriptor, so the allocated size is passed allowing run-time bounds checking. On the other hand, there is an equivalent of C type-casting, so it is still possible for the programmer to shoot themselves in foot while simultaneously hoisting themselves on their on petard.
I used PL/I in about '68 to do transmission line calculations. It was great for the task because it had a complex float type and a full set of complex math functions. It was a lot better than Fortran or Cobol at the time. I think it did not succeed because the PL/I compiler was too big and slow for the first generations of minicomputers in the '70s. There may have been intellectual property issues that kept it from being more widely used as well.
I wrote a Battleship game in PL/I on a Univac 1100 ca. 1978. It was a pretty cool language, but those /* comments */ felt weird after FORTRAN and COBOL.
I used PL/UM, a PL/I variant at the University of Maryland at about the same time. Also on a Univac 1100, specifically an 1108 and/or 1106. Where you there, too?
In retrospect, many of the observations are good, even foresightfull.
I believe that VAX/VMS was based on some of these experiences plus careful reading of Structured Programming by Djikstra.
Unfortunately, DEC didn't grok the performance issue of microcoded CISC and Sun Sparc ate their lunch.
Lessons DEC learned:
. Combining engineering of hardware and software at the same time
. Networking as a medium of exchange including for storage (cluster interconnect, C I)
. Diverse software support, from C, PL/I, Cobol, etc
. VAXcluster as a means to converge management, storage, scalability, and so on
Novel tech:
. Software-supported coding, such as language-sensitive editing, w/o emacs
. A basic data architecture, based on Rdb. Weak, but sort of functional
Oopses:
. RISC. Eventually they made Alpha but FP sucked, even architecturally
I worked in PL/1 for 4 years. Saying it is just "F&%ing works" made me laugh hard! The compilation never failed because the compiler assumed what you really wanted. I got many bizarre programs.
Must have had an odd code base then - I found it nice to work with.
And in my experience Primes pl1/g Compiler did properly assume what a sane developer would want - well there was that one time I had to recompile the entire Pl1 part of our MR system and push it out to all 17 systems :-)
I put a Prime minicomputer emulator online that has both PL/I-G and full PL/I. It's configured as a Prime 9950, a successor to the Prime 750. Count me as one of the few who has written production PL/I software for a Prime!
telnet em.prirun.com 8002 for the subset G compiler
telnet em.prirun.com 8005 for the full PL/I compiler
Emacs is also installed on the first machine running rev 20 Primos, but not quite on the second running rev 23 Primos because I didn't have all the pieces.
I used it in the early '70s. A principal problem was that the language was so extensive ("kitchen sink") that some programmers could be using features that others were simply unaware of and which conflicted during integration.
I'd be interested to hear from those who have used both - how does it compare to Algol? Looking at wikipedia it seems similar in its syntax and also in the intention of the design. Also: I think I first heard of PL/I in the 1980s but only today have I discovered it is P.L. One rather than P.L. Eye - thanks, HN!
PL/1 grew out of a project in the early 1960's to develop a successor to Fortran. It was decided very early on that it would do decimal arithmetic (like COBOL) and then that it would provide good support for record-oriented I/O and the common access methods used for sequential and random-access disk, tape, cards, printers, etc. typically attached to mainframe computers, which you pretty much needed to compile it anyway. This made it quite a horse of a different feather than Algol. Minicomputer and microcomputer versions of PL/1 subsequently appeared (I recall Digital Research had one that implemented something called subset G,), but these were limited subsets, pretty much matching simple implementations of Fortran, Pascal, or Modula-2 feature for feature -- not as elegant as Algol, but about as close to Algol as they were to IBM's full PL/1 level F. For a long time, many IBM System/360 and System/370 mainframe were not suitable to run the famous IBM OS/360, and there were two levels of simplified versions of the operating system (called DOS and DOS/VSE), and each of these, in turn, offered only its own distinct subset version of the full mainframe PL/1.
You can find the code they wrote with that compiler (EPL) and more information about Multics here. It's browsable but not in any modern archive though (https://web.mit.edu/multics-history/). And here are some links to a simulator that allows you to boot Multics up (https://multicians.org/simulator.html). That web site also has a bunch of history about the system.
There is also https://ban.ai for a publicly accessible Multics system.
PL/I (and PL/C) was my first high-level language when I studied Computer Science in the late 70s.
CS 101 at my college was "IBM 370 Assembly Language". Then we moved on to PL/I.
And it was on punch cards.
My first paying gig was to write PL/I code for a factory monitoring system on a VAX @ Buick City in Flint Michigan, 1981. Anyone remember DEC and those wonderful VAX systems?
My first paying gig was as a temp worker college freshman and I designed and wrote the link level protocol in PL/M for a Ku band satellite terminal @ Harris in Palm Bay at exactly the same time. The engineers with real jobs @ Harris were in nicer parts of the building and got to work on the network layers and above on VAXen. Those were great times. Yeah we had useless offices literally the size of closets (but we all had offices, ones with walls and doors that closed) but we did everything in the lab, playing music, talking, everyone was a smoker and cigarette smoking in the lab was almost a requirement the air was so thick with smoke. Before I left we fantasized about putting bubble memory into the terminal when bubble memory was a thing. Small world. Thank you for making my afternoon nicer with the memories.
My first project in Fortran (early 80s) involved writing a parser (go figure, what a dumb idea). I had no idea what a parser looked like so someone gave me a printout of a PL/I parser - word wrapped. It made no sense, I went to the library and got some books and got it done somehow.
This article is by the recently deceased Dr. Corbató, who lead the development of early time-sharing systems, such as CTSS and Multics.
It seems that PL/I wasn't a good choice in hindsight, being too complex to implement a compiler quickly, given the memory constraints back in the day.
I posted this because I was interested in a comment about Multics that stated that PL/I's design prevented memory access bugs, because it had variable length arrays/strings(?), and not C's zero-terminated strings. Of course C/unix was a better choice for the memory-limited systems of the day than the relative behemoth that was PL/I/Multics.
PL/I doesn't prevent memory access bugs, but it makes it easier to do good programming. For example, parameters are passed by descriptor, so the allocated size is passed allowing run-time bounds checking. On the other hand, there is an equivalent of C type-casting, so it is still possible for the programmer to shoot themselves in foot while simultaneously hoisting themselves on their on petard.
I used PL/I in about '68 to do transmission line calculations. It was great for the task because it had a complex float type and a full set of complex math functions. It was a lot better than Fortran or Cobol at the time. I think it did not succeed because the PL/I compiler was too big and slow for the first generations of minicomputers in the '70s. There may have been intellectual property issues that kept it from being more widely used as well.
I wrote a Battleship game in PL/I on a Univac 1100 ca. 1978. It was a pretty cool language, but those /* comments */ felt weird after FORTRAN and COBOL.
I used PL/UM, a PL/I variant at the University of Maryland at about the same time. Also on a Univac 1100, specifically an 1108 and/or 1106. Where you there, too?
I was at Petro-Canada in Calgary, Alberta. I displayed the Battleship arrays on HP character-based CRTs.
SSG rocks! Unix needs a modern equivalent.
Man they seemed so naive in those days.
I bet they still feel nostalgic whenever they see `proc options(main)` or `put skip edit` though.
In retrospect, many of the observations are good, even foresightfull.
I believe that VAX/VMS was based on some of these experiences plus careful reading of Structured Programming by Djikstra.
Unfortunately, DEC didn't grok the performance issue of microcoded CISC and Sun Sparc ate their lunch.
Lessons DEC learned:
. Combining engineering of hardware and software at the same time . Networking as a medium of exchange including for storage (cluster interconnect, C I) . Diverse software support, from C, PL/I, Cobol, etc . VAXcluster as a means to converge management, storage, scalability, and so on
Novel tech:
. Software-supported coding, such as language-sensitive editing, w/o emacs . A basic data architecture, based on Rdb. Weak, but sort of functional
Oopses: . RISC. Eventually they made Alpha but FP sucked, even architecturally
You know this is Multics we are talking about here :-)
I must be one of the few on hn who has actually programmed in Pl/1 on a system (Prime 750's) that used it as its systems programming language.
It is a Dream Language it just F&%ing works
I worked in PL/1 for 4 years. Saying it is just "F&%ing works" made me laugh hard! The compilation never failed because the compiler assumed what you really wanted. I got many bizarre programs.
That was typical of PL/C and the silly IBM timesharing language based on PL/1, not so much of PL/1 itself.
Must have had an odd code base then - I found it nice to work with.
And in my experience Primes pl1/g Compiler did properly assume what a sane developer would want - well there was that one time I had to recompile the entire Pl1 part of our MR system and push it out to all 17 systems :-)
I put a Prime minicomputer emulator online that has both PL/I-G and full PL/I. It's configured as a Prime 9950, a successor to the Prime 750. Count me as one of the few who has written production PL/I software for a Prime!
telnet em.prirun.com 8002 for the subset G compiler
telnet em.prirun.com 8005 for the full PL/I compiler
Emacs is also installed on the first machine running rev 20 Primos, but not quite on the second running rev 23 Primos because I didn't have all the pieces.
Enjoy!
If it was a dream language, why do you think it died out, and why did COBOL become dominant and survives to this day?
I used it in the early '70s. A principal problem was that the language was so extensive ("kitchen sink") that some programmers could be using features that others were simply unaware of and which conflicted during integration.
Similar for me. Enjoyed a couple of years in college working in PL/1 on an Amdahl 470V/7. Good times!
I'd be interested to hear from those who have used both - how does it compare to Algol? Looking at wikipedia it seems similar in its syntax and also in the intention of the design. Also: I think I first heard of PL/I in the 1980s but only today have I discovered it is P.L. One rather than P.L. Eye - thanks, HN!
PL/1 grew out of a project in the early 1960's to develop a successor to Fortran. It was decided very early on that it would do decimal arithmetic (like COBOL) and then that it would provide good support for record-oriented I/O and the common access methods used for sequential and random-access disk, tape, cards, printers, etc. typically attached to mainframe computers, which you pretty much needed to compile it anyway. This made it quite a horse of a different feather than Algol. Minicomputer and microcomputer versions of PL/1 subsequently appeared (I recall Digital Research had one that implemented something called subset G,), but these were limited subsets, pretty much matching simple implementations of Fortran, Pascal, or Modula-2 feature for feature -- not as elegant as Algol, but about as close to Algol as they were to IBM's full PL/1 level F. For a long time, many IBM System/360 and System/370 mainframe were not suitable to run the famous IBM OS/360, and there were two levels of simplified versions of the operating system (called DOS and DOS/VSE), and each of these, in turn, offered only its own distinct subset version of the full mainframe PL/1.
I learned to program with PL/1.
I had forgotten about 'put skip edit'.
I have no memory of what it was for. However, I'm sure some fine gray(er)beard will remind me here! ;-)