In about 1993 or so, at IBM, PL/I was
being supported by just one guy! If they
have a new release, then they may have
put some more people on it!
PL/I is not totally out of date! E.g., it
has some really sweetheart scope of names
rules. The On Conditions are generally
nicer than Try-Catch, e.g., if in a
code block A and do a Goto out of it
to a statement label in a containing
code block B (it's fair to call PL/I
a block structured language),
then the stack of that task (in some
ways nicer than just a thread)
is rolled (popped as in popping a
stack, which is essentially what happens)
back to the context of the last time
block B was active.
Block B can have a function F
that inherits names defined
in the blocks that contain
B, and block B can call a function
G, pass F as an entry variable,
and function G can call it's
parameter for function F, function
F can execute and access all the
variables it has access to that
function G may not. That can
be nice. I used it once when
scheduling the fleet for FedEx.
Can have tasks, like threads.
Can allocate some storage as, say,
controlled. Then when the
task ends, that allocated storage
is freed. That can be nice --
nice way to stop memory leaks
when have to kill a task.
PL/I has structures which
replace much of the utility of
classes. And the structures,
with arrays of structures of arrays
of structures of arrays, etc.,
are much faster than instances
of classes because all the
addressing is just a fairly
nice generalization of simple old
array addressing without pointers.
Such a structure can be based
which means that can allocate
one and get back a pointer to it.
So, that is a lot like allocating
an instance of a class. B can
be part of a structure A,
and B can be defined to be like
structure C -- so, can get
some inheritance.
The flat file I/O is much sweeter
than what is in C and was brought
over to, say, Visual Basic .NET
or C#.
PL/I will convert nearly any data type
to nearly any other, e.g., something
like a cast in the C family of
languages, but the documentation
says in very full and fine detail
just how each conversion is done.
There's a relatively powerful
pre-processor macro language
executed by the compiler
that can be used to generate a lot
of source code -- can be nice.
If they have tried to upgrade PL/I,
say, to 64 bit addressing,
maybe more on event handling,
some collection classes,
a sweet DB/2 or RDBMS interface
(it always had some DB syntax and
semantics in the language),
then it could be a nice language
even now.
It's been said that the golden age
of language design was the 1960s.
C was designed after PL/I and
was a really big step down
so that it could compile on a
DEC mini-computer with
8 KB of main memory while
PL/I always had at least
64 KB.
On VM/CMS and MVS,
PL/I didn't have access to TCP/IP,
but C did, so I wrote
some C code callable from PL/I
that gave PL/I access to
TCP/IP. Used it a little! Maybe
now TCP/IP is closer to being
native to the language.
I was in the group at IBM's Watson
lab that did the expert system
shell KnowledgeTool that was
implemented as a pre-processor to
PL/I. One night I stayed up until
dawn and coded the logic that
made rule subroutines fast,
functional, etc.
The key was to keep a crucial
part of our run time software
and the user's rule subroutine
on the stack of dynamic descendancy.
Gee, I got an award! The hourly
rate for that night was actually
relatively good!
It's been said that the golden age of language design was the 1960s. C was designed after PL/I and was a really big step down so that it could compile on a DEC mini-computer with 8 KB of main memory while PL/I always had at least 64 KB.
UNIX's success in the market brought C upon us.
Actually it was a very big step down, not only in terms of what other systems programming languages of the same era were capable of, but also in terms of security and compiler research.
One just has to look at PL/I, PL/M, Algol 68, Mesa and then to C.
Just as an example, Algol for B5000 systems (1961) already had the distinction between safe and unsafe code, with unsafe program modules requiring some form of "root" access. Sounds familiar?
Early in my career I wrote some Algol. So, got to love
block structured languages and adopted the style of
left margin indention then called publication Algol.
I was on the computer selection committee at FedEx, and
from what it had we were impressed with Algol, etc.
So a Burroughs system is what we recommended and got.
Alas, it was too slow. Soon the computing was way, way
behind, and Big Blue got called in and got a really
big, new account. The MVT/MVS family of operating systems,
with JCL, etc. was like an unanesthetized root canal
procedure while undergoing a barbed wire enema, but it
could get the work done.
Generally that computing is having problems with
virus is a total bummer -- we should be able to
run malicious code safely.
Gee, Flash keeps telling
me their code is a security risk. No joke! And
that's version 12 or so of their code. Flash guys,
I've got more to do than be a lab rat running on a
wheel going 'round and 'round downloading code.
Yup, looks like Flash guys or someone was correct:
I spent all of December and part of January fighting
a virus on Windows: Kept getting instances of
iexpore.exe running. Yes, that is the EXE of
Windows Internet Explorer (IE). So, I got those instances
even without starting IE. So, I ran Microsoft's latest
virus removal tools, days for each, and they found nothing.
The virus was still there. So, I did a Windows
System Restore back to the earliest copy I had, 2 months
ago. Seems to have worked. But that was about six
weeks of virus mud wrestling for no good reason.
A simple Google search shows that discussions about
fighing that
iexplore.exe problem is all over the Web;
apparently it is a very common virus.
Flash guys, are you to blame for that one?
Flash guys: Programming lesson 1 in Coding 101:
Check your input and detect any problems. If the
input is not suitably clean, then
refuse to use it. If the specifications of
your input is too complicated for a check,
at least good checks while running, then
correct your specifications. Flash guys,
I can understand one bug, but 12? Are you
guys even trying, I mean trying to fix
bugs instead of pushing users to
download?
And Microsoft guys, why do you let your code
let bad guys somewhere east of Moscow
mess up my computer? You guys just like
shipping bugs? Believe me, I do not
like fixing viruses.
As I recall, Multics was written in PL/I. Prime
had a version of PL/I and used it for much of their
operating system.
Once Google ran a recruiting ad and I sent them a
resume. I got a phone call from one of their
recruiters, and his big question was "What is your
favorite programming language?"
I said, "PL/I".
Wrong answer! Likely he was looking for C++.
Come on guy, I want to do something other than
fight memory leaks -- in PL/I if some work
is some part of my code raises an On Condition
(a software version of an interrupt, which
might also have been from a hardware interrupt),
then in the code block that gets executed by
the On Unit that has been established
for that condition, can decide what to do
with the interrupt. So, one thing to do is just
to kill off that work that raised the interrupt.
So, say that the block of the On Unit
that gets executed is X in code block B,
some code in block B did the function call
that got the work going, and just want to
kill off that work. So, from block X just
do a Goto to the statement label want
in block B and not in block X, and presto, bingo, that
work is killed off, that is, wiped clean
by the wrath of non-local Goto. So, in particular,
likely all the storage (all except based
storage) allocated by that worked to be killed
off is freed. So, look, Ma, no memory leaks
from exceptional condition handling!
Google guys: The original definition of C++
was just as a pre-processor to C. And you want
to assume that that is a lot better than
what IBM, George Radin, etc. did with PL/I?
Do you have anyone who understands PL/I?
I got introduced to computers with a Timex 2068 back in 1986, but as a language geek I always researched the old systems.
Additionally I managed to use a few languages of the Algol family for systems programing, hence strenghting my belief in safe systems programmin.
One of the best quotes I keep recalling is the Turing Award speech from Hoare, where he mentions his company customers were against having support to disable bounds checking in Algol compilers. Yet here we are.
Every time I check the CVE list I wish UNIX had never left AT&T labs.
Comments
In about 1993 or so, at IBM, PL/I was being supported by just one guy! If they have a new release, then they may have put some more people on it!
PL/I is not totally out of date! E.g., it has some really sweetheart scope of names rules. The On Conditions are generally nicer than Try-Catch, e.g., if in a code block A and do a Goto out of it to a statement label in a containing code block B (it's fair to call PL/I a block structured language), then the stack of that task (in some ways nicer than just a thread) is rolled (popped as in popping a stack, which is essentially what happens) back to the context of the last time block B was active.
Block B can have a function F that inherits names defined in the blocks that contain B, and block B can call a function G, pass F as an entry variable, and function G can call it's parameter for function F, function F can execute and access all the variables it has access to that function G may not. That can be nice. I used it once when scheduling the fleet for FedEx.
Can have tasks, like threads. Can allocate some storage as, say, controlled. Then when the task ends, that allocated storage is freed. That can be nice -- nice way to stop memory leaks when have to kill a task.
PL/I has structures which replace much of the utility of classes. And the structures, with arrays of structures of arrays of structures of arrays, etc., are much faster than instances of classes because all the addressing is just a fairly nice generalization of simple old array addressing without pointers.
Such a structure can be based which means that can allocate one and get back a pointer to it. So, that is a lot like allocating an instance of a class. B can be part of a structure A, and B can be defined to be like structure C -- so, can get some inheritance.
The flat file I/O is much sweeter than what is in C and was brought over to, say, Visual Basic .NET or C#.
PL/I will convert nearly any data type to nearly any other, e.g., something like a cast in the C family of languages, but the documentation says in very full and fine detail just how each conversion is done.
There's a relatively powerful pre-processor macro language executed by the compiler that can be used to generate a lot of source code -- can be nice.
If they have tried to upgrade PL/I, say, to 64 bit addressing, maybe more on event handling, some collection classes, a sweet DB/2 or RDBMS interface (it always had some DB syntax and semantics in the language), then it could be a nice language even now.
It's been said that the golden age of language design was the 1960s. C was designed after PL/I and was a really big step down so that it could compile on a DEC mini-computer with 8 KB of main memory while PL/I always had at least 64 KB.
On VM/CMS and MVS, PL/I didn't have access to TCP/IP, but C did, so I wrote some C code callable from PL/I that gave PL/I access to TCP/IP. Used it a little! Maybe now TCP/IP is closer to being native to the language.
I was in the group at IBM's Watson lab that did the expert system shell KnowledgeTool that was implemented as a pre-processor to PL/I. One night I stayed up until dawn and coded the logic that made rule subroutines fast, functional, etc. The key was to keep a crucial part of our run time software and the user's rule subroutine on the stack of dynamic descendancy. Gee, I got an award! The hourly rate for that night was actually relatively good!
PL/I doesn't have to be so bad!
UNIX's success in the market brought C upon us.
Actually it was a very big step down, not only in terms of what other systems programming languages of the same era were capable of, but also in terms of security and compiler research.
One just has to look at PL/I, PL/M, Algol 68, Mesa and then to C.
Just as an example, Algol for B5000 systems (1961) already had the distinction between safe and unsafe code, with unsafe program modules requiring some form of "root" access. Sounds familiar?
Burroughs, being a stack machine, had MMU like qualities 'for free. Desktop got there 25 years later.
Early in my career I wrote some Algol. So, got to love block structured languages and adopted the style of left margin indention then called publication Algol.
I was on the computer selection committee at FedEx, and from what it had we were impressed with Algol, etc. So a Burroughs system is what we recommended and got.
Alas, it was too slow. Soon the computing was way, way behind, and Big Blue got called in and got a really big, new account. The MVT/MVS family of operating systems, with JCL, etc. was like an unanesthetized root canal procedure while undergoing a barbed wire enema, but it could get the work done.
Generally that computing is having problems with virus is a total bummer -- we should be able to run malicious code safely.
Gee, Flash keeps telling me their code is a security risk. No joke! And that's version 12 or so of their code. Flash guys, I've got more to do than be a lab rat running on a wheel going 'round and 'round downloading code.
Yup, looks like Flash guys or someone was correct: I spent all of December and part of January fighting a virus on Windows: Kept getting instances of iexpore.exe running. Yes, that is the EXE of Windows Internet Explorer (IE). So, I got those instances even without starting IE. So, I ran Microsoft's latest virus removal tools, days for each, and they found nothing. The virus was still there. So, I did a Windows System Restore back to the earliest copy I had, 2 months ago. Seems to have worked. But that was about six weeks of virus mud wrestling for no good reason.
A simple Google search shows that discussions about fighing that iexplore.exe problem is all over the Web; apparently it is a very common virus.
Flash guys, are you to blame for that one?
Flash guys: Programming lesson 1 in Coding 101: Check your input and detect any problems. If the input is not suitably clean, then refuse to use it. If the specifications of your input is too complicated for a check, at least good checks while running, then correct your specifications. Flash guys, I can understand one bug, but 12? Are you guys even trying, I mean trying to fix bugs instead of pushing users to download?
And Microsoft guys, why do you let your code let bad guys somewhere east of Moscow mess up my computer? You guys just like shipping bugs? Believe me, I do not like fixing viruses.
As I recall, Multics was written in PL/I. Prime had a version of PL/I and used it for much of their operating system.
Once Google ran a recruiting ad and I sent them a resume. I got a phone call from one of their recruiters, and his big question was "What is your favorite programming language?"
I said, "PL/I".
Wrong answer! Likely he was looking for C++.
Come on guy, I want to do something other than fight memory leaks -- in PL/I if some work is some part of my code raises an On Condition (a software version of an interrupt, which might also have been from a hardware interrupt), then in the code block that gets executed by the On Unit that has been established for that condition, can decide what to do with the interrupt. So, one thing to do is just to kill off that work that raised the interrupt. So, say that the block of the On Unit that gets executed is X in code block B, some code in block B did the function call that got the work going, and just want to kill off that work. So, from block X just do a Goto to the statement label want in block B and not in block X, and presto, bingo, that work is killed off, that is, wiped clean by the wrath of non-local Goto. So, in particular, likely all the storage (all except based storage) allocated by that worked to be killed off is freed. So, look, Ma, no memory leaks from exceptional condition handling!
Google guys: The original definition of C++ was just as a pre-processor to C. And you want to assume that that is a lot better than what IBM, George Radin, etc. did with PL/I? Do you have anyone who understands PL/I?
Many thanks for the history part.
I got introduced to computers with a Timex 2068 back in 1986, but as a language geek I always researched the old systems.
Additionally I managed to use a few languages of the Algol family for systems programing, hence strenghting my belief in safe systems programmin.
One of the best quotes I keep recalling is the Turing Award speech from Hoare, where he mentions his company customers were against having support to disable bounds checking in Algol compilers. Yet here we are.
Every time I check the CVE list I wish UNIX had never left AT&T labs.