You are making four big mistakes: First you are angry. You are not so much attacking PL/I as attacking me personally. Nope. Besides noting that you have very l

You are making four big mistakes: First you are angry. You are not so much attacking PL/I as attacking me personally. Nope. Besides noting that you have very little knowledge in PL research at the end, I made no comments about you personally. Second you are pursuing religious arguments about programming languages. Nope, I specifically mentioned practical things that matter. Third you are arguing things about PL/I that are really not part of the language. If you're talking about things like, "no one knows PL/I," so what? This is entirely relevant from an engineering standpoint. Just because it's not "really part of the language" is irrelevant because we're not debating whether or not PL/I is better than C/C++ in the 1950s in a perfect world, we're talking about practical engineering right now on real systems. Fourth much of what you say about PL/I is technically wrong. Not a one. What PL/I compilers are awful? As far as I know, there aren't very many and the more common ones there are, essentially all from IBM, are highly polished. Only if you're using compiler benchmarks from the 90's. I'm looking for things like packrat parsing and partial and incremental linking. Auto SSE/SIMD would be nice. If you're so convinced that IBM PL/I is good enough, why don't you benchmark it against GCC (on Intel ICC often outperforms GCC but I'm confident even GCC will far outperform PL/I). That it's my 'favorite' doesn't mean that I suggest that others use it. I used the IBM PL/I on OS/2 a few times; I have the IBM PL/I for Windows but don't even have it installed. On Windows I use Visual Basic .NET, if only because it has such good access to .NET, ADO.NET, and ASP.NET. In many ways, I would prefer PL/I, but it is not a practical option. My entire post was about how it's not a practical option and how you shouldn't be surprised when no one wants to use PL/I in production... PL/I has some features that were deliberately included to make learning it relatively easy. E.g., PL/I has no reserved words! That is, all the 'key' words in the language can be used by programmers for their own identifier names. So, a beginner doesn't have to worry about using a reserved word. I taught some elementary parts of PL/I to some not very good students in the business school at Georgetown University, and they learned fine. This is unimportant. Arguably it's worse than having reserved words because it allows for inadvertent shadowing, but really it's just a back-and-forth thing that no one cares about. For 3, the only serious problem with 'type safety' is for pointers. True, in PL/I, pointers do not have 'types' based on what they point to. That is, any pointer can point to anything. But, then, using pointers in PL/I is not nearly as necessary or common as in C/C++, is quite advanced, and is not common. I liked using pointers because can really work with the memory and, at times, write some 'polymorphic' functions. Tricky work with pointers is always tricky, and that the pointers in PL/I are not 'strongly typed' didn't make the work harder. Again, PL/I is not nearly as dependent on pointers as C; a C programmer is forced to used pointers frequently, and PL/I programmer can do fine using pointers only rarely. You completely misunderstood -- C and C++ are the standards. If you want people to use something not-standard you need to provide something which is far better in your own language than in the standards in order to compel people to switch. Being a little bit better isn't good enough, you need to be a lot better. Strong typing, garbage collection, and higher-order functions are all things which suck in C/C++. If you want people to adopt your language you should offer full support for these things because that gives you a compelling reason to switch. Otherwise on types, PL/I took the attitude... Read more about strong typing and read about type or category theory (preferably both). C and Java types are not strong typing, they're typing done in probably the worst possible way. Learn ML. Or can do a calculation, enter a Begin-End block and do the automatic allocation inside that block. Welcome to RAII, circa 2000. To get around the problem, end up using C structures or C++ classes, both of which are much less efficient. Only in C or C++ compilers from 1995... Actually, can claim that for some years Rexx, with a few extensions for some lower level OS access, basically 'ran' all of IBM: There were about 4000 mainframes around the world connected with simple bisync lines. In the end, it all looked much like the Internet today. So, the mainframes were acting as both the servers and the routers. The hard work of the routing, security, etc. was done with 'server virtual machines' programmed mostly in Rexx with a few routines for some lower level access. It worked surprisingly well. Rexx was no toy. It really is. IBM hasn't even come close to building what would be termed a modern distributed system infrastructure. There's no PL/I equivalent for MapReduce, BigTable, GFS, etc. A lot of nonsense. On IBM, PL/I used standard OS calling sequences. Calling Fortran, Cobol, assembler, and C was routine. I wrote a collection of routines in PL/I to call C to call the TCP/IP routines. Occasionally I called assembler from PL/I. OS calling sequences are the bare-minimum. If I wanted to optimize my Python code by dropping down and rewriting the code in a systems language, C has my back. Good luck with PL/I. You seem to be using a lot of examples from HPC but they're not really relevant. HPC is a pretty easy target because you get to make a lot of assumptions about the DS you're architecting and the software that will be run on it. PL/I is just a dead language -- there's no reason to ever switch to it and while it may have been slightly better than C++ during IBM's heyday, the world has moved on. Even scientific computing prefers parallel Fortran, which ever since the latest version is incredibly fast.