Was later adopted by IBM and Intel for their OS, although since it grew C++ levels of complexity, eventually split up in various dialects.
PL/S, PL/M, PL.8, PL/Something...
One of them, PL.8 is famously associated with being one of the first LLVM like compiler frameworks, used by IBM on their RISC research, before they pivot and created AIX for their RISC CPUs.
System languages like PL/I, BLISS, Modula-2, would have had a different adoption if UNIX wasn't basically free beer with a recipe on how to make it.
> System languages like PL/I, BLISS, Modula-2, would have had a different adoption if UNIX wasn't basically free beer with a recipe on how to make it.
You always say that. And I always call BS on it. I don't expect to persuade you, replying for the Nth time, but I have a couple of things I want you to think about.
"Not free" sometimes beats "free". People buy cars even in cities that have public transit. People paid for cable TV when over-the-air TV was free.
For this to happen, though, the not-free option has to deliver more value than the free version. With a car, I can go when I want; with public transit I have to wait. For many people, there's value in that. With cable I can watch 500 channels. There's value in that, at least for some people.
PL/I, Modula-2, and Pascal did not deliver more value than C - or at least not enough value to be worth the price of their compilers. Multics did not deliver more value than Unix - or at least, not enough more.
In fact, Multics had to reach a very high bar, because not only was Unix free, it ran on less-expensive hardware. The issue (probably) wasn't that Multics cost more than Unix; the issue was that Multics ran on hardware that cost a lot more than a PDP-11. Unix could have cost as much as Multics and still won, because the cost of the OS was not the dominant cost in the equation.
You often mention network effects - that Unix and C took over universities because they were free, and so everyone was using them, and so everyone knew how to use them, and so when they went somewhere else, they used what they knew. Go back to cable TV. Over-the-air TV had network effects - everyone was talking about the show they watched last night, and if you didn't watch it, you were left out. It was free advertising plus social pressure to be part of the "in" crowd. And yet cable still made money, and eventually grew into internet distribution, and still took away large amounts of market share from broadcast. Network effects can be overcome, if the product is actually closer to what people want.
So I think your explanation is too simplistic. It may have been a factor, but in the ahistorical world where Unix and C weren't free, I think they would have won anyway - still because of cost, but because of hardware cost.
> Multics didn't fail: it accomplished almost all of its stated goals. Unix succeeded too, solving a different problem.
Multics wouldn't have become what Unix became even if Unix wasn't there. It was pursuing different goals. And it turned out that Unix's goals had a lot bigger market than Multics's goals.
So, Unix had warts. But those warts were bearable because it met the needs of the market it addressed, and the other OSes didn't do so, or at least didn't do so as well.
Had UNIX been sold as commercial product, most likely the winner would have been something like VAX VMS, not Multics, which was anyway an OS for DoD only.
Or something else, definitely not UNIX, there was plenty of other alternatives when free would not have been an option, and UNIX haters book is still quite up to date in some of the original warts.
> Had UNIX been sold as commercial product, most likely the winner would have been something like VAX VMS
In the 70s and 80s, a lot of universities used VM/CMS for research and teaching. But then they ended up all migrating to some combination of UNIX and PCs running DOS/Windows.
In the 1980s, IBM was seriously pursuing the idea of a VM/CMS-based workstation – they ended up actually releasing the IBM 7437 VM/SP Technical Workstation in 1988, and it was adopted by some customers, primarily those who used the mainframe-based CAD systems CADAM and CATIA. But it just couldn't compete with UNIX workstations in the market. In an alternative timeline where UNIX was much less successful, it might have stood more of a chance.
Had VMS been any more wide spread, there would have been a VMS haters book.
I could make a start, referring to the default editor, EDIT. In the early nineties (no idea, what version that actually was) it was possible (and there was no warning) to edit the same file in multiple sessions (using multiple terminals by not-so-well communicating team members). Only the last file saved remained on disk.
I think that’s a reasonable argument, but in practice if Unix and C weren’t free it would have meant universities using tools that were closer to free — things like the UCSD p-system would have been more widespread. Different world; possibly a better one, if I’m right, which is unknowable.
Well, we built a compiler in bliss 36 so I can address that a bit.
Bliss isn’t like Fortran and is quite a different beast from C. It had a practical way to define structures. It defined code structures as expressions rather than statements. I feel it was a a little higher level than C. But not higher level like PL/I. There were different languages for 36 bit machines (PDP-10) 32 bit machines and I think even 16 bit machines.
You can get a taste of the syntax from playing with REXX
, which is an interpreted language that started on mainframes but has been ported almost everywhere.
In early 90th I was an OS/2 fanboy, I did a lot of automation in REXX. I'm not sure REXX syntax resembles PL/I which was then heavily used at the place I worked on "big iron". PL/I used to be more verbose, uppercased and aming SQL database work, methinks. REXX, on the other hand, was more like Perl and I felt quite comfortable with Perl when I switched OS/2 to FreeBSD. :)
It is still around, although far less used than it once was. Some people use it on IBM mainframes, although COBOL was always more popular. Also saw some usage for applications on OpenVMS
IBM z/OS is mainly written in PL/X, which is a systems programming dialect of PL/I (removing features which are irrelevant to systems programming and adding stuff like inline assembly). So are various other IBM mainframe products like DB2 for z/OS. PL/X was previously known as PL/S, PL/S II, PL/AS. There was also a "PL/X-86" which was a port of PL/X to x86, targeting OS/2, it was used for mainframe service processor code.
Large parts of IBM i are written in a couple of related PL/I dialects, PL/MI and PL/MP. PL/MI is used for code that runs above the virtual machine, PL/MP for code which runs below it. When they switched from CISC to RISC, a lot of the PL/MP code was rewritten in C++, although apparently some of it survives. (Parts of IBM i are also written in Modula 2)
PL.8 is yet another systems programming PL/I dialect. It was developed as part of the compiler for the IBM 801 RISC project. It was the language many of IBM's compilers were written in (not sure if that is still true?). In the earliest versions the AIX kernel was written in a mixture of PL.8 and C, although newer versions all the PL.8 code is gone. It was also used to write firmware for mainframes (and possibly AS/400 aka IBM i too). IBM even built a PL.8 frontend for GCC, but they never officially released it outside of IBM – https://dl.acm.org/doi/10.1147/rd.483.0543
Yet another IBM PL/I dialect is PL/DS which was used for the IBM 8100 and DPPX/370, although that stuff is long dead.
Then there was also Intel / Digital Research PL/M, which was used to write CP/M. (In CP/M 2.x and later, the core of the OS was moved from PL/M to assembly to improve performance, but PL/M was still used for utilities.) I've also heard claims that PL/M was used to write some of the firmware on CISC AS/400 (more specifically, the Service Processor), although not sure how true that is.
And then the defunct Honeywell CP-6 mainframe OS had its own PL/I dialect, PL/6.
PL/I is also apparently what Stratus VOS is written in
Back in the 90s, Object REXX was available on OS/2. I used it to tie a mainframe application on 3270 to SQL calls to update a database for a windows application. Once Object REXX was released on Windows, we moved it off OS/2.
REXX is not PL/I, but very easy to for a PL/I programmer to pick up.
PL/I on the mainframe can be a highly effective application language, but there's a number of features that are ferociously computationally expensive that were acceptable for low volume or one off stuff that had to be avoided by production applications.
COBOL is tedious compared to PL/I. While I had occasion to fix COBOL bugs and performance issues and even taught SQL to COBOL programmers I refused to write COBOL programs.
Then there's Multics PL/I. I did a pilot project to evaluate porting from IBM VM to Multics on Honeywell and discovered a flaky environment. I saved my employer a pile of money by killing that idea. Unfortunately the HW GCOS had to be replaced by a Multics machine which gave no end of problems. Happily that was not my problem.
