Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Saturday May 16 2020, @02:39AM   Printer-friendly
from the near-the-root-of-the-programming-language-tree dept.

ALGOL 60 at 60: The Greatest Computer Language You've (Probably) Never Used:

2020 marks 60 years since ALGOL 60 laid the groundwork for a multitude of computer languages.

The Register spoke to The National Museum of Computing's Peter Onion and Andrew Herbert to learn a bit more about the good old days of punch tapes.

ALGOL 60 was the successor to ALGOL 58, which debuted in 1958. ALGOL 58 had introduced the concept of code blocks (replete with begin and end delimiting pairs), but ALGOL 60 took these starting points of structured programming and ran with them, giving rise to familiar faces such as Pascal and C, as well as the likes of B and Simula.

"In the 1950s most code was originally written in machine code or assembly code," said Herbert, former director of Microsoft Research in Cambridge, with every computer having its own particular twist on things.

[..] "Fortran," said Herbert, "emerged as the first real programming language for scientific and numeric work. That convinced people that having higher-level languages (as they called them then – they were pretty primitive by modern standards) made programmers more productive."

[...] "And a bunch of people thought you could do better."

[...] One group started on the design of what was then called an "Algorithmic Language": a language for writing algorithms. The output, in 1958, described the language "ALGOL 58". However, as engineers began to create compilers for the new system, they found "all kinds of things hadn't really been thought about or worked through properly," recalled Herbert.

[...] Eventually, Herbert told us, "they published the ALGOL 60 report, which is the baseline that everyone then worked to."

[...] "People were sorting out some of the things that we now take for granted like ideas in structured programming, data structures, data types," he added.

[...] Alas, those seeking a handy-dandy "HELLO WORLD" example will be disappointed. The Achilles' heel of the language that would go on to inspire so many others was that it lacked standard input/output capabilities.

[...] Oh dear. The omission pretty much did for vendor independence as manufacturers naturally went their own way, leaving large chunks of code incompatible between systems. There were also elements of ALGOL 60 that were open to interpretation, leaving it a little compromised from the start.

While ALGOL ploughed its furrow, Fortran continued to be developed in parallel. "People in the Fortran world," explained Herbert, "saw ideas in ALGOL they quite liked and brought them across." As the decades passed, Fortran remained the centre of gravity for scientific computing while ALGOL became more of an academic language, used for teaching computer science ideas.

[...] The story of ALGOL 60 is not so much of the language's eventual fate, but also of those that it inspired. ALGOL W, based on a proposal for ALGOL X, by Niklaus Wirth and QuickSort creator Tony Hoare would go on to inspire Wirth's Pascal and Modula-2. Pascal's influence continues to be felt today.

ALGOL 60 also heavily influenced the Combined Programming Language (CPL), developed in the 1960s but not implemented until the following decade. CPL in turn led to Basic CPL (BCPL), from which B descended. The B language was further developed to become C.

[...] As for taking the ALGOL 60 itself out for a spin today, there are a few options for those not fortunate enough to have an Elliott 803 or 903 to hand. MARST will translate ALGOL 60 to C or one can get a feel for the whole 803 experience via a simulator.

This humble scribe did not have occasion to use ALGOL, but did spent the better part of two years programming PASCAL professionally. At a time when it seemed all other languages had a limited — and finite — set of data types, PASCAL was different. It encouraged the creation of whatever data types and data structures that best matched the task at a hand.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 1, Informative) by Anonymous Coward on Saturday May 16 2020, @02:46AM

    by Anonymous Coward on Saturday May 16 2020, @02:46AM (#994852)

    They've been using Algol since the days of the B5000

  • (Score: 5, Interesting) by HiThere on Saturday May 16 2020, @03:41AM (5 children)

    by HiThere (866) Subscriber Badge on Saturday May 16 2020, @03:41AM (#994868) Journal

    Algol was the ancestor of a huge number of modern languages, and it was the first language I used that had as a feature that I/O must be done via a library, it wasn't part of the language. IIRC, it got something about the scope wrong in nested scopes that I was always needing to work around. One of my classes used Algol rather than Fortran. It was a very interesting language, and had lots of nice features...but it didn't work well with an IBM 026 keypunch. Perhaps if we'd had an 029... Partially it was the same problem APL had later, only less extreme. The implementation we used compiled to a reverse polish assembler code for a pseudo machine. We called it an interpreter, but it was really compiled in the same sense that Python is. This made debugging interesting, as we often needed to get down to that level to figure out what was happening. Later I did the same things with Fortran (only to actual op codes, of course), and that was a lot less interesting. I was glad when we stopped needing to do that.

    I don't think I ever found a bug in the Algol compiler. I found one once in the Fortran compiler, where 0 (the literal number) was being treated as a variable, so when I made a typo and accidentally set it to something, there were problems that seemed totally unrelated to the real problem.

    --
    Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
    • (Score: 2) by maxwell demon on Saturday May 16 2020, @08:21AM (4 children)

      by maxwell demon (1608) on Saturday May 16 2020, @08:21AM (#994921) Journal

      I guess you passed the literal 0 to a function argument that the function modified. In that case, it wasn't a bug in the compiler, but you invoking undefined behaviour.

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 1, Informative) by Anonymous Coward on Saturday May 16 2020, @01:06PM

        by Anonymous Coward on Saturday May 16 2020, @01:06PM (#994970)

        I guess you're an idiot that doesn't know that was a famous bug with FORTRAN compilers.

      • (Score: 0) by Anonymous Coward on Saturday May 16 2020, @04:02PM

        by Anonymous Coward on Saturday May 16 2020, @04:02PM (#995020)

        Sometimes you can blame users for doing stupid things, but other times (such as in this one) allowing the user to do something SO stupid is where the blame lies.

      • (Score: 2) by HiThere on Saturday May 16 2020, @04:11PM (1 child)

        by HiThere (866) Subscriber Badge on Saturday May 16 2020, @04:11PM (#995023) Journal

        Nope. The typo was in a do loop header. I never did figure out how the compiler made any sense out of it, but it parsed something like "DO 0 = 1 20" as an assignment to 0. That was a seriously garbled sentence that should have read something like "DO 10 I = 1, 20", and it should have been flagged as an error. Instead, however, it assigned 0 the value of 120. Or possibly 1, I forget the details. The alternate FORTRAN compiler caught the problem.

        --
        Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
  • (Score: 2) by legont on Saturday May 16 2020, @04:24AM

    by legont (4179) on Saturday May 16 2020, @04:24AM (#994877)

    It was the main language I used at school when learning computer science. I also participated in ALGOL 68 compiler development.

    --
    "Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
  • (Score: 3, Interesting) by mendax on Saturday May 16 2020, @05:39AM (5 children)

    by mendax (2840) on Saturday May 16 2020, @05:39AM (#994888)

    SYMPL [wikipedia.org] was a flavor of ALGOL used on some Control Data mainframes of the 1970's and 1980's to write compilers and other sophisticated utility programs. (It actually was a derivative of JOVIAL [wikipedia.org] which was itself a derivative of ALGOL). To those mainframes it served much the same purpose as C/C++ does to today's machines. I learned it and had a great deal of fun with it when writing my own little projects when I was in school. It was as close to assembly one could get on the machine in a high-level language. As I recall, one of the unique features it had was some sophisticated bit manipulation capabilities built into the language that eliminated the ANDing and ORing and bit shifting required in C/C++.

    Actually someone else can write something about how important JOVIAL was in the scheme of things in the past. It was an important language in the world of national defense contracts.

    --
    It's really quite a simple choice: Life, Death, or Los Angeles.
    • (Score: 3, Interesting) by istartedi on Saturday May 16 2020, @07:34AM (3 children)

      by istartedi (123) on Saturday May 16 2020, @07:34AM (#994913) Journal

      OK, I'm intrigued. What could a language have that would make me never want to use AND and OR, bitwise or logically? It sounds like the equivalent of saying "sophisticated math that eliminated multiplication and adding". ANDing and ORing are so fundamental, I literally can't imagine what you'd replace them with. I'm guessing that maybe what you really mean is that it had a rich library of bitwise functions so that you wouldn't have to write them from scratch? They'd still have to be built on ANDs, ORs and shifts; but I guess if they had enough functions you might never feel the need to use raw ANDs, ORs and shifts. It seems crazy to think that those wouldn't be in the language though, even if only as primitives upon which the sophisticated built-in functions were built.

      --
      Appended to the end of comments you post. Max: 120 chars.
      • (Score: 3, Insightful) by maxwell demon on Saturday May 16 2020, @08:38AM (2 children)

        by maxwell demon (1608) on Saturday May 16 2020, @08:38AM (#994923) Journal

        What could a language have that would make me never want to use AND and OR, bitwise or logically?

        The OP only specified bitwise operations; I'm sure he'd use logical and/or in those languages; avoiding those indeed would be odd.

        They'd still have to be built on ANDs, ORs and shifts

        And if/for/while still internally build on goto. What happens internally is only of theoretical interest. You wouldn't say you use goto when you write a for loop.

        A lot of the anding/oring/bit shifting done in C is for bit field manipulation. I don't know about the languages mentioned by the OP, but I know Pascal had the set type for this sort of thing.

        Note that original Pascal did not have those bitwise and/or operations at all; Turbo Pascal did have them, but I don't remember ever using them in the time when I wrote Turbo Pascal programs. I can't say for sure that I never used them, but at least it was sufficiently rare that I can't recall it. I did use Pascal set types, and of course I used Pascal's logical and/or operators.

        --
        The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 1) by istartedi on Saturday May 16 2020, @04:59PM (1 child)

          by istartedi (123) on Saturday May 16 2020, @04:59PM (#995043) Journal

          Well, I'm glad that I didn't write my graphics engine in original Pascal, back when I used to experiment with that sort of thing (80s to mid 90s). Nowadays the graphics engines are all abstracted so I guess you could toss bitwise operations out the window, at least for that application. Sets and gets in bitfields or some other abstraction could synthesize the original bitwise operations, but you'd be counting on them to optimize it for you.

          I get your point about GOTOs. I'm glad that one's been abstracted away; but you can have my bitwise operations when you pry them from my cold dead hands, LOL.

          --
          Appended to the end of comments you post. Max: 120 chars.
          • (Score: 2) by maxwell demon on Sunday May 17 2020, @08:33AM

            by maxwell demon (1608) on Sunday May 17 2020, @08:33AM (#995281) Journal

            I don't know if the original Pascal was ever implemented on a system with graphics abilities. Standard Pascal implementations were exceptionally rare; almost every implementation deviated in significant ways. In particular, useful but missing functionality was always added. For example, standard Pascal has terrible string handling (yes, worse even than C). But about every Pascal implementation added proper string handling.

            Note also that what I wrote refers to the original Pascal standard. There was also an Extended Pascal standard which had far more features (including bitwise operators), but to my knowledge the only Pascal compiler that ever implemented it was gpc.

            Anyway, as I said, in Turbo Pascal there were definitely bit-wise and/or/not, as well as shifts (the latter were useful even in non-low-level programs, as a faster way to multiply/divide by powers of 2). So you could have implemented your graphics engine there (OTOH Turbo Pascal had a graphics library as part of the installation, so maybe you wouldn't have had the need to begin with).

            Anyway, I think there's a confusion on your side about the set type: It has absolutely nothing to do with setters/getters.

            For example, a one byte large type with bit-level access could be specified as

            type BinaryByte = set of 0..7;
            <ecode>
            To set a variable of that type it to a certain bit pattern, you'd just enumerate the bits to be set:
            <ecode>
            primes := [2,3,5,7];

            You can also set or clear individual bits:

            flags := flags + [3,5]; { set bits 3 and 5 }
            flags := flags - [SpecialFlag]; { clear SpecialFlag, which must be a constant or variable with value in the correct range }

            However there were no bit shifts on that type, so it might not have been suitable for your graphics engine. But then, Pascal was originally meant as teaching language, and any implementation targeted at actual software development did support the bitwise operators anyway. It's just that for most of the uses that you'd use them in C, Pascal already had a proper abstraction to offer. But sure, if you do truly low-level stuff (and a graphics engine is definitely low-level stuff), you need access to low-level functionality. It's just that the majority of code written isn't for low-level stuff (or else almost nobody would ever have programmed in Java, Perl or Python), and in a language not meant for low-level functionality development it is absolutely no problem if the corresponding low-level functionality is missing. If you write low-level stuff in a language not designed for it, you're simply using the wrong language to begin with.

            --
            The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 3, Informative) by hendrikboom on Saturday May 16 2020, @05:54PM

      by hendrikboom (1125) Subscriber Badge on Saturday May 16 2020, @05:54PM (#995075) Homepage Journal

      CDC's Algol 68 compiler was written in SYMPL, and used a fair amount of SYMPL's code generator.

  • (Score: 3, Informative) by hendrikboom on Saturday May 16 2020, @04:49PM

    by hendrikboom (1125) Subscriber Badge on Saturday May 16 2020, @04:49PM (#995040) Homepage Journal

    Those who want to try it have a present-day option.
    Go get an implementation of Racket (allegedly a dialect of Scheme, but it's more than that.)
    Give it an Algol 60 program by prefixing it with the line:
            #lang algol60
    Racket allows you to specify the language the program is written in on the first line. The Racket system implements quite a few languages compatibly.

    Racket is available on Mac, Linux, and Windows. You don't have to buy a 40-yesr-old machine to try it.

    -- hendrik

  • (Score: 2) by hendrikboom on Saturday May 16 2020, @06:00PM (2 children)

    by hendrikboom (1125) Subscriber Badge on Saturday May 16 2020, @06:00PM (#995081) Homepage Journal

    I read the first 10 Algol Bulletins, which contain some of the deliberations while they were puttinig Algol 60 together.

    How they invented block structure with local and global variables?

    It started out as a generalization of Fortran's COMMON storage!

    Step One was eliminating problems with declaring COMMON variables differently in different functions by letting them be declared only once, and outside the functions.

    You can guess the rest.

    • (Score: 2) by maxwell demon on Sunday May 17 2020, @08:42AM (1 child)

      by maxwell demon (1608) on Sunday May 17 2020, @08:42AM (#995282) Journal

      Yeah, FORTRANS's COMMON blocks got a worse reputation than they deserved. Their main problem was the missing type safety, but that problem was shared by everything passed between functions in FORTRAN.

      But COMMON blocks were superior to global variables in one important respect: You only had to look at the single function's declarations to know exactly what the function could modify (note that since FORTRAN also didn't have pointers, you couldn't change anything else through indirection).

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 2) by hendrikboom on Sunday May 17 2020, @08:54PM

        by hendrikboom (1125) Subscriber Badge on Sunday May 17 2020, @08:54PM (#995457) Homepage Journal

        The problem with COMMON blocks is that you had to repeat the declarations identically in each function.
        If you got them wrong in one function, the code looked fine, but that function would be reading and writing variables in the common block that were not the ones evidently named in the function.

        Locality without glitches of this sort weren't really solved until we got languages with module syntax, explicit imports and exports, and some kind of link-time or run-time check that the imports and exports matched up properly.

        -- hendrik

(1)