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

[DiTBho]

Talking about procedural languages, I usually write programs in C89/99.

For Xmas, a friend of mine sent me an old yellowish big book with more than 700 pages entirely typeset using "troff" on the Unix operating system (WOW, seriously WOW!!!), it was printed in 1977 and it uses examples from programming languages such as FORTRAN (10%), Algol (10%), PL/I (80%), programming language.

Never heard before, according to Google, PL/I is a very ancient language, older than C

PL/I: 1964->concept, 1969->implementation, by IBM
K&R C: 1972, concept,implementation, by Dennis Ritchie

Will I understand them? How much PL/I is different from K&R C? 

[SiliconWizard]

I suppose you have taken a look at this? https://en.wikipedia.org/wiki/PL/I

It sure is very different. But still procedural.
As to whether you'll understand code at first sight? You'll tell us.

[retiredfeline]

You can probably figure it out, once you get past the prolixity, the uppercase, and the fact that there are no reserved words. Why would you want to though, you can get algorithm examples in more recent languages.

I think I last wrote a PL/1 program for a Univac 1108, just out of curiosity. I don't think anybody else used it, everybody used FORTRAN on that mainframe. I think I was interested in being able to write recursive functions.

However troff is still very much alive, as groff and still used for man pages.

[IanB]

I played with PL/I a bit when I was at university (when it was still a "living" language). This was on a Multics system, which was kind of built around PL/I. Multics inspired Unix. You could say that PL/I is to Multics as C is to Unix.

It is just a procedural language, like C, or Algol, or Pascal, or anything similar. Nothing really oddball about it.

It's claim to fame was its attempt to solve all programming problems, from mathematics to accounting. As such, it tried to combine the capabilities of Algol, Fortran and Cobol in one environment, and therefore to be the last ever programming language that anyone would need. (RIP, PL/I  )

But yes, you should understand the examples in the book quite easily.

[DiTBho]

Why would you want to though, you can get algorithm examples in more recent languages

yeah, just for the challenge, and just because the book is a gift 
(also, because despite being old, the book is a kind of saint gold bible
modern version of that books exist, but cost a fortune (>>180 euro))

troff is still very much alive, as groff and still used for man pages.

Yup 

[DiTBho]

It is just a procedural language, like C, or Algol, or Pascal, or anything similar. Nothing really oddball about it.

oh, that's great! Years ago I wrote a lot of programs in Turbo-Pascal before switching to C.
I moved from Pascal@DOS(1989-1998) to C@BeOS(1999-2005), then to C@Linux (2006...)

If it's like riding a bicycle, I should still remember something (I hope)

But yes, you should understand the examples in the book quite easily.

Great! 

[SiliconWizard]

Pascal is still alive. You can try freepascal if you want to get back to it. It's modern and has added a lot to the Pascal you have likely used at the time.

[Cerebus]

UPPERCASE? Not for a long time. Prolix? Not really; more so than C (just a bit), much less so than COBOL.

Judge for yourself. This is the only bit of PL/1 that I have lying around. It's systems code  (a bootloader of sorts) for a Multics machine (36 bit word, 9 bit character, mainframe) and part of the Multics operating system - a spiritual predecessor to Unix as some of the Unix guys were working on Multics (project MAC) in the period just before they satrted in on Unix. C was influenced by PL/1 about as much as it was by Algol and BCPL. In this chunk of code you'll find some of those influences - pointers, pointer based variables and structures.

The only thing that I think needs any explanation is that

    dcl some_variable fixed bin (17);

is declaring a variable 17 bits wide, it's not an array which would probably be the assumption of someone who's not seen PL/1 before. Arrays look like this:

    dcl some_array (10) fixed binary;

is a 10 element array of integers at the machine's native default length (36 bits in the case of the Multics machine). There are quite a few abbreviations available 'dcl' for declare', 'bin' for 'binary' and so on.

Code: [Select]

/*
 Copyright 2015-2016 by Charles Anthony

 All rights reserved.

 This software is made available under the terms of the
 ICU License -- ICU 1.8.1 and later.
 See the LICENSE file at the top-level directory of this distribution and
 at https://sourceforge.net/p/dps8m/code/ci/master/tree/LICENSE
 */

cload:
  procedure;

/*
    dcl ios_$attach  entry (char (*) aligned, char (*), char (*), char (*), bit (72) aligned);
    dcl com_err_ entry options (variable);


    dcl card_device  char (32) init ("rdrb");
    dcl card_dim char (32) init ("crz");
    dcl status bit (72) aligned;

    dcl 1 stat                 aligned based (addr (status)),
          2 word1              fixed bin (35),
          2 iocode             fixed bin (35);
*/
    dcl iox_$attach_ioname entry (char (*), ptr, char (*), fixed bin (35));
    dcl iox_$open entry (ptr, fixed bin, bit (1) aligned, fixed bin (35));
    dcl iox_$read_record entry (ptr, ptr, fixed bin (21), fixed bin (21),
             fixed bin (35));
    dcl iox_$close entry (ptr, fixed bin (35));
    dcl iox_$detach_iocb entry (ptr, fixed bin (35));
    dcl iox_$get_chars entry (ptr, ptr, fixed bin(21), fixed bin(21),
             fixed bin(35));

    dcl hcs_$append_branch entry (char(*), char(*), fixed bin(5),
            fixed bin(35));
    dcl hcs_$append_branchx entry (char(*), char(*), fixed bin(5),
            (3) fixed bin(6), char(*), fixed bin(1), fixed bin(1),
            fixed bin(24), fixed bin(35));
    dcl hcs_$make_seg entry (char(*), char(*), char(*), fixed bin(5),
            ptr, fixed bin(35));
    dcl hcs_$set_bc_seg entry (ptr, fixed bin(24), fixed bin(35));
    dcl hcs_$terminate_noname entry (ptr, fixed bin(35));

    dcl get_group_id_$tag_star returns (char (32) aligned);

    dcl get_wdir_ entry returns (character (168));

    dcl ioa_ entry options (variable);
    dcl com_err_ entry options (variable);
    dcl cu_$arg_ptr entry (fixed bin, ptr, fixed bin, fixed bin (35));
    dcl cu_$arg_count entry (fixed bin);
 
    dcl error_table_$end_of_info fixed binary (35) external;

    dcl iocbp ptr;
    dcl code fixed (35);
    dcl buffer char (4096);
    dcl p ptr;
    dcl segp ptr;
    dcl char_count fixed bin (21);
    dcl bc fixed bin (24);
    dcl this_read_bits fixed bin;
    dcl this_read_chars fixed bin (21);
    dcl path character (168);
    dcl bn fixed bin;
    dcl  argp ptr,
         argln fixed bin (17),
         arg char (argln) based (argp) unaligned,
         count fixed bin;

    dcl 1 h based aligned,
          2 type fixed binary,        /* 0 */
          2 bitcnt fixed binary,      /* 1 */
          2 dlen fixed binary,        /* 2 */
          2 dname character (168),    /* 3 */
          2 elen fixed binary,        /* 45 */
          2 ename character (32);     /* 46 */
                                      /* 54 */

    dcl 1 s based aligned,
          2 block (1:255) char (4096);

    dcl 1 minbuf based aligned,
          2 buf char (256);

    dcl  rings (3) fixed binary (6);

    call cu_$arg_count (count);
    if count ^= 1 then do;
      call ioa_ ("Usage cload tape_label");
      goto done;
    end;

    call cu_$arg_ptr (1, argp, argln, code);

    rings (1) = 4;
    rings (2) = 4;
    rings (3) = 4;

   
    call iox_$attach_ioname  ("tape_switch", iocbp, "tape_nstd_ " || arg, code);
    if code ^= 0 then do;
      call com_err_ (code, "cload", "attach_ioname");
      goto done;
    end;

    call iox_$open (iocbp, Sequential_input, "0"b, code);
    if code ^= 0 then do;
      call com_err_ (code, "cload", "open");
      goto done1;
    end;

    p = addr (buffer);

    /* skip the label and first mark */
    call iox_$read_record (iocbp, p, 4096, char_count, code);
    /*call ioa_ ("read label char_count ^d code ^d ^w", char_count, code, p -> h.type); */
    if code ^= 0 then
      call com_err_ (code, "cload", "read label");

    call iox_$read_record (iocbp, p, 4096, char_count, code);
    /*call ioa_ ("read label mark char_count ^d code ^d ^w", char_count, code, p -> h.type);*/
    if code ^= error_table_$end_of_info | char_count ^= 0 then
      call com_err_ (code, "cload", "read label mark");

/* Loop over segments */

loop:

    /* Read the header */
    call iox_$read_record (iocbp, p, 4096, char_count, code);
    /* call ioa_ ("read code ^d char_count ^d type ^w bitcnt ^w", code, char_count, p -> h.type, p -> h.bitcnt); */
    if code ^= 0 then do;
      call com_err_ (code, "cload", "read header");
      goto done2;
    end;


    if p -> h.type = 0 then do; /* dir */
       call ioa_ ("DIR: ^a>^a", p -> h.dname, p -> h.ename);
       if p -> h.dlen ^= 0 then
           path = rtrim (get_wdir_ ()) || ">" || substr (p -> h.dname, 1, p -> h.dlen);
       else
           path = rtrim (get_wdir_ ());
       /* call ioa_ ("^a", path); */
       call hcs_$append_branchx (path,
              substr (p -> h.ename, 1, p -> h.elen),
              1011b, /* sma */
              rings,
              (get_group_id_$tag_star ()), /* user_id */
              1b, /* dirsw */
              0b, /* copy_sw */
              0, /* bit_count */
              code);
      if code ^= 0 then do;
        call com_err_ (code, "cload", "append_branchx");
        goto done2;
      end;

    end;


    else if p -> h.type = 1 then do; /* seg */
       call ioa_ ("SEG: ^a>^a", p -> h.dname, p -> h.ename);

       call hcs_$make_seg (rtrim (get_wdir_ ()) || ">" || substr (p -> h.dname, 1, p -> h.dlen),
              substr (p -> h.ename, 1, p -> h.elen),
              "", /* ref_name */
              1110b, /* rew */
              segp,
              code);
       if code ^= 0 then do;
         call com_err_ (code, "cload", "make_seg");
         goto done2;
       end;

       bc = p -> h.bitcnt;
       call hcs_$set_bc_seg (segp, bc, code);
       if code ^= 0 then do;
         call com_err_ (code, "cload", "set_bc_seg");
         goto done2;
       end;

       bn = 0;
dloop:
       if (bc > 0) then do;
           /* Calculate the number of bits in the next block */
           this_read_bits = bc;
           if this_read_bits > 4096 * 9 then
               this_read_bits = 4096 * 9;
           this_read_chars = this_read_bits / 9;

           /* minium buffer size */
           if this_read_chars < 256 then
             this_read_chars = 256;
           
           bn = bn + 1;
           p = addr (segp -> s.block (bn));

           /* zero out the minimum buffer size to handle short reads */
           p -> minbuf.buf = char (0);

           /* Read a block of data */
           call iox_$read_record (iocbp, p, this_read_chars, char_count, code);
           if code ^= 0 then do;
             call com_err_ (code, "cload", "read data");
             goto done2;
           end;
           bc = bc - this_read_bits;
           goto dloop;
       end;

       call hcs_$terminate_noname (segp, code);
       if code ^= 0 then do;
           call com_err_ (code, "cload", "terminate data");
           goto done2;
       end;

    end;



    else if p -> h.type = 2 then do; /* end */
       call ioa_ ("END: ^a>^a", p -> h.dname, p -> h.ename);
       goto done2;
    end;


    else do;
       call ioa_ ("Bad value in h.type: ^d", p -> h.type);
       goto done2;
    end;

    /* read eod mark */
    p = addr (buffer);
    call iox_$read_record (iocbp, p, 4096, char_count, code);
    /* call ioa_ ("read eod mark char_count ^d code ^d ^w", char_count, code, p -> h.type); */
    if code ^= error_table_$end_of_info | char_count ^= 0 then do;
      call com_err_ (code, "cload", "read eod mark");
       goto done2;
    end;

    goto loop;

done2:
    call iox_$close (iocbp, code);
done1:
    call iox_$detach_iocb (iocbp, code);
done:
    return;

%include iox_modes;

  end;


[tggzzz]

Talking about procedural languages, I usually write programs in C89/99.
...
Will I understand them? How much PL/I is different from K&R C? 

If, after a small amount of reading, can't understand another contempory procedural language, then you probably aren't competent to use C.

As someone that has been using C since 1982 and has never used PL/1, I would learn PL/1 faster than I would learn all the "gotchas" in C.

[SiliconWizard]

If, after a small amount of reading, can't understand another contempory procedural language, then you probably aren't competent to use C.

Well... yes, but I'd temper this a bit. I guess it would all depend on what you mean by "understand". And by "contemporary", I suppose you mean,as  in the same period as original C? Or did you mean as in "recent"?

In both cases, a few languages, either from the 60s/70s or recent, are pretty quirky. And not immediately figuring them out is no sign that you aren't competent to use C. Just a thought...

[tggzzz]

If, after a small amount of reading, can't understand another contempory procedural language, then you probably aren't competent to use C.

Well... yes, but I'd temper this a bit. I guess it would all depend on what you mean by "understand". And by "contemporary", I suppose you mean,as  in the same period as original C? Or did you mean as in "recent"?

In both cases, a few languages, either from the 60s/70s or recent, are pretty quirky. And not immediately figuring them out is no sign that you aren't competent to use C. Just a thought...

I was thinking of both originating 50+ years ago, when there were very few alternative programming paradigms except procedural.

I will stand by my statement that back then there was relatively little difference between mainstream procedural languages. Certainly not as much as between future paradigms such as first order predicate logic, relational database, object oriented, discrete event simulation, statistics, FSM, etc languages.

[SiliconWizard]

If, after a small amount of reading, can't understand another contempory procedural language, then you probably aren't competent to use C.

Well... yes, but I'd temper this a bit. I guess it would all depend on what you mean by "understand". And by "contemporary", I suppose you mean,as  in the same period as original C? Or did you mean as in "recent"?

In both cases, a few languages, either from the 60s/70s or recent, are pretty quirky. And not immediately figuring them out is no sign that you aren't competent to use C. Just a thought...

I was thinking of both originating 50+ years ago, when there were very few alternative programming paradigms except procedural.

I will stand by my statement that back then there was relatively little difference between mainstream procedural languages. Certainly not as much as between future paradigms such as first order predicate logic, relational database, object oriented, discrete event simulation, statistics, FSM, etc languages.

Generalizing a bit yes, but I can think of at least a couple languages that would certainly be pretty far from C, and even probably looking like garbage if you don't know anything about them.

First: Forth. Yes, it's actually classified as a procedural language.

Then there would be Smalltalk. I'm not completely sure it qualifies as a "procedural language", although it's a bit hard to tell. I'll leave it to your appreciation.

Now of course, if we consider more recent languages, there are quite a few that are a bit hard to decipher, even though they are still procedural, although most of those would, admittedly, not be widely popular.

[tggzzz]

If, after a small amount of reading, can't understand another contempory procedural language, then you probably aren't competent to use C.

Well... yes, but I'd temper this a bit. I guess it would all depend on what you mean by "understand". And by "contemporary", I suppose you mean,as  in the same period as original C? Or did you mean as in "recent"?

In both cases, a few languages, either from the 60s/70s or recent, are pretty quirky. And not immediately figuring them out is no sign that you aren't competent to use C. Just a thought...

I was thinking of both originating 50+ years ago, when there were very few alternative programming paradigms except procedural.

I will stand by my statement that back then there was relatively little difference between mainstream procedural languages. Certainly not as much as between future paradigms such as first order predicate logic, relational database, object oriented, discrete event simulation, statistics, FSM, etc languages.

Generalizing a bit yes, but I can think of at least a couple languages that would certainly be pretty far from C, and even probably looking like garbage if you don't know anything about them.

Instant thoughts are APL, Snobol and Teco

First: Forth. Yes, it's actually classified as a procedural language.

Then there would be Smalltalk. I'm not completely sure it qualifies as a "procedural language", although it's a bit hard to tell. I'll leave it to your appreciation.

Now of course, if we consider more recent languages, there are quite a few that are a bit hard to decipher, even though they are still procedural, although most of those would, admittedly, not be widely popular.

Smalltalk-80 definitely isn't procedural; it is object oriented with a vengence! The earlier Smalltalks are more ambiguous but were internal research languages. The only earlier OOP language I'm aware of is Simula.

Forth definitely is procedural.

[DiTBho]

Yesterday I spent the whole day reading half of the first chapter of the book. The examples written in PL/1 are not difficult to follow, but for me they are less clear than if they were written in C, but if I reread them five times then they appear somewhat clear enough.

I hope with time to train enough so that other chapters will take less time to read and understand 

[nfmax]

If, after a small amount of reading, can't understand another contempory procedural language, then you probably aren't competent to use C.

Well... yes, but I'd temper this a bit. I guess it would all depend on what you mean by "understand". And by "contemporary", I suppose you mean,as  in the same period as original C? Or did you mean as in "recent"?

In both cases, a few languages, either from the 60s/70s or recent, are pretty quirky. And not immediately figuring them out is no sign that you aren't competent to use C. Just a thought...

I was thinking of both originating 50+ years ago, when there were very few alternative programming paradigms except procedural.

I will stand by my statement that back then there was relatively little difference between mainstream procedural languages. Certainly not as much as between future paradigms such as first order predicate logic, relational database, object oriented, discrete event simulation, statistics, FSM, etc languages.

Generalizing a bit yes, but I can think of at least a couple languages that would certainly be pretty far from C, and even probably looking like garbage if you don't know anything about them.

Instant thoughts are APL, Snobol and Teco

First: Forth. Yes, it's actually classified as a procedural language.

Then there would be Smalltalk. I'm not completely sure it qualifies as a "procedural language", although it's a bit hard to tell. I'll leave it to your appreciation.

Now of course, if we consider more recent languages, there are quite a few that are a bit hard to decipher, even though they are still procedural, although most of those would, admittedly, not be widely popular.

Smalltalk-80 definitely isn't procedural; it is object oriented with a vengence! The earlier Smalltalks are more ambiguous but were internal research languages. The only earlier OOP language I'm aware of is Simula.

Forth definitely is procedural.

50 years ago is (almost) 1972. Which lets Prolog scrape in, just. Back in the day, there was a horribly believable urban myth that Word for Windows was actually written in Prolog...

[brucehoult]

In my first job after university (Jan 1985) I worked as a programmer at a financial company that had a DG MV/10000 supermini (claimed about twice faster than a VAX 11/780). They were running stockbroking accounting software from a vendor and didn't have any programming language on the machine.

My first job was to decide what programming language they would buy from DG. The choices were COBOL, FORTRAN, and PL/I. I spent a week in the DG office trying them all, and combining them with the DG/SQL database. I'd used COBOL and FORTRAN before but never seen PL/I. Nevertheless the clear winner was PL/I. If you squinted at it right you could pretty much pretend it was some frankenstein mix of Pascal and C, with COBOL record structures thrown in for good measure. It had arrays and strings (including *bit* strings) and pointers and a heap and a full set of control constructs and supported recursion and nested functions / limited closures.

[tggzzz]

Back in the day, there was a horribly believable urban myth that Word for Windows was actually written evolved in Prolog...

FTFY

[MarkMLl]

Back in the day, there was a horribly believable urban myth that Word for Windows was actually written in Prolog...

Windows (circa NT) certainly used to contain a lump of Prolog, which handled network configuration. The rules were buried in a DLL, if one knew where to look.

Going back to OP's question. PL/I is a derivative of ALGOL-60, as are the Pascal family (Pascal, Ada, Modula-2 etc.) and the BCPL family (BCPL, C, C++, Perl, Python etc.). Non-derivative languages include APL, Forth, Lisp, Smalltalk, Prolog and arguably Rust.

I still use a modern Pascal implementation on occasion, but consider myself "adequately read" as far as language history and philosophy are concerned. That leaves me with very little patience for the mutual hostility of the Pascal and C communities.

Judging by what I see in the Free Pascal (compiler/libraries) and Lazarus (IDE) forums, newcomers to the Pascal family of languages have a bit of trouble with the language structure (syntax) and runtime behaviour (semantics) but more than anything else they object to the lack of braces as block enclosures. They object somewhat less to Pascal's relative verbosity than they used to, since modern C has largely adopted Pascal's strict type checking etc.

On unix-based systems there is this as a fortune cookie:

Code: [Select]

Speaking as someone who has delved into the intricacies of PL/I, I am
sure that only Real Men could have written such a machine-hogging,
cycle-grabbing, all-encompassing monster.  Allocate an array and free
the middle third?  Sure!  Why not?  Multiply a character string times a
bit string and assign the result to a float decimal?  Go ahead!  Free a
controlled variable procedure parameter and reallocate it before
passing it back?  Overlay three different types of variable on the same
memory location?  Anything you say!  Write a recursive macro?  Well,
no, but Real Men use rescan.  How could a language so obviously
designed and written by Real Men not be intended for Real Man use?

I think that a C user will find PL/I somewhat alien, but would suggest that the learning experience will be very much worthwhile.

MarkMLl

[DiTBho]

I think that a C user will find PL/I somewhat alien, but would suggest that the learning experience will be very much worthwhile.

yup, I program in C somehow OOP-like and a strongly typed way, so ... from this point of view I do find PL/I alien, but not too much after a while

[MarkMLl]

This is Peter Norton writing in 1984:

The traditional FORTRAN school contributed not only handy calculation-by-formula but also automatic calculation with whole arrays of data, one of the main virtues of the language APL. The COBOL camp contributed very powerful I/0 formatting, particularly through an option called PICTURE; formatting using the PICTURE option allows such nice things as floating dollar signs and commas in numbers (BASIC programmers have a crude form of this feature in the PRINT USING statement). The ALGOL language (which isn't widely known these days) contributed such features as a free format for program layout, and block structuring, which helps us make sure that one part of a program doesn't interfere with another. Anyone who is familiar with Pascal and C is accustomed to these virtues; they were not only uncommon when PL/I was created, but PL/I's versions of these features are probably better than those of any language created since. The final element, which I called new topics, consisted of several abilities that had not existed before in major programming languages. These included support of interrupts (similar to BASIC's ON KEY and ON ERROR statements), use of macros and program libraries, and other goodies of that ilk.

Some ALGOL-60 implementations (e.g. Burroughs) did actually have decent I/O formatting, a measure of exception handling and so on. Hoare, co-chairman of the PL/I standardisation committee, famously described ALGOL-60 as being a better language than any of its predecessors and most of its successors... but there were "gaps" in its specification necessitated by the relative immaturity of the computer industry in those days.

However, the important thing to appreciate about just about every language up until the late '70s or perhaps early '80s is that the facilities it provided were locked down by its implementors: the form of (for example) the filehandling functions was defined in the compiler and couldn't be easily changed by linking in a new library. And for that matter, there were few if any languages where the underlying syntax could be changed until the 2010s: while e.g. C++ allows operators to be overloaded it's not generally possible to add a novel operator or define a novel flow control syntax on whim.

Which, I'd suggest, provides a backdrop for considering an older language such as PL/I: irrespective of how "cutting edge" it was considered to be at the time.

MarkMLl

[rstofer]

In grad school, I undertook writing an 8080 Assembler in PL/I.  This was in 1976 and assemblers weren't laying all over the place for students and hobbyists.

My adviser said my code looked a lot like FORTRAN and he was right.  It was possible to write FORTRAN in PL/I!

The project was my first exposure to a higher level language and I wish I had taken the time to get proficient.  The problem was, the only computer on campus with a PL/I compiler was a tiny IBM 360/40 that the school used for business.  Getting access was problematic.

Still, I like the language and I could have done so much better.  It was a great lead-in to UCSD Pascal in '80.

Since the OP linked to a Pascal interpreter written in Python (and I NEED to learn Python), I think I'll follow along and see how it works out.

[Cerebus]

Generalizing a bit yes, but I can think of at least a couple languages that would certainly be pretty far from C, and even probably looking like garbage if you don't know anything about them.

I can think of some that look like garbage even if you do know them. APL and Lisp, I'm looking at you both.

...
Then there would be Smalltalk. I'm not completely sure it qualifies as a "procedural language", although it's a bit hard to tell. I'll leave it to your appreciation.

Smalltalk is definitely a procedural language. Versions were Smalltalk-80 and Smalltalk-74, both a bit outside the '50 year old' criteria.

[Cerebus]

Smalltalk-80 definitely isn't procedural; it is object oriented with a vengence!

That doesn't make it non-procedural. Procedures being named methods, and procedure calls being named 'sending messages' doesn't stop them from being procedures.

[MarkMLl]

I can think of some that look like garbage even if you do know them. APL and Lisp, I'm looking at you both.

People think that the weirdest thing about APL is the character set. It's not: the right-to-left evaluation order is far weirder... even if Iverson had a good reason for doing it that way,

Smalltalk is definitely a procedural language. Versions were Smalltalk-80 and Smalltalk-74, both a bit outside the '50 year old' criteria.

I agree. And something that almost everybody overlooks is that it was defined with a substantial number of "big project" features including enforced naming conventions and internal documentation. But Kay was an extremely clued-up guy, with experience that eclipsed the authors of APL, Lisp and the rest.

MarkMLl

[tggzzz]

Generalizing a bit yes, but I can think of at least a couple languages that would certainly be pretty far from C, and even probably looking like garbage if you don't know anything about them.

I can think of some that look like garbage even if you do know them. APL and Lisp, I'm looking at you both.

...
Then there would be Smalltalk. I'm not completely sure it qualifies as a "procedural language", although it's a bit hard to tell. I'll leave it to your appreciation.

Smalltalk is definitely a procedural language. Versions were Smalltalk-80 and Smalltalk-74, both a bit outside the '50 year old' criteria.

... only in the sense that you can write Fortran in any language.

The key differentiating point is that the "procedure" is "contained in" the data upon which the method is invoked. That's an inversion of standard procedural semantics.

Which method is executed cannot be known at compile time. It is associated with the "receiving" object and can only be known at runtime via a dynamic lookup. Hence the Smalltalk equivalent of a null pointer exception: Object doesNotUnderstand. (Of course in Smalltalk that can be intercepted and used for some powerful purposes, e.g. proxy objects that forward messages to the "real" recipient.)

It takes real perversity to use Smalltalk procedurally - basically you need a single instance of a single class, with all methods hung off that object.