Interesting that it is available for OS/2 and not Windows.
If you are already supporting Linux and OS/2, it isn't much more work to support Windows too–and will likely attract many more users than OS/2 support will
The FAQ [0] says:
> Iron Spring PL/I is free for non-commercial and hobbyiest use. The price of the commercial version has not yet been determined, but will be approximately two orders of magnitude less than IBM's compiler for Windows. Academic, Government, and Volume licenses will be available. A CD will be available at additional cost.
I'm sceptical the commercial version is ever going to happen now. This is a very small and shrinking market, 20 years ago selling it would have been a tough gig but you might have had some success, the same success today is going to be orders of magnitude harder. If you had a time machine to take this product back to the 1990s, it probably would have done much better, though even there it would have been a decisively niche product.
> The compiler is currently closed-source.
I wonder why people do this – I get why you want to keep your software closed source if you have realistic plans to commercially exploit it – but if you don't, why not just let people have the source code?
I've heard before stories about solo closed source developers who suddenly and unexpectedly die, and they'd left the source code on an encrypted disk, and even if their family gives some technical friend permission to try to retrieve it, turns out to be impossible because nobody knows the password. Open source, not an issue.
> I've heard before stories about solo closed source developers who suddenly and unexpectedly die, and they'd left the source code on an encrypted disk, and even if their family gives some technical friend permission to try to retrieve it, turns out to be impossible because nobody knows the password. Open source, not an issue.
I feel we need more code escrows for that reason. Keep it commercial till you die, fine, but let it live on afterwards.
glhaynes · 1d ago
Best guess: that's because no organizations are writing their first PL/I apps in 2025; and there aren't many PL/I-using organizations who weren't big IBM customers, who largely migrated from OS/2 to Linux. So I wouldn't be shocked if a Windows version wouldn't bring in enough money to make even a relatively easy port worth it.
Next-to-best guess: author was an OS/2-head, many of whom have been hating M$ Windoze for 30 years at this point! Ah, those were good days.
skissane · 1d ago
> So I wouldn't be shocked if a Windows version wouldn't bring in enough money to make even a relatively easy port worth it.
True, but I’m sceptical the Linux or OS/2 versions have ever brought in any money either.
This looks to me suspiciously like a hobby project masquerading as a commercial venture
vincent-manis · 1d ago
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.)
pjmlp · 12h ago
It is one of my favourite languages, but somehow I think C++ has gotten beyond the complexity level PL/I was famous for among language designers, and you kind of refer to.
Apparently, we always end up having to reboot language design after a certain threshold of putting features into them.
shrubble · 1d ago
There is MULTICS, which was released as open source a while ago, and an emulator was written for it also.
Since MULTICS had a high quality PL/I compiler, you can install the emulator to play with the language. The "shell" is different from Unix but shares some similarities.
There is also a CP/M PL/I compiler, and apparently also CPM-86 and DOS versions.
Simply because some of the source file (1 or 2) for CPM are written in PL/1, rather than the majority having been written in PL/M, then eventually translated to assembler.
PLI-80 BINARY : 146K This is the PLI compiler. It is very compatible with the IBM PLI compiler used on the 360. The only functions I found missing were DATE and TIME, which were easy to fake out. (Apparently this is version 1.0).
PLI-80 version 1.3 : 111K Here is the PLI-80 version 1.3 compiler and libraries.
PL/I-80 version 1.4: 188K - version 1.4 including quite a few example files
pdw · 1d ago
According to their news page, they started development on OS/2... in 2007... Amazing.
> 5 Nov, 2007: Iron Spring Software announces the availability of the first alpha version of their new PL/I compiler. The alpha runs on the OS/2 operating system only.
OhMeadhbh · 1d ago
why?
trealira · 1d ago
There are some books at my university about how to program on PL/1. So, I've wanted to write some code with it out of sheer curiosity for some time (especially given a lot of the "interesting features" I've heard about that modern languages don't all have). I only lacked a compiler to use. Thanks for finding one, OP.
palmotea · 1d ago
> (especially given a lot of the "interesting features" I've heard about that modern languages don't all have)
Such as?
adrian_b · 1d ago
The language PL/I included in its specification many things that are omitted in most modern languages, being implemented in libraries or in the operating system, e.g. for handling threads (tasks in IBM lingo), exceptions, signals, events.
However the integration in the language of those features made them frequently more convenient and I consider the pthreads API available in UNIX/Linux as considerably inferior to the thread handling that PL/I already had in 1965 (e.g. already then PL/I had an equivalent of WaitForMultipleEvents that was better than anything in pthreads).
Even if the C language has evolved from BCPL, most of its evolution has consisted in taking various features either from PL/I or from Algol 68. The C language has introduced very few innovations, i.e. only the "continue" statement and its more general (but more verbose and cumbersome) syntax for the "for" statement. Therefore many features of C and of its descendants come from PL/I, e.g. "struct", ".", "->", "malloc" and "free", signals and many others.
Also PL/I allowed aggregates, i.e. arrays and structures, in many contexts where most modern languages accept only scalar variables, requiring verbose loops for handling aggregates (or the definition of custom object classes, i.e. the implementation of some library for handling them).
pjmlp · 12h ago
And removed two big ones, bounds checkings and proper arrays.
trealira · 1d ago
I remember reading this link that went through them, but the link is dead now:
But a couple interesting things I remember hearing (though I'm not sure if they were in the linked page) were passing alternate return address labels to functions, and resumable exceptions (although Lisp and Ruby do have this).
Also, not that unique, but that no keywords are reserved, and so you can have variables named "if" and such.
jll29 · 1d ago
I also wrote a language in which keywords are not reserved,
called Leazy, during high school ( https://github.com/jochenleidner/leazy ), but just for fun.
It`s arguably a good idea to treat keywords as reserved, in order to avoid confusion and to write faster compilers.
No-one should (be able to) write confusing code like:
if if = then then then = else else else = end end if
It's good to have a PL/1 compiler available to those that hwve legacy needs and that want to learn about the language, but it has been said it was overly complex (what I read about it sound like it was "the C++ of its time"). Since then, many language designers, at least the good ones (e.g. Wirth, Gosling), have recognized that less is more.
trealira · 1d ago
Thanks for sharing your old compiler and the source code listing for it, though I can't read the documentation in German.
Out of curiosity, how did you deal with the fact that for a top-down parser, 1 token of lookahead isn't enough to know if, say, you're dealing with an if-statement (e.g. "if x > 0 then ...") or an assignment or procedure call using a variable named "if" (e.g. "if = 1", "if(x, y, z)")?
I feel like the best solution would be an LR parser that reduced to an if statement only when seeing "if <expr> then" (and I saw you mentioned LALR and LL parsers somehow in your documentation), but you could also maybe use a backtracking top down parser.
I realize could read the source code listing, but I think it would be easier just to ask, and I might misunderstand it.
dfawcus · 1d ago
Would that be this, using the current version of the TUHS archive?
Yes, that's it, thanks. I knew the site wasn't dead, so I was confused why the link seemingly was.
pjmlp · 1d ago
Bounds checking in strings and arrays in a well known systems language, 10 years younger. :)
kjellsbells · 1d ago
I dont sense much love in the comments, but I find this kind of computing niche kind of useful. There is more to life than arguments over Rust. Computer systems can have lifetimes measured in multiple generations. Etc. It is interesting to see what is going on elsewhere in the galaxy, so to speak.
These guys seem passionate about what they do in the same way that other niche companies are, e.g. Isode with X.400 or Arca Noae on OS/2. Good luck to them.
The blurb for their lead guy claims he's been involved in PL/I since 1965. I'm estimating that would make him 80 now. If he is still cranking out compiler code at 80 I hope this is a golden years/fun project for him.
Koshkin · 1d ago
./plic advent.pli
(ERR999)No valid statements in source program
(Goes back to reading an article about Common Lisp.)
rep_lodsb · 1d ago
You need to specify margins for advent.pli (because the text outside them is not part of the source code), and an output file name:
This was my first programming language. CS 101 was taught in PL/I, on punch cards, when I went to college. We actually used a Cornell dialect called "PL/C"
While it's called "Pee el one" it's rendered PL/I. So the title is wrong; the article has it correct. Please fix it! See: https://en.wikipedia.org/wiki/PL/I
Polizeiposaune · 1d ago
In the context of Multics it was generally spelled "PL/1" rather than "PL/I" (the latter being IBM usage); source files named xxx.pl1, compiled with the "pl1" command. See for instance https://www.multicians.org/pl1-raf.html
If you are already supporting Linux and OS/2, it isn't much more work to support Windows too–and will likely attract many more users than OS/2 support will
The FAQ [0] says:
> Iron Spring PL/I is free for non-commercial and hobbyiest use. The price of the commercial version has not yet been determined, but will be approximately two orders of magnitude less than IBM's compiler for Windows. Academic, Government, and Volume licenses will be available. A CD will be available at additional cost.
I'm sceptical the commercial version is ever going to happen now. This is a very small and shrinking market, 20 years ago selling it would have been a tough gig but you might have had some success, the same success today is going to be orders of magnitude harder. If you had a time machine to take this product back to the 1990s, it probably would have done much better, though even there it would have been a decisively niche product.
> The compiler is currently closed-source.
I wonder why people do this – I get why you want to keep your software closed source if you have realistic plans to commercially exploit it – but if you don't, why not just let people have the source code?
I've heard before stories about solo closed source developers who suddenly and unexpectedly die, and they'd left the source code on an encrypted disk, and even if their family gives some technical friend permission to try to retrieve it, turns out to be impossible because nobody knows the password. Open source, not an issue.
[0] http://www.iron-spring.com/faq.html
I feel we need more code escrows for that reason. Keep it commercial till you die, fine, but let it live on afterwards.
Next-to-best guess: author was an OS/2-head, many of whom have been hating M$ Windoze for 30 years at this point! Ah, those were good days.
True, but I’m sceptical the Linux or OS/2 versions have ever brought in any money either.
This looks to me suspiciously like a hobby project masquerading as a commercial venture
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.)
Apparently, we always end up having to reboot language design after a certain threshold of putting features into them.
Since MULTICS had a high quality PL/I compiler, you can install the emulator to play with the language. The "shell" is different from Unix but shares some similarities.
About 3/4 of the way down this page, is the PL/I source code: https://multicians.org/pl1.html
Simply because some of the source file (1 or 2) for CPM are written in PL/1, rather than the majority having been written in PL/M, then eventually translated to assembler.
Here we go:
http://www.cpm.z80.de/binary.html
> 5 Nov, 2007: Iron Spring Software announces the availability of the first alpha version of their new PL/I compiler. The alpha runs on the OS/2 operating system only.
Such as?
However the integration in the language of those features made them frequently more convenient and I consider the pthreads API available in UNIX/Linux as considerably inferior to the thread handling that PL/I already had in 1965 (e.g. already then PL/I had an equivalent of WaitForMultipleEvents that was better than anything in pthreads).
Even if the C language has evolved from BCPL, most of its evolution has consisted in taking various features either from PL/I or from Algol 68. The C language has introduced very few innovations, i.e. only the "continue" statement and its more general (but more verbose and cumbersome) syntax for the "for" statement. Therefore many features of C and of its descendants come from PL/I, e.g. "struct", ".", "->", "malloc" and "free", signals and many others.
Also PL/I allowed aggregates, i.e. arrays and structures, in many contexts where most modern languages accept only scalar variables, requiring verbose loops for handling aggregates (or the definition of custom object classes, i.e. the implementation of some library for handling them).
https://minnie.tuhs.org/pipermail/tuhs/2021-November/024695....
But a couple interesting things I remember hearing (though I'm not sure if they were in the linked page) were passing alternate return address labels to functions, and resumable exceptions (although Lisp and Ruby do have this).
Also, not that unique, but that no keywords are reserved, and so you can have variables named "if" and such.
It`s arguably a good idea to treat keywords as reserved, in order to avoid confusion and to write faster compilers.
No-one should (be able to) write confusing code like:
It's good to have a PL/1 compiler available to those that hwve legacy needs and that want to learn about the language, but it has been said it was overly complex (what I read about it sound like it was "the C++ of its time"). Since then, many language designers, at least the good ones (e.g. Wirth, Gosling), have recognized that less is more.Out of curiosity, how did you deal with the fact that for a top-down parser, 1 token of lookahead isn't enough to know if, say, you're dealing with an if-statement (e.g. "if x > 0 then ...") or an assignment or procedure call using a variable named "if" (e.g. "if = 1", "if(x, y, z)")?
I feel like the best solution would be an LR parser that reduced to an if statement only when seeing "if <expr> then" (and I saw you mentioned LALR and LL parsers somehow in your documentation), but you could also maybe use a backtracking top down parser.
I realize could read the source code listing, but I think it would be easier just to ask, and I might misunderstand it.
https://www.tuhs.org/pipermail/tuhs/2021-November/024695.htm...
These guys seem passionate about what they do in the same way that other niche companies are, e.g. Isode with X.400 or Arca Noae on OS/2. Good luck to them.
The blurb for their lead guy claims he's been involved in PL/I since 1965. I'm estimating that would make him 80 now. If he is still cranking out compiler code at 80 I hope this is a golden years/fun project for him.
While it's called "Pee el one" it's rendered PL/I. So the title is wrong; the article has it correct. Please fix it! See: https://en.wikipedia.org/wiki/PL/I
Fixed.