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.

[tggzzz]

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,

Yup. Most people are surprised by the results of 7, 7 - 7, 7 - 7 - 7, 7 - 7 - 7 -7, ...

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.

Yes he was, but I've never liked the lack of namespaces in Smalltalk. Your project's concept of "Tank" is unlikely to be my project's concept

[IanB]

Yes he was, but I've never liked the lack of namespaces in Smalltalk. Your project's concept of "Tank" is unlikely to be my project's concept

That was surely an opportunity for "Bigtalk" 

[SiliconWizard]

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.

So, that's what I thought too. But I knew this would be an interesting example nevertheless.

[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.

... 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.

No, the procedure is not contained in the data, it is [indirectly] contained in the method dictionary of the class that a particular object belongs to. Standard procedural semantics is that one has types and has procedural operations on those types, Smalltalk just makes it easier to extend those types and their operators. It is still all done procedurally, there is no inference, there is no functional composition.

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.

Procedural programming languages are ones in which one writes procedures: "Do this, if that, then do this" and so on. This is what one does in Smalltalk. Run time binding does not make "anObject add: anotherObject" un-procedural, it just means that the programmer doesn't have to manage the bookkeeping as to which particular procedure gets invoked to deal with what type "anObject" is at the moment. Contrast with functional programming languages. If you still want to insist that Smalltalk is not procedural, please provide an example in Smalltalk that does not "follow a procedure" to get the result that one is looking for.

[Cerebus]

Yes he was, but I've never liked the lack of namespaces in Smalltalk. Your project's concept of "Tank" is unlikely to be my project's concept

There are namespaces in Smalltalk-80 but they are not exposed in the language, they are part of the interactive programming environment. They are also implied by superclass membership. "Tank" that is a subclass of "FluidContainer" is not the same [class] object as "Tank" that is a subclass of "Weapon".

My personal disliked feature of Smalltalk is that it doesn't really have a form outside of the interactive programming environment - there is no defined denotation for "here is a class definition  for 'Child' that is a subclass of 'Parent'". One or two implementations have defined methods that kind of let you write this out as a standalone program or algorithm, but none of them was quite there. It's very difficult to use Smalltalk to describe your algorithms in a paper in the way that Algol used to be used for that purpose. Similarly it's difficult to zip up an application in Smalltalk and pass it to someone else to install in the way one can the same in C, C++, python, whatever. Solving that problem properly does indeed require the formal introduction of some form of namespaces.

[MarkMLl]

That was surely an opportunity for "Bigtalk" 

At this point, can I bang a drum please for Timothy Budd who's published- among many other things- teaching implementations of both Smalltalk and APL. https://web.archive.org/web/20210304111757/http://web.engr.oregonstate.edu/~budd/Books/index.html

I particularly like his Leda book, which has some thought-provoking examples in the freely-available chapters.

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.

No, the procedure is not contained in the data, it is [indirectly] contained in the method dictionary of the class that a particular object belongs to.

Semantically they are "contained in" each object. (Note the quotes!) The implementation technique you mention merely saves some memory space.

Standard procedural semantics is that one has types and has procedural operations on those types, Smalltalk just makes it easier to extend those types and their operators. It is still all done procedurally, there is no inference, there is no functional composition.

You appear to be confusing/conflating functional programming with object oriented programming. Either, of course, can be used to implement the other.

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.

Procedural programming languages are ones in which one writes procedures: "Do this, if that, then do this" and so on. This is what one does in Smalltalk. Run time binding does not make "anObject add: anotherObject" un-procedural, it just means that the programmer doesn't have to manage the bookkeeping as to which particular procedure gets invoked to deal with what type "anObject" is at the moment. Contrast with functional programming languages. If you still want to insist that Smalltalk is not procedural, please provide an example in Smalltalk that does not "follow a procedure" to get the result that one is looking for.

Correct, but that misses the point of OOP. In OOP the object/data defines the operations/procedures that can be performed on it.

In procedural programming the procedure's signature defines the type of data on which it can operate.

[tggzzz]

Yes he was, but I've never liked the lack of namespaces in Smalltalk. Your project's concept of "Tank" is unlikely to be my project's concept

There are namespaces in Smalltalk-80 but they are not exposed in the language, they are part of the interactive programming environment. They are also implied by superclass membership. "Tank" that is a subclass of "FluidContainer" is not the same [class] object as "Tank" that is a subclass of "Weapon".

I wondered if someone would raise that canard. What if I replaced "Tank" with "Person"? What should be its superclass? IMNSHO, a fluid containing Tank should have an instance variable of type Cuboid, whereas a vehicular Tank could reasonably be a subclass of Vehicle with instance variable "Bore".
 
OOP neophytes tend to overuse inheritance where composition is preferable. I have even seen a project where Currency was defined as a subclass of Integer, whereas it would have been better defined as a subclass of Object with an instance variable of type Integer.

My personal disliked feature of Smalltalk is that it doesn't really have a form outside of the interactive programming environment - there is no defined denotation for "here is a class definition  for 'Child' that is a subclass of 'Parent'". One or two implementations have defined methods that kind of let you write this out as a standalone program or algorithm, but none of them was quite there. It's very difficult to use Smalltalk to describe your algorithms in a paper in the way that Algol used to be used for that purpose. Similarly it's difficult to zip up an application in Smalltalk and pass it to someone else to install in the way one can the same in C, C++, python, whatever. Solving that problem properly does indeed require the formal introduction of some form of namespaces.

With that we are in violent agreement.

There are techniques which work (e.g. ChangeSets and others im VisualAge), but they feel brittle and unclean.

[Cerebus]

You appear to be confusing/conflating functional programming with object oriented programming. Either, of course, can be used to implement the other.

No, I'm not. I'm contrasting procedural programming languages with other programming language types such as functional, inferential etc. OOP is just another procedural language structuring device, it doesn't remove the procedural nature of OOP.

procedure | prəˈsiːdʒə |
noun
...
• a series of actions conducted in a certain order or manner

Correct, but that misses the point of OOP. In OOP the object/data defines the operations/procedures that can be performed on it.

If they "defines the operations/procedures" how are they not procedural if you've just chosen the term "procedure" to describe them.

In procedural programming the procedure's signature defines the type of data on which it can operate.

No, that's not one means by procedural programming, in procedural programming one writes procedures, one doesn't leave the programming language to decide for itself how to solve the problem as one does in functional languages, inferential languages and so on.

You're using your own definition of procedural programming apparently to mean "contains something called a procedure". If there's conflation going on here it's you conflating the  'procedure' in procedural language and the 'procedure' as one of the many names for a packaged sequence of program steps also known as a routine, subroutine or function'.

[SiliconWizard]

That's fun. =)

OOP can actually be more or less implemented on top of various paradigms. It's not really a paradigm in itself. Well, not so much anyway.
OCaml, for instance, is OO but also essentially functional. I think Scala as well.

And yes, the most common implementations of OOP are usually procedural - they tie data structures to methods, which are nothing but procedures.

Smalltalk is a bit of a weird animal, but I would also have considered it procedural. Now I admit I am not a Smalltalk expert.

But interestingly enough, OOP is frequently depicted (in many definitions even) as a paradigm in itself, on the same "level" as procedural, or functional. Which I don't quite agree with either. But if you stick to those commonly seen definitions, you'll naturally be inclined to claim they are different.

[tggzzz]

You appear to be confusing/conflating functional programming with object oriented programming. Either, of course, can be used to implement the other.

No, I'm not. I'm contrasting procedural programming languages with other programming language types such as functional, inferential etc. OOP is just another procedural language structuring device, it doesn't remove the procedural nature of OOP.

procedure | prəˈsiːdʒə |
noun
...
• a series of actions conducted in a certain order or manner

Correct, but that misses the point of OOP. In OOP the object/data defines the operations/procedures that can be performed on it.

If they "defines the operations/procedures" how are they not procedural if you've just chosen the term "procedure" to describe them.

In procedural programming the procedure's signature defines the type of data on which it can operate.

No, that's not one means by procedural programming, in procedural programming one writes procedures, one doesn't leave the programming language to decide for itself how to solve the problem as one does in functional languages, inferential languages and so on.

You're using your own definition of procedural programming apparently to mean "contains something called a procedure". If there's conflation going on here it's you conflating the  'procedure' in procedural language and the 'procedure' as one of the many names for a packaged sequence of program steps also known as a routine, subroutine or function'.

I suggest you read, learn and inwardly digest the entirety of https://en.wikipedia.org/wiki/Object-oriented_programming

In procedural programming the procedures specify the types of data on which they can operate.
In object oriented programming the data specifies the procedures that can operate on it.

I hope you can see the essential difference there. Data-centric vs operation-centric.

[Cerebus]

Yes he was, but I've never liked the lack of namespaces in Smalltalk. Your project's concept of "Tank" is unlikely to be my project's concept

There are namespaces in Smalltalk-80 but they are not exposed in the language, they are part of the interactive programming environment. They are also implied by superclass membership. "Tank" that is a subclass of "FluidContainer" is not the same [class] object as "Tank" that is a subclass of "Weapon".

I wondered if someone would raise that canard. What if I replaced "Tank" with "Person"? What should be its superclass? IMNSHO, a fluid containing Tank should have an instance variable of type Cuboid, whereas a vehicular Tank could reasonably be a subclass of Vehicle with instance variable "Bore".

You're confusing me describing (using a crude exemplar) how the actual Smalltalk-80 environment worked with me advocating some concrete example of how I think it ought to be done.

As far as Tanks go, many fluid containing ones are not composed of cuboids, such as a tank of acetylene gas. Making that mistake could end your life, explosively. However, they all do have the behaviour of containing fluids.

OOP neophytes tend to overuse inheritance where composition is preferable. I have even seen a project where Currency was defined as a subclass of Integer, whereas it would have been better defined as a subclass of Object with an instance variable of type Integer.

One who knows the Smalltalk class hierarchy well probably would start with a subclass of Magnitude, likely Fraction and extend it with an instance variable for scale as a starting point and override behaviour such that the scaling was handled transparently. Where there is shared behaviour with a superclass one should subclass to gain the benefit of inheriting all that preprogrammed behaviour*, starting at Object and inheriting almost bugger all behaviour and no arithmetic operations (not even add:) wouldn't be very helpful for a currency class where comparison, ordering operators and arithmetic might prove to be rather useful. 

*Truthfully, there's not much in Magnitude, just < <= > >= and between:and: but it's a logical place to start.

[tggzzz]

OOP neophytes tend to overuse inheritance where composition is preferable. I have even seen a project where Currency was defined as a subclass of Integer, whereas it would have been better defined as a subclass of Object with an instance variable of type Integer.

One who knows the Smalltalk class hierarchy well probably would start with a subclass of Magnitude, likely Fraction and extend it with an instance variable for scale as a starting point and override behaviour such that the scaling was handled transparently. Where there is shared behaviour with a superclass one should subclass to gain the benefit of inheriting all that preprogrammed behaviour*, starting at Object and inheriting almost bugger all behaviour and no arithmetic operations (not even add:) wouldn't be very helpful for a currency class where comparison, ordering operators and arithmetic might prove to be rather useful. 

*Truthfully, there's not much in Magnitude, just < <= > >= and between:and: but it's a logical place to start.

No, you wouldn't.

You would define a Class Currency (superclass Object) that "has-a" (==instance variable) value which is an Integer (etc). Relevant arithmetic operations would then be delegated to the value. Irrelevant operations would not appear in the Currency's signature.

Delegation is a key OOP concept, one that is very powerful.

"Your" inheritance technique would allow all sorts of irrelevant operations on Currency, e.g. taking the cosine of it! Preventing that would break the vitally important Liskov Substitution Principle.

[Cerebus]

I suggest you read, learn and inwardly digest the entirety of https://en.wikipedia.org/wiki/Object-oriented_programming

Don't be so bloody condescending. I have a full set of the Smalltalk books; in 1985 I wrote a Smalltalk implementation from the  'Blue Book' because at the time I had no access to hardware that would run any of the existing implementations. So, I may know just a little bit about OOP. Just because I don't agree with your definition of what constitutes a procedural programming language doesn't mean I need to be directed at Wikipedia.

In procedural programming the procedures specify the types of data on which they can operate.
In object oriented programming the data specifies the procedures that can operate on it.

I hope you can see the essential difference there. Data-centric vs operation-centric.

I've used the original X-Windows Athena Widgets. The Athena widgets were most definitely OOP, each data type had a set of procedures that implemented the operation for that type and only for that type and they even used inheritance. Yet weirdly they were all written in C, a procedural programming language, even by your definition. OOP is a structuring device for procedural programming, OOP languages make that easier but that's all, they are still procedural in nature. OOP is simply a more restrictive subset of procedural programming (restrictive in this case only implying that they restrict how a programmer may structure their code).

OOP neophytes tend to overuse inheritance where composition is preferable. I have even seen a project where Currency was defined as a subclass of Integer, whereas it would have been better defined as a subclass of Object with an instance variable of type Integer.

One who knows the Smalltalk class hierarchy well probably would start with a subclass of Magnitude, likely Fraction and extend it with an instance variable for scale as a starting point and override behaviour such that the scaling was handled transparently. Where there is shared behaviour with a superclass one should subclass to gain the benefit of inheriting all that preprogrammed behaviour*, starting at Object and inheriting almost bugger all behaviour and no arithmetic operations (not even add:) wouldn't be very helpful for a currency class where comparison, ordering operators and arithmetic might prove to be rather useful. 

*Truthfully, there's not much in Magnitude, just < <= > >= and between:and: but it's a logical place to start.

No, you wouldn't.

You would define a Class Currency (superclass Object) that "has-a" (==instance variable) value which is an Integer (etc). Relevant arithmetic operations would then be delegated to the value. Irrelevant operations would not appear in the Currency's signature.

Delegation is a key OOP concept, one that is very powerful.

"Your" inheritance technique would allow all sorts of irrelevant operations on Currency, e.g. taking the cosine of it! Preventing that would break the vitally important Liskov Substitution Principle.

Nolo contendere. I'm pretty sure at this point that you're just arguing with "my way or the highway" logic and I'm too old for that kind of argument and you're way too old for it.

[brucehoult]

I suggest you read, learn and inwardly digest the entirety of https://en.wikipedia.org/wiki/Object-oriented_programming

In procedural programming the procedures specify the types of data on which they can operate.
In object oriented programming the data specifies the procedures that can operate on it.

I hope you can see the essential difference there. Data-centric vs operation-centric.

Wikipedia is not necessarily the last word in definitive knowledge.

"Procedural programming", to me and others here, means explicitly specifying the steps to be followed and in what order. Normal object-oriented programming languages such as Smalltalk and C++ and Java are a subset of procedural programming, not something different. Languages such as Lisp and Scheme are a different subset of procedural programming.

Prolog, SNOBOL, Haskell are examples of non-procedural languages.

[Cerebus]

That's fun. =)

OOP can actually be more or less implemented on top of various paradigms. It's not really a paradigm in itself. Well, not so much anyway.
OCaml, for instance, is OO but also essentially functional. I think Scala as well.

And yes, the most common implementations of OOP are usually procedural - they tie data structures to methods, which are nothing but procedures.

Smalltalk is a bit of a weird animal, but I would also have considered it procedural. Now I admit I am not a Smalltalk expert.

But interestingly enough, OOP is frequently depicted (in many definitions even) as a paradigm in itself, on the same "level" as procedural, or functional. Which I don't quite agree with either. But if you stick to those commonly seen definitions, you'll naturally be inclined to claim they are different.

I dunno, I think that paradigm is exactly the word to describe OO but it's a word that has been tortured in recent years, especially by computer people, doubly so by computer marketing people.

If you use paradigm to mean 'a way of thinking/reasoning about something' then it is, if you use the classic meaning of 'the finest example of a thing, suitable to be emulated' then it's not.

I've briefly mentioned the Athena Widget set. That was fully OO thinking built entirely out of C. It was clear that the designers had seen the Smalltalk MVC environment, or something like it, and gone "this is the way to implement a graphic user interface" and then gone on to do the best they could with the tools they had, and that they could expect other people who wanted to run X-Windows to have - so very plain C. I'd be quite comfortable saying that "The Athena Widget set was designed in an Object Oriented paradigm", or at least I would if the word paradigm hadn't become so problematic.

[MarkMLl]

This is all departing a long way from OP's question, and by now is probably telling him nothing he doesn't know.

In procedural programming the procedures specify the types of data on which they can operate.
In object oriented programming the data specifies the procedures that can operate on it.

I am extremely uncomfortable with that as a definition, and suggest that you're confusing the concepts of "named procedure with predefined parameter types" and "procedure comprising a specific series of operations".

As others have pointed out, Smalltalk's methods are basically procedures, even if the parameters are specified unconventionally (by comparison with contemporary mainstream languages). And most if not all conventional languages with OO pretensions have an implicit parameter referring to the object being manipulated. There really is no distinct dividing line.

On the other hand are things like Prolog, and SQL queries. But even in those cases there are usually facilities for embedding specific procedural sequences.

I was once discussing Prolog and Japan's "5th Generation" project, and pointed out that the implementers had to tack on a substantial amount (the details are largely lost) of procedural capability to make it usable for systems programming. However somebody made the thought-provoking comment that it would probably be possible to handle e.g. an interrupt with adequately detailed Prolog-style rules: "We've got an interrupt, change the state of the system so that there is no longer an interrupting condition".

But in any event, the distinctions between the various paradigms (procedural, OO, functional, inferential and so on) is extremely vague, and I'd suggest that more than anything else they're the result of turf wars in academic research and laziness in academic teaching.

MarkMLl

[tggzzz]

I suggest you read, learn and inwardly digest the entirety of https://en.wikipedia.org/wiki/Object-oriented_programming

In procedural programming the procedures specify the types of data on which they can operate.
In object oriented programming the data specifies the procedures that can operate on it.

I hope you can see the essential difference there. Data-centric vs operation-centric.

Wikipedia is not necessarily the last word in definitive knowledge.

"Procedural programming", to me and others here, means explicitly specifying the steps to be followed and in what order. Normal object-oriented programming languages such as Smalltalk and C++ and Java are a subset of procedural programming, not something different. Languages such as Lisp and Scheme are a different subset of procedural programming.

Prolog, SNOBOL, Haskell are examples of non-procedural languages.

That is internally consistent, but not with the common usage of the term.

Would you class Erlang as a procedural language?

Would you class an FSM language as a procedural language?

Which allows the engineer to express their intent most concisely and successfully?

[tggzzz]

This is all departing a long way from OP's question, and by now is probably telling him nothing he doesn't know.

In procedural programming the procedures specify the types of data on which they can operate.
In object oriented programming the data specifies the procedures that can operate on it.

I am extremely uncomfortable with that as a definition, and suggest that you're confusing the concepts of "named procedure with predefined parameter types" and "procedure comprising a specific series of operations".

As others have pointed out, Smalltalk's methods are basically procedures, even if the parameters are specified unconventionally (by comparison with contemporary mainstream languages). And most if not all conventional languages with OO pretensions have an implicit parameter referring to the object being manipulated. There really is no distinct dividing line.

Well, everything is defined by the sequence of program counter states!

The difference is how you think about composing the sequence of states: data first or program counter first.

On the other hand are things like Prolog, and SQL queries. But even in those cases there are usually facilities for embedding specific procedural sequences.

I was once discussing Prolog and Japan's "5th Generation" project, and pointed out that the implementers had to tack on a substantial amount (the details are largely lost) of procedural capability to make it usable for systems programming. However somebody made the thought-provoking comment that it would probably be possible to handle e.g. an interrupt with adequately detailed Prolog-style rules: "We've got an interrupt, change the state of the system so that there is no longer an interrupting condition".

Prolog is very powerful in a limited domain. Two fundamental problems are side effects (e.g. I/O) and the closed world assumption. The former also arises with pure functional languages.

But in any event, the distinctions between the various paradigms (procedural, OO, functional, inferential and so on) is extremely vague, and I'd suggest that more than anything else they're the result of turf wars in academic research and laziness in academic teaching.

There is certainly grey areas between the various paradigms, and the pure academics can have fun debating them. And that's without considering that they are , like C++ Templates, Turing complete

Nonetheless, there are significant differences, and an engineer chooses a tool that allows them to express the design in a way that stands most chance of being successful.

[MarkMLl]

That is internally consistent, but not with the common usage of the term.

I suggest that it is the standard usage of the term, at least by people who've studied the available paradigms.

There are people who refer to tigers as felines and rhinos as equines when the correct terms are felids and equids: just because something is popular doesn't make it right.

MarkMLl

[MarkMLl]

Well, everything is defined by the sequence of program counter states!

Until one starts thinking about parallel systems, where the program counters exhibit not merely different sequences but might be subject to vastly different clock rates.

And without intending to imply any cause-or-effect relationship, that's particularly the case in an OO system or one where different subproblems can be "farmed out" (e.g. multithreaded searching in the logic programming domain).

Prolog is very powerful in a limited domain. Two fundamental problems are side effects (e.g. I/O) and the closed world assumption. The former also arises with pure functional languages.

I agree, but one problem is that there are always people who are prepared to push a paradigm or a language implementation far beyond what is reasonable. I remember once settling down to read a paper discussing the use of APL for astronomical calculations expecting that the author had hit upon some way of describing planetary orbits in matrix form, only to find that it was a transcpt of Meeus's standard numerical methods which could have been better done in BASIC... or even COBOL.

There is certainly grey areas between the various paradigms, and the pure academics can have fun debating them. And that's without considering that they are , like C++ Templates, Turing complete

...and the water is muddied enormously when a fairly pure initial implementation is polluted by extensions which depart far from the original paradigm since the implementor considers it easier to tack in a bit of OO or procedural parsing than to be able to link with other languages. A classic example of that was Turbo Prolog.

MarkMLl

[rstofer]

I completely forgot that Digital Research created a PL/I compiler for CP/M 2.2.  I have it and it works but I haven't used it much.

Of course, Gary Kildall (creator of Digital Research) also wrote the PL/M compiler for Intel.  It was written in FORTRAN.  I have the source but never bothered to get it up and running.  It's out on the web somewhere...

[rstofer]

...and the water is muddied enormously when a fairly pure initial implementation is polluted by extensions which depart far from the original paradigm since the implementor considers it easier to tack in a bit of OO or procedural parsing than to be able to link with other languages. A classic example of that was Turbo Prolog.

MarkMLl

Like adding OO to Fortran 2003?  Fortran 77 included structures. 
The original FORTRAN got us to the Moon and back.  This 'johnny-come-lately' stuff just isn't necessary.
With gfortran, it is possible to link to gcc code.  I have an example where I'm doing serial IO in C and high level stuff in Fortran.

[guenthert]

[..]
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.
[..]

You're discounting FORTH and the whole LISP family of languages there.  But yes, outside of those, that capability was (for the better or worse) rare.

[SiliconWizard]

The idea of overloading whitespace is fascinating, though. (See the other thread. )

[tggzzz]

Well, everything is defined by the sequence of program counter states!

Until one starts thinking about parallel systems, where the program counters exhibit not merely different sequences but might be subject to vastly different clock rates.

And without intending to imply any cause-or-effect relationship, that's particularly the case in an OO system or one where different subproblems can be "farmed out" (e.g. multithreaded searching in the logic programming domain).

That's a separate can of worms Most languages have multithreading (let alone multicore) as a bolt-on afterthought. I like xCORE processors plus xC (modern Occam ) because they start by presuming multicore systems.

Prolog is very powerful in a limited domain. Two fundamental problems are side effects (e.g. I/O) and the closed world assumption. The former also arises with pure functional languages.

I agree, but one problem is that there are always people who are prepared to push a paradigm or a language implementation far beyond what is reasonable. I remember once settling down to read a paper discussing the use of APL for astronomical calculations expecting that the author had hit upon some way of describing planetary orbits in matrix form, only to find that it was a transcpt of Meeus's standard numerical methods which could have been better done in BASIC... or even COBOL.

Oh, yes indeed.

Too many people only have hammers in their toolkit

There is certainly grey areas between the various paradigms, and the pure academics can have fun debating them. And that's without considering that they are , like C++ Templates, Turing complete

...and the water is muddied enormously when a fairly pure initial implementation is polluted by extensions which depart far from the original paradigm since the implementor considers it easier to tack in a bit of OO or procedural parsing than to be able to link with other languages. A classic example of that was Turbo Prolog.

MarkMLl

Oh, yes indeed.

Too many languages have become cancerous growths

[brucehoult]

I never used Turbo Prolog but I remember seeing it announced and I'd written a few Prolog programs before that. I don't know anything about cancerous growth, but what I do remember from the announcement was that it was missing at least one absolutely fundamental standard Prolog feature!  Was it assert & retract?

[MarkMLl]

I never used Turbo Prolog but I remember seeing it announced and I'd written a few Prolog programs before that. I don't know anything about cancerous growth, but what I do remember from the announcement was that it was missing at least one absolutely fundamental standard Prolog feature!  Was it assert & retract?

I'm no Prolog guru, but from what I know about the internals that would sound like the obvious bit for a naive implementation to sweep under the carpet.

I have, however, sold and supported a fair number of development tools, and have always been disappointed by how many companies attempted to have cross-language linkability and how quickly they folded afterwards. MS was one of the first to pull it off with .NET, which suffered from starting big leaving people who wanted to get it working truly cross-platform an almost impossible job.

I'd suggest that the fact that companies were allowed to get away with having multiple incompatible languages- or sometimes multiple incompatible implementations of the same language- was a symptom of the compartmentalisation of users' application domains. And I think that's still a major problem. The situation wasn't helped by the fact that separate compilation with a final linkage stage wasn't universally available until (depending on the platform... lots of handwaving here) the late 70s or early 80s: having to structure your modularisation around file inclusion is obviously extremely limiting.

MarkMLl

[brucehoult]

I have, however, sold and supported a fair number of development tools, and have always been disappointed by how many companies attempted to have cross-language linkability and how quickly they folded afterwards. MS was one of the first to pull it off with .NET, which suffered from starting big leaving people who wanted to get it working truly cross-platform an almost impossible job.

DEC did a pretty usable job on VAX/VMS by (among other things) making the compilers for every language (BASIC, Pascal, FORTRAN, COBOL) able to create and accept function arguments using all the calling conventions native to any of the other languages. Providing high level machine code procedure call instructions probably helped that too, even if it meant the actual performance was not as good as the older PDP 11/70 -- or for that matter using the VAX instruction set in a more RISCy way.

[MarkMLl]

DEC did a pretty usable job on VAX/VMS by (among other things) making the compilers for every language (BASIC, Pascal, FORTRAN, COBOL) able to create and accept function arguments using all the calling conventions native to any of the other languages. Providing high level machine code procedure call instructions probably helped that too, even if it meant the actual performance was not as good as the older PDP 11/70 -- or for that matter using the VAX instruction set in a more RISCy way.

From my limited exposure I think Multics did a fairly good job as well. But it quite simply didn't appear to be a high priority to most people, and those companies that tried it generally went TITSUP **

MarkMLl

** El Reg would come up with something like Totally Incapable To Support Unexpected Paradigms to explain that.

[DiTBho]

Prolog is pretty dead nowadays. Why?

[brucehoult]

** El Reg would come up with something like Totally Incapable To Support Unexpected Paradigms to explain that.

Since you mention that filthy rag ... ahhh, the old days of Magee and Lettice ... back when I was a 3rd year university student in Hamilton NZ in 1983 I got friendly with a 1st year student called Simon in one of the programming classes I was tutoring. Simon, myself, and a masters' student (Lawrence D'Oliviero) ended up having lunch together most days. Simon didn't get along with studies and dropped out and later got a job as a trainee operator on the university VAXes. (As I recall, he worked in retail at Dick Smith Electronics in between) He also started writing a satirical column for the student newspaper about the frustrations of the operator job. The rest is history.

[brucehoult]

Prolog is pretty dead nowadays. Why?

One-trick pony.

As is multiple layers of non-linear matrix multiplication.

[MarkMLl]

Prolog is pretty dead nowadays. Why?

One-trick pony.

In slightly more detail: people realised that a program needed to be able to do more than one specialist job, so even if it was desirable for it to be able to handle logical inference internally it also needed a decent user interface and so on. And despite the way that multiple Prolog implementations were enhanced with procedural extensions, eventually they concluded that it was easier to format the rules to suit a general-purpose language such as Python (which I consider utterly despicable, but that's another subthread) than it was to design a language from scratch which as well as being usefully procedural could also express the inference rules in a way that would be familiar to specialists in that area.

I consider that to be unfortunate, but languages with arbitrarily-extensible notation are notoriously difficult to get right.

The same applies to e.g. matrix handling: it can be expressed elegantly in APL and decent implementations can be remarkably time-efficient (often at the cost of memory space). It just /isn't/ any more.

One thing that surprises me is the scant amount of attention that Smalltalk gets these days, since it's shipped as standard on hundreds of thousands of computers every year.

MarkMLl

[DiTBho]

I'd like to learn and use Ruby. Unfortunately, I haven't yet found a book with Ruby examples. Maybe it depends on my domain of interests.

[Cerebus]

** El Reg would come up with something like Totally Incapable To Support Unexpected Paradigms to explain that.

Since you mention that filthy rag ... ahhh, the old days of Magee and Lettice ... back when I was a 3rd year university student in Hamilton NZ in 1983 I got friendly with a 1st year student called Simon in one of the programming classes I was tutoring. Simon, myself, and a masters' student (Lawrence D'Oliviero) ended up having lunch together most days. Simon didn't get along with studies and dropped out and later got a job as a trainee operator on the university VAXes. (As I recall, he worked in retail at Dick Smith Electronics in between) He also started writing a satirical column for the student newspaper about the frustrations of the operator job. The rest is history.

Back in the 90s I used to work with John Lettice at Dennis and I've drunk in most of London's pubs with Mike Magee. Everybody who knows Mike has at least two drinking stories about him: the one where Mike nearly/actually started a full scale pub fight and the one where they woke up in a cell/ditch/basement of a five star hotel/wherever. John himself was not un-averse to the traditional journalist's liquid lunch/dinner/supper/breakfast but was much quieter about it. I'd often go to the pub just around the corner from Dennis Towers to find him nursing a pile of copy to edit and a pint in the corner on his own.

Mike Magee:

You can almost hear him saying to the photographer "What did ye say, pal?"

I can't find any pictures of John, the rumour that he doesn't show up on film or in mirrors is, I'm sure, just that.

[SiliconWizard]

Prolog is pretty dead nowadays. Why?

Have you taken a look? IMHO, with a certain amount of professional experience, merely looking at the language is enough to answer this question. It's interesting, but definitely not made for doing anything really useful except a few toy examples, and possibly the kind of "expert systems" that were done in the 80's.

[SiliconWizard]

I'd like to learn and use Ruby. Unfortunately, I haven't yet found a book with Ruby examples. Maybe it depends on my domain of interests.

What would you like to implement with it?

[DiTBho]

I'd like to learn and use Ruby. Unfortunately, I haven't yet found a book with Ruby examples. Maybe it depends on my domain of interests.

What would you like to implement with it?

At the moment, a web-application (Ruby on Rail) 

[brucehoult]

I'd have thought there would be hundreds of Rails examples around. It's still used a lot. It's used in the back end by the company I'm working for now.

The shortage might be non-Rails examples with Ruby. I don't know ... I'm the kind that tens to just grab the reference manual and look at some existing code (that I have to modify, often) and go for it. I like Ruby a lot more than Python and shoul be using it for my quick-and-dirty stuff, but my fingers still effortlessly flow out Perl for that.

[DiTBho]

Prolog is pretty dead nowadays. Why?

Have you taken a look?

Yes, and the only professional use I am aware(1) of is Stood-2010 (written in C++ and Prolog)
-> about 12 years old software.

(1) because I use it at work.

[SiliconWizard]

What is  Stood-2010, and what part was written in Prolog?

[DiTBho]

What is  Stood-2010, and what part was written in Prolog?

The one related to the project design and constraints analysis , but I am not expert, and I cannot publish sources. Basically, the Prolog modules are

• the software requirements analysis module
• the software design core module, the GUI is written in C++, there is also a module that reads external files in order to prepare a system requirements table { hardware, operating System, ... } and a realization constraints table { team organization, technical choices, quality standards, ... } .... there is also a C++ module that processes UML 2.0
• the software unit testing module, it generates C code + ICE scripts
• the software functional testing module, it generates C code + ICE scripts
• the documentation framework, it calls a C++ module that calls a kind of Office module that calls Microsoft World and generates a document ... kind of light solution for trace-ability requirements

80% is written in Prolog. All the processing core.
C++ is used as wrapper, to read/write text files and for the GUI.


edit:
there is also a "C-code reverse engineering" module written in Prolog, but it doesn't compile.

[MarkMLl]

I like Ruby a lot more than Python and shoul be using it for my quick-and-dirty stuff, but my fingers still effortlessly flow out Perl for that.

The Perl community got the language a terminally-bad reputation by being excessively clever: uncommented one-liners for the sake of it.

Python is an abomination.

MarkMLl

[Cerebus]

... shoul be using it for my quick-and-dirty stuff, but my fingers still effortlessly flow out Perl for that.

You do know you can get medication for that nowadays? 

[brucehoult]

The Perl community got the language a terminally-bad reputation by being excessively clever: uncommented one-liners for the sake of it.

It's possible to go overboard, of course, but here's one I use frequently when posting code to online forums that use markdown rather than bbcode (e.g. Redit):

Code: [Select]

perl -pe '$_ = "    $_"' foo.c

Ok, you could use sed or awk just as well for that one, but I prefer to know perl well than all of them poorly.

[SiliconWizard]

What is  Stood-2010, and what part was written in Prolog?

The one related to the project design and constraints analysis , but I am not expert, and I cannot publish sources. Basically, the Prolog modules are
(snip)
80% is written in Prolog. All the processing core.

OK. I'd guess it's essentially a rule-based system. So it pretty much falls into the category I was talking about, such as good old expert systems.
Sure Prolog is not bad for that, although I think there are better solutions these days for rule-based systems and logic proofing.

edit:
there is also a "C-code reverse engineering" module written in Prolog, but it doesn't compile.

 

[DiTBho]

there is also a "C-code reverse engineering" module written in Prolog, but it doesn't compile.

Yes, essentially it's a rule-based system, but ironically, that is the most interesting part for me 

I mean, I don't know anything about Prolog, and I don't need to recompile Stood, I use Stood at work to create projects' skeleton with a plan for their trace-ability; Stood for me is a program that runs on a workstation; on my little laptop I only wanted to use that reverse-engineering-module coupled with IDA to analyze a couple of ROMs, but no dice, it doesn't even compile.

[DiTBho]

The Chapter 2 tries to make the point:
PL/I -> E/PL (created to be simpler than PL/I)
BCPL created to simpler than PL/I and its dialects
BCPL ->B (created to run on a machine with limited RAM)
B -> C (created to be portable and with types)

So, I should also be able to understand E/PL, BCPL and B examples
(I hope )

[MarkMLl]

Although BCPL is more often described as being a descendant of CPL, hence of ALGOL, making it a sibling of PL/I rather than a descendant.

Considered as a system implementation language, BCPL was also a contemporary of Wirth's PL/360 at Stanford.

MarkMLl

[MarkMLl]

Sure Prolog is not bad for that, although I think there are better solutions these days for rule-based systems and logic proofing.

Although at that point I think one needs to distinguish between the Prolog notation (styled after Horn Clauses, hence familiar to many workers in "knowledge engineering") and the backend resolution mechanism which in principle could use any frontend language.

I'm torn over the desirability of fancy application-specific notations which are completely unlike conventional programming languages. On the one hand they have the desirable property of being familiar to their users, while on the other they provide an excuse for academics to waste years coming up with efficient and reliable parsers.

MarkMLl

[tggzzz]

I'm torn over the desirability of fancy application-specific notations which are completely unlike conventional programming languages. On the one hand they have the desirable property of being familiar to their users, while on the other they provide an excuse for academics to waste years coming up with efficient and reliable parsers.

This is more often seen in the form of Domain Specific Language vs Domain Specific Library.

It seems that all computer science graduates hanker after creating a language, just as electronic engineer graduates want to create a processor. In almost all cases those turn out to be poor - as features get bolted on even the designer doesn't understand them all and their interactions. Then, on top of that, there's no tooling for their special purpose creation, which is either crippling expensive or limiting. And on top of that, you have to train staff and find staff that are willing to learn something that wont be helpful elsewhere.

Hence I'm very wary of DSLanguages, and usually prefer DSLibraries

It is sometimes not apprectiated that the reason the intel 8080 won over most of the competition was not because of the (mediocre) silicon, it was because intel provided an ecosystem of boards, languages, and development systems.

[MarkMLl]

This is more often seen in the form of Domain Specific Language vs Domain Specific Library.

That is true. But even if the library that provides the backend computation is good, non-programmer users are likely to be unhappy if the language is hostile: cartographers will expect a way of entering degree-minute-second coordinates without having to quote them as strings, engineers will expect that /all/ arithmetic operations extend seamlessly to complex numbers, and so on.

It seems that all computer science graduates hanker after creating a language, just as electronic engineer graduates want to create a processor.

But at the same time, there has to be a pathway by which they can gain the knowledge and experience to do this adequately. Otherwise there will be no new designs... ARM and AVR didn't come out of existing big corporates (Itanium and IBM Workplace OS did).

It is sometimes not apprectiated that the reason the intel 8080 won over most of the competition was not because of the (mediocre) silicon, it was because intel provided an ecosystem of boards, languages, and development systems.

The 8080 was losing ground to Intel's own 8048 on one hand and Zilog's Z80 on the other... not to mention Motorola's 68k. The 8086 was widely regarded as lackluster with many potential customers hanging on for Zilog's promised Z800 (running at an unprecedented 20MHz), the thing that saved Intel was IBM's adoption of the 8088 in an unprecedentedly-open architecture which meant that developers no longer had to shell out for Intel blue boxes or hunt for a spare ASR33.

MarkMLl

[SiliconWizard]

It is sometimes not apprectiated that the reason the intel 8080 won over most of the competition was not because of the (mediocre) silicon, it was because intel provided an ecosystem of boards, languages, and development systems.

The popularity of a given processor or programming language in general is almost always due to the available ecosystem rather than its own merits.

[Cerebus]

Although BCPL is more often described as being a descendant of CPL, hence of ALGOL, making it a sibling of PL/I rather than a descendant.

Considered as a system implementation language, BCPL was also a contemporary of Wirth's PL/360 at Stanford.

MarkMLl

The definitive statement on this would come from Martin Richards the designer of BCPL, who is still alive and kicking. The paper "How BCPL evolved from CPL" would seem, just in its title, to be a pretty authoritative statement on the matter. CPL had it's conceptual origins in 1961, PL/1 in 1963, and BCPL in 1966.

[tggzzz]

It is sometimes not apprectiated that the reason the intel 8080 won over most of the competition was not because of the (mediocre) silicon, it was because intel provided an ecosystem of boards, languages, and development systems.

The 8080 was losing ground to Intel's own 8048 on one hand and Zilog's Z80 on the other... not to mention Motorola's 68k. The 8086 was widely regarded as lackluster with many potential customers hanging on for Zilog's promised Z800 (running at an unprecedented 20MHz), the thing that saved Intel was IBM's adoption of the 8088 in an unprecedentedly-open architecture which meant that developers no longer had to shell out for Intel blue boxes or hunt for a spare ASR33.

MarkMLl

That was the case in the 80s. I was thinking of the earlier (blue box, 8-bit) generation in the late 70s.

[MarkMLl]

The definitive statement on this would come from Martin Richards the designer of BCPL, who is still alive and kicking. The paper "How BCPL evolved from CPL" would seem, just in its title, to be a pretty authoritative statement on the matter. CPL had it's conceptual origins in 1961, PL/1 in 1963, and BCPL in 1966.

Thanks, there's a lot of meat in that. One thing that's somewhat understated is that they appeared to be using "Pascal style" calling convention where the return opcode knows how many operands to pop off the stack, somewhere in between BCPL and C that was changed to allow the caller to use a variable number of parameters.

I've had a previous run-in with the Cambridge character sets https://scifi.stackexchange.com/questions/233847/first-fictional-programming-language-in-sci-fi-or-fantasy/233942#233942 :-)

MarkMLl

[SiliconWizard]

Although BCPL is more often described as being a descendant of CPL, hence of ALGOL, making it a sibling of PL/I rather than a descendant.

Considered as a system implementation language, BCPL was also a contemporary of Wirth's PL/360 at Stanford.

MarkMLl

The definitive statement on this would come from Martin Richards the designer of BCPL, who is still alive and kicking. The paper "How BCPL evolved from CPL" would seem, just in its title, to be a pretty authoritative statement on the matter.

Btw, there is an interesting feature talked about in this paper:

let w ≡ xx + 2xy + yy
Every time w is evaluated it recomputes xx + 2xy + yy
using the current values of x and y. In CPL, xx means x
multiplied by x. Multi-character identifiers had to start
with capital letters.

(I don't like the CPL multi-character rule here at all, but not what I'm interested in.)

I've been thinking for a while now that the only reasonable use of the "let" keyword in a programming language should be exactly this: defining substitutions of expressions that hold true at all times, just like the way we use "let" in math. (But the CPL language required the '≡' symbol instead of '=', which I don't particularly like here. To me, that should be the meaning of "let".)

Using "let" merely as a way to declare, and initialize a variable, is wrong on every level IMHO.
But the ability of defining substitutions would be tremendously useful and help with code clarity and code correctness. I don't think I have seen this in a modern language. Please point me to one if there is - certainly there are some of them that I don't know well, especially the functional languages.

Obviously you can define such substitutions with macros, but that's a quirky way of doing things, has potential pitfalls, and does not lend itself well to a range of verifications and analysis.

[Cerebus]

I've been thinking for a while now that the only reasonable use of the "let" keyword in a programming language should be exactly this: defining substitutions of expressions that hold true at all times, just like the way we use "let" in math. (But the CPL language required the '≡' symbol instead of '=', which I don't particularly like here. To me, that should be the meaning of "let".)

Using "let" merely as a way to declare, and initialize a variable, is wrong on every level IMHO.

You won't find me disagreeing with you there. I think the Cambridge computer scientists were mathematicians first, and that tends - as you note - toward that interpretation of the work 'let'. In a similar vein, I have a strong dislike of the use of '=' as an assignment operator; I much prefer the Algol 68 ':=' (read out loud as 'becomes'), or the backarrow character '←' for assignment. I dislike backarrow simply because it shows up poorly in many fonts and we don't have it on keyboards nowadays (We did in the past, but it got usurped by the underscore.).

[MarkMLl]

The forum's losing postings where two people try to comment simultaneously. Happened to me twice today.

strong dislike of the use of '=' as an assignment operator; I much prefer the Algol 68 ':=' (read out loud as 'becomes'), or the backarrow character '←' for assignment. I dislike backarrow simply because it shows up poorly in many fonts and we don't have it on keyboards nowadays (We did in the past, but it got usurped by the underscore.).

:= was originally a digraph for the arrow. I think the last arrow holdout was PARC, in Smalltalk and Mesa.

I favour := for assignment and == for comparison, the single-character = should be phased out.

The scope for confusion is particularly bad where multiple assignment is allowed, e.g. something like

Code: [Select]

  a = b == c = d;

MarkMLl

[MarkMLl]

Second attempt at posting this, apologies if anybody sees a duplicate.

Using "let" merely as a way to declare, and initialize a variable, is wrong on every level IMHO.
But the ability of defining substitutions would be tremendously useful and help with code clarity and code correctness. I don't think I have seen this in a modern language. Please point me to one if there is - certainly there are some of them that I don't know well, especially the functional languages.

I think that Rust uses let as definition/assignment, and a lot of careful thought appears to have gone into it.

I think that what you're suggesting is somewhat like the classical macro substitutions, and I'm not sure what the prevailing opinion on those is these days, i.e. whether they should have a mandatory sigil or mandatory enclosure.

The language I use most heavily has limited substitution capabilities which can get frustrating: like GOTO they're something you might not need often and might have associated health warnings, but when you need them you /really/ need them.

MarkMLl

[SiliconWizard]

I've been thinking for a while now that the only reasonable use of the "let" keyword in a programming language should be exactly this: defining substitutions of expressions that hold true at all times, just like the way we use "let" in math. (But the CPL language required the '≡' symbol instead of '=', which I don't particularly like here. To me, that should be the meaning of "let".)

Using "let" merely as a way to declare, and initialize a variable, is wrong on every level IMHO.

You won't find me disagreeing with you there. I think the Cambridge computer scientists were mathematicians first, and that tends - as you note - toward that interpretation of the work 'let'. In a similar vein, I have a strong dislike of the use of '=' as an assignment operator; I much prefer the Algol 68 ':=' (read out loud as 'becomes'), or the backarrow character '←' for assignment. I dislike backarrow simply because it shows up poorly in many fonts and we don't have it on keyboards nowadays (We did in the past, but it got usurped by the underscore.).

Same here. Of course the back-arrow can just be typed as '<-'. That's usually not hard to read, although it looks better with some fonts than others.

Speaking of fonts, the JetBrains mono has ligatures that will make '<-', '->', and a lot of other combinations appear as ligatures. https://www.jetbrains.com/lp/mono/
I have a mixed feeling about that, but I admit I haven't tested this font yet, so, I'd have to see how well it works, or maybe how annoying it is in practice.

[MarkMLl]

Same here. Of course the back-arrow can just be typed as '<-'. That's usually not hard to read, although it looks better with some fonts than others.

I'm a fan of overstrikes since they worked well in APL: the worst thing that happened to the language was moving it onto a terminal which tried to have a separate key for each operator e.g. http://www.aplusdev.org/keyboard.gif

However, something like <- is going to be an enormous problem if not immediately supported by the character set: having something like  x<-2  requires either that a type has already been associated with x and that the lexer has access to the symbol table, or that the lexer starts being sensitive to whitespace to an extent that has usually been avoided.

MarkMLl

[Cerebus]

:= was originally a digraph for the arrow.

It was, but it took on a life of its own leading to "::=" (is defined as) in BNF and other places.

[SiliconWizard]

However, something like <- is going to be an enormous problem if not immediately supported by the character set: having something like  x<-2  requires either that a type has already been associated with x and that the lexer has access to the symbol table, or that the lexer starts being sensitive to whitespace to an extent that has usually been avoided.

Well. It depends. It would be a problem in languages that allow using assignments as expressions, or allowing expressions with no effect. Thus making the above example ambiguous. Certainly, that wouldn't work in C, since both are allowed. Indeed, "x < -2;" (using whitespace to make it clear) can be a statement in C. And "x = 2" is an expression.

If you don't allow either, you don't need to be sensitive to whitespace. You only need to be sensitive to context. Some languages do use the '<-' operator (Go with channels, for instance), and it causes no issue. Writing to a channel is "chan <- something".  Reading from a channel is "<- chan". I don't think there is any context in which it could be ambiguous.

I still much prefer  ':=' for assignment in a prog. language (I only use the back-arrow for pseudo-code), but just saying that it's not necessarily a deal-breaker.

[Cerebus]

Same here. Of course the back-arrow can just be typed as '<-'. That's usually not hard to read, although it looks better with some fonts than others.

I'm a fan of overstrikes since they worked well in APL: the worst thing that happened to the language was moving it onto a terminal which tried to have a separate key for each operator e.g. http://www.aplusdev.org/keyboard.gif

However, something like <- is going to be an enormous problem if not immediately supported by the character set: having something like  x<-2  requires either that a type has already been associated with x and that the lexer has access to the symbol table, or that the lexer starts being sensitive to whitespace to an extent that has usually been avoided.

MarkMLl

I have a bit of a love/hate relationship with languages that require you to get into keyboard kontortions to enter them.

Algol-68 has, in its definition, 'large syntactic marks' and 'small syntactic marks' which in presentation form becomes:

proc double (int x) int = 
begin
    x * 2
end

But had to be entered as actual program code (depending on whether you had access to lowercase) as:

PROC double (INT x) INT = 
BEGIN
    x * 2
END

or

'PROC' DOUBLE ('INT' X) 'INT' = 
'BEGIN'
    X * 2
'END'

The first Algol-68 compiler I had access to (on an ICL 1900) used the latter 'stropping' style. Yuch!

[tggzzz]

The first Algol-68 compiler I had access to (on an ICL 1900) used the latter 'stropping' style. Yuch!

Ditto on an ICL 2900. I felt the chance of getting it right first time was so low that I didn't bother and went and did something more profitable!

[MarkMLl]

Algol-68 has, in its definition, 'large syntactic marks' and 'small syntactic marks' which in presentation form becomes:

I have a theory that ALGOL-68 was sabotaged: it was never meant to succeed.

MarkMLl

[IanB]

When I was first exploring the programming languages available on a TOPS-10 system, Algol was one of the ones that didn't commend itself very much. FORTRAN was much more accessible, as was probably its intention.

[tggzzz]

Algol-60 was my first language,on an Elliott 803. Tony Boards compiler is regarded as groundbreaking.

[Cerebus]

Algol-68 has, in its definition, 'large syntactic marks' and 'small syntactic marks' which in presentation form becomes:

I have a theory that ALGOL-68 was sabotaged: it was never meant to succeed.

MarkMLl

Letting Adriaan van Wijngaarden persuade people to use a van Wijngaarden two-level grammar as the definitive version of the language definition was tantamount to sabotage. I know people who can 'out compiler' me before breakfast who can't get their heads around VWF.

Also telling people that the variable declaration:

    int a variable := 1;

was shorthand for:

    (ref int a variable = loc int) := 1;

and was very different from

    int a constant = 1;

quickly left people as confused as all heck, and left those of us with assembler and systems programming experience going "Hm, interesting..."

It (Algol-68) is still my personal favourite of classical imperative languages, in the right hands with the right compiler it was a superb language that never gained wide acceptance. I'd probably still use it as my day to day language of choice, but for the absence of support equivalent to other languages on modern platforms.

[SiliconWizard]

Algol-68 has, in its definition, 'large syntactic marks' and 'small syntactic marks' which in presentation form becomes:

I have a theory that ALGOL-68 was sabotaged: it was never meant to succeed.

Uh, not sure one can say that. It's always extremely hard to predict the success of a programming language. The real successes actually, have been pretty unexpected for the most part.

But from what I've seen, ALGOL-68 was just too complex for its time. So, maybe that was the obvious part that made it unpractical. The tooling was just too hard to write. Wirth went on with Algol-W and then Pascal. Algol-68 died.

You could say that C++ is also very complex, but it only became complex over time, not right from the start. Stroustrup was clever enough to introduce complexity slowly and mischievously. If C++ had been anything near C++20 in the 80's, it would also have failed spectacularly IMO.

[Cerebus]

But from what I've seen, ALGOL-68 was just too complex for its time.

The language itself wasn't too complex for the time, but a lot of people found the report and revised report too difficult to understand, and as a consequence it developed a reputation as being really hard to write a compiler for. Add to that it was unclear to many at the time how to produce a compiler that could handle the context sensitivity inherent to the language's expression structure. Much discussion of strong and weak contexts for coercion (casting), dereferencing and deproceduring (making procedure calls) added to 'implementors fear' around the language.

[brucehoult]

Thanks, there's a lot of meat in that. One thing that's somewhat understated is that they appeared to be using "Pascal style" calling convention where the return opcode knows how many operands to pop off the stack, somewhere in between BCPL and C that was changed to allow the caller to use a variable number of parameters.

It's obviously better for code size to have the called function do as much of the work as possible rather than duplicating it for every function call in all of it's (possibly) many callers. And varargs is something that is not actually used all that often, outside of printf() and a couple of others.

On all RISC ABIs I can think of right now (let's leave SPARC register windows out) the issue is usually side-stepped because most functions can have all their arguments passed entirely in registers. RISC-V, Aarch64, POWER all pass up to 8 arguments in registers, and 32 bit ARM up to 4. This also applies to x86_64 with up to six arguments in registers on every OS except Windows (which uses 4).

Even when the argument registers overflow, modern ABIs generally don't clean up after every function call, unlike the case on 32 bit x86 and m68k.

x86_64 does, with overflow arguments stored with a whole bunch of pushq, then call, then then an addq $nn, %rsp after every call.

But on ARM and POWER and RISC-V (both 32 bit and 64 bit) the compiler just figures out what the maximum number of overflow arguments are for all functions called by the current function (plus saved registers and overflow local variables) and allocates stack once at the start of the function and deallocates it once at the end of the function. Every called function gets its overflow arguments (if any) passed at SP, 4(SP), 8(SP) etc with the same SP value every time.

This works the same with both fixed number and variable number of arguments because the compiler sees all the calls in the current function and knows how many arguments there are for those particular calls.

[MarkMLl]

But from what I've seen, ALGOL-68 was just too complex for its time. So, maybe that was the obvious part that made it unpractical. The tooling was just too hard to write. Wirth went on with Algol-W and then Pascal. Algol-68 died.

I'm afraid your chronology is wrong there. ALGOL-W preceded ALGOL-68 and was Wirth's proposal. When AvW outflanked him he resigned from the standardisation committee in May 1968 and then designed Pascal in about four or five months so that he could allocate work on it at the start of the postgrad year. And while he based it on ALGOL-W, he intentionally changed some things to break syntactic compatibility: he was effectively washing his hands of ALGOL.

If Wirth hadn't thrown his toys out of the pram, he and Hoare would have been able to muster enough support to prevent the AvW proposal from being accepted as the standard, and possibly to get some variant of ALGOL-W through instead.

Unfortunately I suspect that Wirth had been manoeuvred into a position where he felt that resignation was inevitable, and that was because...

Letting Adriaan van Wijngaarden persuade people to use a van Wijngaarden two-level grammar as the definitive version of the language definition was tantamount to sabotage. I know people who can 'out compiler' me before breakfast who can't get their heads around VWF.

...AvW had been diverted onto the intellectually-interesting attempt at formal definition by somebody who had, until comparatively recently, been Wirth's boss at Stanford. If one considers it, the grammar was much more the sort of thing that the long-hairs at Stanford and MIT liked, while the Europeans were more intent on having something that worked.

http://www.tomandmaria.com/Tom/Writing/DijkstrasCrisis_LeidenDRAFT.pdf

MarkMLl

[SiliconWizard]

But from what I've seen, ALGOL-68 was just too complex for its time. So, maybe that was the obvious part that made it unpractical. The tooling was just too hard to write. Wirth went on with Algol-W and then Pascal. Algol-68 died.

I'm afraid your chronology is wrong there. ALGOL-W preceded ALGOL-68 and was Wirth's proposal.

Never said otherwise. Possibly you misinterpreted the "went on". I know it was Wirth's proposal for Algol 68. All I said is that it was practical enough (but apparently judged not enough of new things) to write a compiler for. Algol W had a compiler, and some people actually used it before Pascal was fully spec'ed and compilers available for it. That's what I mean with "went on". Maybe Wirth was being a dick or not, I absolutely don't know and don't really care, but all I know is that the languages he designed, maybe too simplistic for some, were always clearly specified and easy to write compilers for. That was not the case for what Algol-68 ended up being.

Algol-W didn't die when it didn't make it for Algol-68 - the last ref. manual is dated June 1972, while the final report of Algol-68 was 1968 and a revised report in 1973.

As to the rest of your post, I certainly didn't know all the politics involved in this, something you seem to know. So, that's informative.

But still, back to Algol-68: it was definitely too unpractical to see the light, whatever the politics otherwise did to undermine it.

[Cerebus]

But still, back to Algol-68: it was definitely too unpractical to see the light, whatever the politics otherwise did to undermine it.

Well, see the light it did. The Royal Signal and Radar Establishment produced the Algol 68R and RS compiler which ran on lots of hardware, including two generations of ICL mainframes. Honeywell mainframes (including under Multics) did too. A lot of UK military code was written in Algol 68 (which didn't necessarily give it a high profile - my copy of the RS porting manual came with an UNCLASSIFIED printed on every page, which may be a hint as to the visibility of some o the other things going on with it).

The Dartmouth TSS had a compiler. Cambridge University produced the 68C compiler that ended on IBM mainframes and most kit at the University itself, including the Cambridge CAP computer for which it was the systems programming language. CDC had their own compiler. CMU produced the 68S compiler, which ran on a range of systems, notably including PDP-11s. There was an IBM PC compiler produced by Charles Lindsey starting from the 68S code in 1984. SunOS got a compiler. There are probably quite a few others I don't know about.

[MarkMLl]

Well, see the light it did.

OTOH, were those really full implementations of the language as specified? I think I recognise some of the ones you've mentioned as having documented limitations.

I think the bottom line is that a very high proportion of the implementations of "large" languages turn out to be incomplete: ALGOL-68, Ada, and (with a nod to OP, if he's still with us :-) PL/I

Which is possibly an argument for keeping languages small but strict, and moving as much functionality as possible into support libraries.

MarkMLl

[brucehoult]

Algol W had a compiler, and some people actually used it before Pascal was fully spec'ed and compilers available for it.

Most of the people in my year at university used Algol W in their last year at high school (1980).

They hand-"punched" cards with their programs (I think using a marker pen). The decks were taken to a local bank and the programs run on NZs centralised "Databank" computer after the day's cheques had been processed. I don't know whether there were card readers and printers in each town or whether they were taken to Auckland or Wellington.

My school had a different system. We did FORTRAN on pre-scored cards that we removed chads from using a paper clip or ballpoint pen. The applied maths teacher (who is now 97 and I visited just before Christmas) took them into a local bureau that had a B1700 and ran them through (in person) after the night's processing was finished. I went in with him a few times as I was doing personal programs a lot more complicated than the class assignments and they often needed debugging or incremental improvements.

[armandine2]

A book not widely available but apparently easy to understand - Roper (1973) PL/1 in Easy Stages

[Cerebus]

Well, see the light it did.

OTOH, were those really full implementations of the language as specified? I think I recognise some of the ones you've mentioned as having documented limitations.

I think the bottom line is that a very high proportion of the implementations of "large" languages turn out to be incomplete: ALGOL-68, Ada, and (with a nod to OP, if he's still with us :-) PL/I

Which is possibly an argument for keeping languages small but strict, and moving as much functionality as possible into support libraries.

MarkMLl

The RSRE 86R compiler and possibly the RS required declaration before use (as in physically earlier in the source code) to enable it/them to be single pass. Both omitted parallel clauses (as in execution in parallel) and I don't know of any Algol 68 compiler that did actually implement parallel clauses. Other than that they were complete.

Algol 68 wasn't that big a language, it's comparable in size to C (about the only non-shared basic language features I can think of are defining new operators, tracking the current type of unions, flexible arrays, keeping track of REF depth and the universally ignored parallel execution) and compared to C++ it's miniscule.

[MarkMLl]

My school had a different system. We did FORTRAN on pre-scored cards that we removed chads from using a paper clip or ballpoint pen. The applied maths teacher (who is now 97 and I visited just before Christmas) took them into a local bureau that had a B1700 and ran them through (in person) after the night's processing was finished. I went in with him a few times as I was doing personal programs a lot more complicated than the class assignments and they often needed debugging or incremental improvements.

Ah yes, the B1700. Booted by reading 16 bits at a time from a cassette and treating it as an opcode... which also allowed MTR (Maintenance Test Routine) tapes to do a useful amount of work. Which was needed, since the "Burroughs Transistor Logic" it used got more and more flaky as the company had difficulty sourcing it (I think it was really Fairchild CTL).

I got into work one morning and fired up a test sequence on the machine I was working on, to find that the middle 8 bits of the 24-bit registers were dead. On opening it up I found I'd left the middle card of the ALU pulled... at that point I was enlightened :-)

MarkMLl

[brucehoult]

Ah yes, the B1700. Booted by reading 16 bits at a time from a cassette and treating it as an opcode... which also allowed MTR (Maintenance Test Routine) tapes to do a useful amount of work. Which was needed, since the "Burroughs Transistor Logic" it used got more and more flaky as the company had difficulty sourcing it (I think it was really Fairchild CTL).

I helped to boot it up a few times, but only a few, and it was 40+ years ago.

I remember turning a big dial to select a registers, entering values on switches to deposit into the registers. Rewinding a cassette just to the right of the blinkenlights. I *thought* the couple of instructions entered manually then read a small card deck with the code for reading the cassette, then the code on the cassette could talk to the disk packs and boot the OS. But I can very easily be wrong.

[MarkMLl]

If you had to set switches and/or load a card it would probably be to specify a non-standard boot device. The 1700 would normally have had a head-per-track disc http://www.picklesnet.com/burroughs/images/fullsize/burr0137.jpg but if it had been replaced by a (top-loading) pack or (front-loading) cartridge drive that would explain it.

The combination of switches and tape made the innards very accessible... which was lucky, since the unfortunate field guys had to do component-level repairs with the customer breathing down their neck and an ever-decreasing stock of reliable spares as the company tightened its belt (around its own neck) heading into the mid 1980s.

MarkMLl

[DiTBho]

Which is possibly an argument for keeping languages small but strict, and moving as much functionality as possible into support libraries.

Yesterday I read chapter 3 and as far as I understand the PL / I examples need to call external functions from libraries to access a single byte. Digging deeper into the reason showed that IO instructions on some machines were only able to access 36 (  ) bits, so functions are needed to manipulate 8 bits.

That's new for me. I am used to use uint8_t, uint16_t and uint32_t directly provided by the C language.

[MarkMLl]

Yesterday I read chapter 3 and as far as I understand the PL / I examples need to call external functions from libraries to access a single byte. Digging deeper into the reason showed that IO instructions on some machines were only able to access 36 (  ) bits, so functions are needed to manipulate 8 bits.

That's new for me. I am used to use uint8_t, uint16_t and uint32_t directly provided by the C language.

It's easiest to build this up gradually.

Discounting low-end stuff like the LGP-30, most early computers had supplementary hardware to handle I/O (both batch and interactive) and their internal software interacted with an edit buffer not unlike printf()/scanf() in C. The result of this is that a 6-bit code was considered adequate since it provided enough space for fixed-case alpha, the numerics, and sundry operators etc. which in many cases were heavily influenced by ALGOL-60's requirements https://en.wikipedia.org/wiki/Six-bit_character_code

This provided an incentive for memory and register width to be some multiple of 6 bits, and in some cases there were supplementary operators which manipulated text in memory independent of the standard numeric operators... famously https://en.wikipedia.org/wiki/IBM_7950_Harvest

However, there was a general understanding that the principal role of the computer was to handle numeric problems with text manipulation being very much supplementary. Hence the word size would be chosen to match the problem domain and would usually be supported by floating point numeric operations on full words: while double- or half-word operands might be supported they might not even use standard algebraic notation, and integer support might simply use the mantissa bits with the exponent forced zero.

Hence many computers of that era settled on a 36-bit full-word, sometimes with a "little brother" based on 18-bit half-words. Notable exceptions were the Burroughs large systems (48 bits) and the Burroughs "small systems" where the operand could be anything between 1 and 24 bits (with 16-bit opcodes and bit-addressable 16-bit memory).

That started to change when IBM introduced the S/360 as a general-purpose machine, with 8-bit bytes supporting both EBCDIC and ASCII, 32-bit words and byte-addressable memory. But even after that mainframes tried to avoid doing too much text manipulation: they were very much oriented to receiving a fixed-format record from an I/O controller, manipulating it in conjunction with fixed-format records from local storage (via another I/O controller), and sending another fixed-format record back to an I/O controller where it could be sent to e.g. a bank clerk's terminal and merged- at the terminal- with a preloaded screen template.

Glad you're still with us and hope you don't find the wibble too distracting :-)

MarkMLl

[DiTBho]

Glad you're still with us and hope you don't find the wibble too distracting :-)

I do find it very informative, providing useful and interesting information


A thing I learned from the book: IBM was one of the first implementing a full B*tree algorithm to manage database records on hard-disk. That's something I have to carefully learn and implement for the firmware of my embroidery machine which is currently memory-only based.

[MarkMLl]

A thing I learned from the book: IBM was one of the first implementing a full B*tree algorithm to manage database records on hard-disk. That's something I have to carefully learn and implement for the firmware of my embroidery machine which is currently memory-only based.

Now /that's/ interesting, since some years later they bought a company called Solid for the sake of their "Bonsai Tree" storage technology :-)

One has to be rather cautious about IBM DASD (i.e. mainframe disk) storage since they had at least some indexing capability built into the controllers. And they relied heavily on record-oriented file structure with organisation and cylinder allocation predefined... which had a big effect on OS/360 and DOS/360 but much less on VM and CMS which were cousins of Multics hence UNIX.

I presume you're aware of https://www.eevblog.com/forum/reviews/brother-(possibly-also-bernina)-embroidery-machine-memory-cards/?all which is still getting sporadic attention.

MarkMLl

[tggzzz]

Which is possibly an argument for keeping languages small but strict, and moving as much functionality as possible into support libraries.

Yesterday I read chapter 3 and as far as I understand the PL / I examples need to call external functions from libraries to access a single byte. Digging deeper into the reason showed that IO instructions on some machines were only able to access 36 (  ) bits, so functions are needed to manipulate 8 bits.

That's new for me. I am used to use uint8_t, uint16_t and uint32_t directly provided by the C language.

And what are you used to for "int"?

On a 36-bit machine it will be 36 bits.

On the first machine I used int would have been 39 bits, and pointers 13 bits - since there was an architectural maximum of 8192 words.

No, there was no C compiler, but there was a pioneering Algol-60 compiler by Tony Hoare

ICL machines were 24-bit, and had 6 bit characters - so a byte would have been 6 bits, not 8

[SiliconWizard]

That was admittedly pretty atrocious for general-purpose use, and hardly the language's fault. Just the hardware.

[tggzzz]

That was admittedly pretty atrocious for general-purpose use, and hardly the language's fault. Just the hardware.

The ICL machines were widely used at the time, were good, and were certainly good for general purpose uses. But not for C!

[MarkMLl]

The ICL machines were widely used at the time, were good, and were certainly good for general purpose uses. But not for C!

It has to be said: widely used in the UK, due to pressure on government-related purchasers i.e. universities etc.

That doesn't necessarily detract from their quality and innovation, but the market wasn't entirely open.

MarkMLl

[Cerebus]

It has to be said: widely used in the UK,

And the empire commonwealth, don't forget. 

As well as the more obvious places (Australia, Indian, Egypt [everyone forgets that Egypt was under British occupation until 1956 and retained close ties for quite a long time afterward], South Africa and various Arab countries) Poland was a market for the 1900 series. There were a handful of installations in various other European countries and, of all the unlikely places, at the Federal Reserve Bank of New York.

[SiliconWizard]

Oh well. There are a few good reasons why word widths that are a power of two are much easier and more efficient to handle, except possibly in very niche applications.
That was, as I remember, discussed a few times in other threads already.
That is of course not to say that non-power-of-two widths are completely unusable. You can always work around any limitation using the appropriate operations. But they make it much clunkier for many things.

[brucehoult]

A couple of the government computing centres in NZ got ICL mainframes in the late 70s, but they were not well liked. To quote one web page [1] "When the ICL 2980 at Trentham finally became operational in 1978 it was quickly discovered to be a clunker, and a decision was made to use it mainly for Customs. The DSIR stayed with the Cumberland centre where it now linked to the IBM system 370/168"

The main universities all got B6700's, as did some of the government computer centres, which they seemed to like well enough. They all moved to new generation IBMs in the late 1980s (4341 or similar).

Databank NZ, a commercial company set up by and jointly owned by all the main banks in 1967 for processing cheques used IBM 360.

The smaller universities went DEC, with PDP-11 then VAX. The polytechnics all got Data General.

[1] https://www.nethistory.co.nz/Chapter_2_-_Battling_with_Big_Iron/

[MarkMLl]

And the empire commonwealth, don't forget. 

I was going to say that, but since both the Empire and Commonwealth have faded and since the United Kingdom is under threat due to the the devolution of chunks of Great Britain I thought the complexity would detract from the point.

I was also going to say that the reach of the "must buy ICL" policy was long when you consider that ICL was subsumed into Fujitsu, and that Fujitsu's incompetence and duplicity ended up in the wrongful conviction of hundreds of sub-postmasters.

MarkMLl

[westfw]

as far as I understand the PL / I examples need to call external functions from libraries to access a single byte. Digging deeper into the reason showed that IO instructions on some machines were only able to access 36 bits

It must be a particularly ancient PL/1 book!  By the time PL/1 was catching on, IBM Mainframes were pretty commonly 32bit machines with byte addressability.

That said, it WAS an age where you couldn't count on byte addressability or 8bit bytes, and "text" wasn't necessarily 8bit bytes either, so using a subroutine was pretty much the only really safe way to access "single bytes" in a portable manner.  DEC PDP10s (my favorite system of those days, although I don't know if there was ever a PL/1 for them) had 36bit words and special instructions for dealing with "bytes" that allowed any byte size from 1 to 36.   Text was usually sixbit (6 bytes/word) or ascii (5 bytes/word), and the people who wrote the C compiler for it had a hell of a time dealing with C's assumption that byte pointers and int pointers looked the same and etc.

(and don't forget that CPUs as recent as x86 and AVR "need" special handling to access "IO space.")

[DiTBho]

It must be a particularly ancient PL/1 book!

This book was printed in 1969, probably with older examples.

[westfw]

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!)

[westfw]

> it was printed in 1977  [original post]
> This book was printed in 1969 [more recently]

Are we talking about two books?  In 1969, it couldn't have been written in troff on a unix system, could it?

I have my doubts about books that are that old, other than their historical interest.
I audited an online "algorithms and data structures" class relatively recently, and was "Why didn't they teach me this stuff back in my (~1978) DS&A class?"  A bit of research showed that some of those algorithms just didn't exist back then (and certainly not when the textbooks for those classes were written.)  For instance, the paper defining Red-Black trees was published in 1978, with significant contributions occurring as late as the 2008...

[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.