old book with examples in PL/I: will a C-guy understand them?

[Cerebus]

Should it be a surprise that 40 odd years after you were initially taught it, a field that wasn't even 40 years old at the time you were taught it has moved on a bit? Mind you, some things haven't, we still get a new "the best thing since sliced bread" fashion every three years.

I do hope that gap in your continuing education was an isolated thing and you're not going to be taken by surprise that we now have hand-held battery powered portable computers with built-in voice and data communications?  On the other hand, if you are, do you have a box of 80 column cards going spare? I ran out of bookmarks about 30 years ago. 

If one thinks computer science has moved on a bit the progress has been glacial compared to biochemistry. When I was studying computer science (around the same time as you) by then-to-be-future-ex-wife was studying biochemistry. In her field at the time the ability to practically determine short DNA sequences was just starting up. A whole PhD might be taken up by laboriously manually sequencing and mapping a single gene or a small handful. In 1990 the human genome project started, and by 2003 they finished and had one complete human DNA sequence, after spending $2.7 billion. I heard recently that the current cost of sequencing an entire person's DNA is about £400 GBP and can be done in a day, one single day.

[rstofer]

This book was printed in 1969

That would do it.  It was about 10 years later when the Oil Company IBM shop I had my summer job at was starting to go "IBM is really trying to push PL/1 a a replacement for Fortran; I guess we should start taking that seriously!"(Note that dealing with "bytes" in fortran was also rather challenging!)

For the IBM1130, there was a Commercial Subroutine Package that dealt with bytes (or chars) and had string functions and fancy formatting capabilities.  The library was callable from Fortran and this really allowed Fortran to be used for business work.  This was circa '70...

I ran into PL/I in grad school circa '75.  I liked the language and I'm surprised it didn't last.  Fortran and COBOL will be with us forever.

[westfw]

Should it be a surprise that 40 odd years after you were initially taught it, a field that wasn't even 40 years old at the time you were taught it has moved on a bit?

No, it shouldn't be.  And I wasn't really surprised, after my initial reaction.

I think I sort-of thought that most of CS was like math - long established stuff that's only had a few small changes, plus a bunch of stuff that was "Engineering" - things that were previously known, but only became possible because of increased speed, increased memory, etc...  I guess that's why I only consider myself an "engineer" rather than a "scientist."  I don't think I've ever discovered a new algorithm for anything; I just make the algorithms someone else has done run faster (or smaller, or on a new chip, or whatever.)

[westfw]

do you have a box of 80 column cards going spare?

You mean like these?

No, of course not.  Why would I save something like that?  :-)

[MarkMLl]

I think I sort-of thought that most of CS was like math - long established stuff

In part that's because of the role of Knuth as the subject's foundation author.

I think that what's needed is a dissection of vols 1-3 plus his original notes for vol 4 and anything he's got for later volumes, since that would define a snapshot of the state of the art when he first roughed them out. After that annotate each algorithm or dictum with references to anything that's superseded it, so that it remains a defining work rather than a tome that everybody aspires to read as a rite of passage but becomes less useful as the years pass.

MarkMLl

[SiliconWizard]

If one thinks computer science has moved on a bit the progress has been glacial compared to biochemistry.

Yep. Actually, I think westfw - if I got what he said correctly - is mostly right. CS has not "moved on" that much. There is no real breakthrough in CS that I can think of. Most of the evolution is "engineering", as he said. Nothing really fundamental. And yes, CS is, for a large part, a branch of mathematics.

Now if you can cite even one breakthrough in CS that has happened in the last 40 years - and that is really a fundamental point, and not just iterative engineering - I'll be glad to read about it and discuss it.

There sure have been a bunch of new algorithms. But do you consider them fundamental advances in CS? That's up for some debate. I tend to consider them "engineering", mostly iterations on existing principles.

[Cerebus]

There sure have been a bunch of new algorithms. But do you consider them fundamental advances in CS? That's up for some debate. I tend to consider them "engineering", mostly iterations on existing principles.

If you said "proofs" in place of "algorithms" and "mathematics" in place of "CS" you'd have a bunch of mathematicians, including some Field's Medal and Nobel Prize winners hunting your scalp. Algorithms are the lifeblood of computing, and inventing significant ones de novo is definitely a step above engineering.

[DiTBho]

I don't think I've ever discovered a new algorithm for anything

I was at the train station with a Japanese PDA in my hands, the kind of tool I usually write C-stuff in, and I was thinking that I had just discovered a new algorithm for parsing mathematical expressions specified in infixed notation and already able to manage the stack with function arguments ... when suddenly a quick look at the Holy Book mentioned - like a gun shot - that *The* algorithm was invented by Edsger Dijkstra and named the "shunting yard" algorithm because its operation resembles that of a railroad shunting yard.

D'oh 

ok, ok, I don't think I've ever discovered a new algorithm for anything.

[guenthert]

But back to the original question:  will PL/I make sense to a programmer (most) familiar with C?
PL/I is a bit of an oddball in that it supports recoverable exceptions (I only know of Common Lisp which offers the same) for which some support of dynamic scoping (like old LISPs) is needed.  That'll be quite alien to a C programmer.

[SiliconWizard]

There sure have been a bunch of new algorithms. But do you consider them fundamental advances in CS? That's up for some debate. I tend to consider them "engineering", mostly iterations on existing principles.

If you said "proofs" in place of "algorithms" and "mathematics" in place of "CS" you'd have a bunch of mathematicians, including some Field's Medal and Nobel Prize winners hunting your scalp. Algorithms are the lifeblood of computing, and inventing significant ones de novo is definitely a step above engineering.

If I said "my uncle" instead of "my aunt", she'd probably have a pair.
So can anyone really see some breakthrough in CS in the last 40 years?

I'm surprised no one talked about quantum computing. That would be the only serious candidate here IMO, although I'm still a bit interrogative about its usability and whether we'll be able to scale that up enough to do really useful work with it. But as far as breakthroughs go, that would probably be it.

[SiliconWizard]

But back to the original question:  will PL/I make sense to a programmer (most) familiar with C?
PL/I is a bit of an oddball in that it supports recoverable exceptions (I only know of Common Lisp which offers the same) for which some support of dynamic scoping (like old LISPs) is needed.  That'll be quite alien to a C programmer.

As I initially said, define "understand" first.

If by that you mean being able to read PL/1 code and feel in a familiar territory without it looking like a succession of weird symbols and tokens, then sure. (As opposed to someone familiar with C reading Smalltak code, for instance...)

But if by that you mean being really able to decipher *exactly* what a given piece of code does, then you'll just need to RTFM. Just like with any other language, no matter how close it is to C. Just because C++ and Java are relatively familiar to look at when you're familiar with C, for instance, doesn't mean you'll fully understand code written in them unless you learn them. So, not sure what more can be told that hasn't already been told here: yes it's a procedural language that should look familiar to people used to procedural languages, but that probably stops there.

[brucehoult]

But back to the original question:  will PL/I make sense to a programmer (most) familiar with C?
PL/I is a bit of an oddball in that it supports recoverable exceptions (I only know of Common Lisp which offers the same) for which some support of dynamic scoping (like old LISPs) is needed.  That'll be quite alien to a C programmer.

And Dylan.

It's pretty simple. Basically the catch block is compiled the same as a nested function (with visibility of local variables in the enclosing function), and added to a list of handlers. When an exception is encountered the handler is searched for and run WITHOUT unwinding the stack first. If the exception can be recovered from then the handler does that and just returns. If it's not recoverable then a non-local GOTO is done to the code after the catch block -- using setjmp/longjmp or a similar mechanism.

gcc supports nested functions so you could do the same thing in slightly enhanced C if you wanted to do the bookkeeping manually.

[SiliconWizard]

And Dylan.

It's pretty simple. Basically the catch block is compiled the same as a nested function (with visibility of local variables in the enclosing function), and added to a list of handlers. When an exception is encountered the handler is searched for and run WITHOUT unwinding the stack first. If the exception can be recovered from then the handler does that and just returns. If it's not recoverable then a non-local GOTO is done to the code after the catch block -- using setjmp/longjmp or a similar mechanism.

That doesn't sound too shabby.

[guenthert]

But back to the original question:  will PL/I make sense to a programmer (most) familiar with C?
PL/I is a bit of an oddball in that it supports recoverable exceptions (I only know of Common Lisp which offers the same) for which some support of dynamic scoping (like old LISPs) is needed.  That'll be quite alien to a C programmer.

And Dylan.

Yeah, it's a pity that Dylan didn't make it.  I thought it had the nice features of a modern Lisp with infix notation (the later releases of Dylan at least) for mass-appeal.

It's pretty simple. Basically the catch block is compiled the same as a nested function (with visibility of local variables in the enclosing function), and added to a list of handlers. When an exception is encountered the handler is searched for and run WITHOUT unwinding the stack first. If the exception can be recovered from then the handler does that and just returns. If it's not recoverable then a non-local GOTO is done to the code after the catch block -- using setjmp/longjmp or a similar mechanism.

gcc supports nested functions so you could do the same thing in slightly enhanced C if you wanted to do the bookkeeping manually.

Hmmh, I have no firsthand experience, but I thought PL/I's exception handling would be even more like Common Lisp in that for function not defining a handler, but called by those which did, *that* handler would be used (the dynamic scoping part).  I don't think that is easily replicable with longjmps or nested functions.

[brucehoult]

But back to the original question:  will PL/I make sense to a programmer (most) familiar with C?
PL/I is a bit of an oddball in that it supports recoverable exceptions (I only know of Common Lisp which offers the same) for which some support of dynamic scoping (like old LISPs) is needed.  That'll be quite alien to a C programmer.

And Dylan.

Yeah, it's a pity that Dylan didn't make it.  I thought it had the nice features of a modern Lisp with infix notation (the later releases of Dylan at least) for mass-appeal.

Maybe its time has simply not yet arrived :-)

It's pretty simple. Basically the catch block is compiled the same as a nested function (with visibility of local variables in the enclosing function), and added to a list of handlers. When an exception is encountered the handler is searched for and run WITHOUT unwinding the stack first. If the exception can be recovered from then the handler does that and just returns. If it's not recoverable then a non-local GOTO is done to the code after the catch block -- using setjmp/longjmp or a similar mechanism.

gcc supports nested functions so you could do the same thing in slightly enhanced C if you wanted to do the bookkeeping manually.

Hmmh, I have no firsthand experience, but I thought PL/I's exception handling would be even more like Common Lisp in that for function not defining a handler, but called by those which did, *that* handler would be used (the dynamic scoping part).  I don't think that is easily replicable with longjmps or nested functions.

Same thing. The list (stack really) of handler functions is separate from the normal call stack. A function with a try block adds the handler to the front of the list and it's available as the (currently) first handler for all functions it calls, functions those functions call etc, unless one of them adds another handler to the start of the list. When the try block exits the handler is popped off the list.  (The handler list might well be local list node structs as local variables in the stack frame of each function that has a try block, not heap allocated, as the lifetime is the same).

[MarkMLl]

But back to the original question:  will PL/I make sense to a programmer (most) familiar with C?
PL/I is a bit of an oddball in that it supports recoverable exceptions (I only know of Common Lisp which offers the same) for which some support of dynamic scoping (like old LISPs) is needed.  That'll be quite alien to a C programmer.

As does Object Pascal, any language which supports an eval() e.g. Perl, and for that matter I know of an ALGOL-60 implementation which goes some way towards having them.

MarkMLl

[brucehoult]

But back to the original question:  will PL/I make sense to a programmer (most) familiar with C?
PL/I is a bit of an oddball in that it supports recoverable exceptions (I only know of Common Lisp which offers the same) for which some support of dynamic scoping (like old LISPs) is needed.  That'll be quite alien to a C programmer.

As does Object Pascal, any language which supports an eval() e.g. Perl, and for that matter I know of an ALGOL-60 implementation which goes some way towards having them.

I ... don't think you're understanding the concept.

The idea is something similar to how a Page Fault is handled. The program tries to access a page that is not in memory at the moment -- maybe doesn't even exist anywhere right now. You don't abort the program. Instead you allocate a new memory page and zero it, or load the existing one from disk into RAM. Then you resume the program at the same instruction that had the problem. The program never knows anything happened (unless it compares a high resolution timer just before and after)

Recoverable exceptions is extending that (hardware assisted) idea to exceptions thrown in a program. For example your program might be writing to a disk file when the disk fills up. An exception is thrown. The handler sees that there is a bunch of stuff in /tmp and deletes it (or compresses some log files or something). The handler returns to the point of the throw and the write to the file succeeds, without the user's program being aware that anything ever happened, or having to be coded specially in any way.

[MarkMLl]

I ... don't think you're understanding the concept.

Recoverable exceptions is extending that (hardware assisted) idea to exceptions thrown in a program. For example your program might be writing to a disk file when the disk fills up. An exception is thrown. The handler sees that there is a bunch of stuff in /tmp and deletes it (or compresses some log files or something). The handler returns to the point of the throw and the write to the file succeeds, without the user's program being aware that anything ever happened, or having to be coded specially in any way.

I understand the concept perfectly well. In what way does OP not do what you're describing?

MarkMLl

[MarkMLl]

*The* algorithm was invented by Edsger Dijkstra and named the "shunting yard" algorithm because its operation resembles that of a railroad shunting yard.

Or more to the point Grau and Waychoff. Waychoff is rarely credited since his corporate situation prevented publication, but as far as I know it was he who first used ALGOL to implement ALGOL in such a way that recursive functions in the compiler mirrored recursive definitions in the language.

MarkMLl

[brucehoult]

I ... don't think you're understanding the concept.

Recoverable exceptions is extending that (hardware assisted) idea to exceptions thrown in a program. For example your program might be writing to a disk file when the disk fills up. An exception is thrown. The handler sees that there is a bunch of stuff in /tmp and deletes it (or compresses some log files or something). The handler returns to the point of the throw and the write to the file succeeds, without the user's program being aware that anything ever happened, or having to be coded specially in any way.

I understand the concept perfectly well. In what way does OP not do what you're describing?

The facilities in Object Pascal, languages which support eval() such a Perl (Python, Javascript), and others such as C++, Java, C# ABSOLUTELY DO NOT do or support what I am describing.

Common Lisp and Dylan do.