Comments by "Lawrence D’Oliveiro" (@lawrencedoliveiro9104) on "High Level Languages u0026 the IBM 360 Series - Computerphile" video.

  1. IBM’s excuse for EBCDIC was that ASCII was almost, but not quite ready for prime-time in 1964.
    4
  2. Those IBM mainframes seemed to have amazingly primitive filesystems. Even our little DEC PDP-11s had files that you could grow just by writing to them.
    4
  3. OS/360 (the troubles with which started off The Mythical Man Month ) was written in assembler, but that didn’t stop it being complicated, buggy and slow.
    3
  4.  @mheermance  RISC was very much about turning traditional assumptions on their heads. That’s where a lot of speed came from.
    3
  5. The CDC 6600 was a supercomputer. It could do computations about 50 times faster than anything else around. CDC was actually set up to sell business machines. But they made the mistake of hiring Seymour Cray as their hardware guru, and he just wanted to build the world’s fastest computers. And the company had no real idea how to sell them.
    2
  6. Lack of a hardware-imposed stack is not necessarily a disadvantage. Even POWER/PowerPC does not dedicate any register as a stack pointer; that is purely an ABI convention. And that’s about as modern an architecture as they come.
    2
  7.  @mheermance  On PowerPC Apple Macs, R1 was dedicated as the stack pointer. I think this might have been IBM’s usage as well.
    2
  8.  @mheermance  There’s even a note in the PowerPC documentation that load-with-update (i.e. stack pop) might be slower than doing separate load and add-to-stack-pointer-register instructions.
    2
  9. Ever did any VAX programming?
    1
  10.  @RupertReynolds1962  It had a machine instruction that took a table of coefficients and would compute a polynomial for a given argument.
    1
  11.  @RupertReynolds1962  There were quite a few complex instructions similar to that. They really went to town in terms of making assembly language look higher-level than FORTRAN in many ways. Much of it turned out to be pointless when it was discovered that these complex instructions were slower than doing the individual steps using a longer sequence of simpler instructions.
    1
  12. Single-level storage was pioneered in the ATLAS project, about two decades earlier. Also a feature of MULTICS.
    1
  13. To go with complex numbers, Python has the cmath module, which is the equivalent of the math module but for the complex domain. Python tends to be my first resort for many things right now -- it has about all the high-level features you could want (e.g. functions and classes as first-class objects), short of turning completely into LI
    1
  14. SP. I agree using indentation for block structuring turns out to be a mistake;
    1
  15. I mitigate it a bit by having “#
    1
  16. end” comments to mark the ends of compound statements.
    1
  17. I also have custom commands in Emacs to jump between lines with matching indentation, which nicely lets me navigate between the matching beginnings and endings of compound statements.
    1
  18. The trouble with FORTH is it’s such a crummy language model. Even PostScript is better than that.
    1
  19.  @aleksandersabak  You like PostScript? Both its graphics model and the language are antiquated, but both can be improved.
    1
  20.  @aleksandersabak  No idea what you mean by “concatenative”. If you want to understand the difference between FORTH and PostScript, start by contemplating you forth love if honk then versus you postscript love {honk} if
    1
  21. The idea of an instruction set implementable across such a wide range of hardware capability was groundbreaking. The software side, not so much. IBM never really got used to the idea of timesharing (not until it adopted Unix in the form of AIX, anyway). Much nimbler competitors like DEC, DG et al ran rings around it in this area, during the 1960s and 1970s.
    1
  22.  @Richardincancale  CP/M was originally cross-developed from a DEC PDP-10 machine running TOPS-10. That’s where its inspiration came from, not IBM mainframes.
    1
  23.  @Richardincancale  The idea of
    1
  24. put
    1
  25. pu
    1
  26. tting a
    1
  27. do
    1
  28. t between the filename and the extension was not,
    1
  29. I think, something done in any IBM mainframe OS. Whereas it was characteristic of DEC operating systems.
    1
  30. Pu
    1
  31. tting a colon on the end of the device name was another DEC-ism. Only DEC systems had multicharacter device names; pity CP/M (and Microsoft) never copied that ...
    1