4 ms·

I'm not in the hate COBOL camp, COBOL is very good at what it does, when I finally got exposure to system z and COBOL, I was astounded at how easy it was to wor

by Aloha 5y ago

I'm not in the hate COBOL camp, COBOL is very good at what it does, when I finally got exposure to system z and COBOL, I was astounded at how easy it was to work with record data there. It's something that's several orders of magnitude harder to do in the Unix world with its "bag of bytes" data paradigm. Everything that originated in the Unix world is really designed for that data model, and is really just a different way of thinking.

skissane 5y ago
I don't hate COBOL either. And you are right, there are some positive aspects of COBOL, including some of the data modelling ideas in the DATA DIVISION. However, I think if you look at PL/I, you'll find most of the same ideas present, but on the whole it is a nicer language. Some people hate PL/I too, and no doubt it can be overcomplicated (which is part of why PL/I subsets were so popular in the 1970s and early 1980s), but I think PL/I has most of COBOL's strengths with fewer of COBOL's weaknesses.
- Aloha 5y ago
  I think of PL/I as a systems programming language, and COBOL as an application programming language, much in the same way you'd look at C/C++ and Java in the Unix world, I think (I think that analogy is actually almost directly applicable, though maybe Pascal is a closer fit? I'm not sure). Different tools designed to do different things. I'd actually like to learn PL/I (or COBOL beyond a cursory knowledge), I'm someone who has a great deal of knowledge of the thought patterns of programming (as well as how you architect software, systems design, etc), without knowing any one tool well, I tend to learn a tool for a task, then forget the tool when I no longer require it anymore. My job is.. hard to explain, but its quasi programming, but also very much not aside from helper scripts I write now and again (I use all of the thought patterns of programming, without any of the tools). I enjoy writing software, but only have so many itches to scratch in my personal time.
  - skissane 5y ago
    > I think of PL/I as a systems programming language, and COBOL as an application programming language, much in the same way you'd look at C/C++ and Java in the Unix world, I think PL/I is a general purpose applications programming language. Its primary design goal was to unify COBOL, FORTRAN and ALGOL into a single language, and as such was intended to meet the needs of both business and scientific application programmers. IBM invested heavily in trying to convince business software developers to move from COBOL to PL/I - see for example [0] - but, while there was a decent amount of business software development done using PL/I in the 1970s, it never had the success in that market which IBM had hoped for, PL/I ended up being an also-ran to COBOL instead of what it was meant to be, the successor. PL/I proper was generally not used as a systems programming language. On the one hand, it had a number of features (decimal arithmetic, formatted and record IO and multithreading support built-in to the language syntax) which while useful in applications programming were unavailable or unsupportable or not useful in systems programming. On the other hand, a lot of features which are valuable in systems programming - such as inline assembly, the ability to manually control the allocation of variables to machine registers - are not in PL/I proper. Given this, it was common to create systems programming dialects of PL/I which removed those application-centric features and added systems programming specific features. But those dialects were not properly speaking PL/I and were often called by other names - IBM’s was called BSL, later renamed to PL/S, which spawned a bunch of descendants with similar names (PL/AS, PL/X, PL/DS, PL/MI, PL/MP, PL.8). Honeywell had PL/6 which was used as the systems programming language for its CP-6 operating system (a backward compatible rewrite of Xerox CP-V). Prime Computer had PL/P as the systems programming language for PRIMOS. Gary Kildall developed PL/M in which he wrote the first versions of CP/M (later versions were rewritten in assembly to get better performance, but even in later versions PL/M was still used to implement some of the utilities.) However, none of these systems programming languages were in the strictest sense PL/I; the original unmodified PL/I (without subsetting or supersetting) was an applications programming language not a systems programming language. [0] http://bitsavers.org/pdf/ibm/360/pli/SC20-1651-1_A_Guide_to_PL_I_for_Commercial_Programmers_Apr68.pdf http://bitsavers.org/pdf/ibm/360/pli/SC20-1651-1_A_Guide_to_...
    - Aloha 5y ago
inkyoto 5y ago
> I was astounded at how easy it was to work with record data there. It's something that's several orders of magnitude harder to do in the Unix world with its "bag of bytes" data paradigm. Hear, hear. I started out in the block and record-oriented I/O world, and quickly found that being unable to make a quick use of highly advanced I/O system calls to be frustrating – for simple tasks. One had to define the record structure, typically in MACRO-11/MACRO-32 (we did not use COBOL, anyway), and only then commence the I/O. Record-oriented I/O also comes with its own wealth of quirks, e.g. if an application crashes / the OS restarts, the system administrator has to determine which files had not closed and manually close each of them off after the crash / system restart. Applications would refuse to start up if the files they operated on had not been properly closed. Blimey. Direct device I/O was even more complex. Even the block I/O wasn't as trivial to use, especially for the simple text processing as the system did not keep the used bytes counter for the last file's disk block; the app would have to read all the blocks in and then either search for a special control character that indicated the end of the text or at least one text editor reserved the very last word of the last file's disk block as the total file character counter. Wash, rinse and repeat. All in all, as soon as I could get a hold of access to a UNIX box, I ran away screaming. UNIX shifts the disk I/O complexity into the application layer (user space) and raw devices (user space + VMM bypass in the kernel space). Want to implement a record-oriented I/O? Write a user space application for it. Want to implement a high performant, record-oriented I/O? Use a raw device (Oracle absolutely wanted to give exclusive access to such one, and it was very fast for its time). That has yielded a highly successful cottage industry of databases, relational and record-oriented ones (e.g. BerkelyDB). Looking back, I have come to appreciate the record-oriented I/O, and I would love to be able to define my application's record structure in the COBOL-like way in C/Rust/whatever and use that for simple and slightly more complex things. I certainly would not want to have to deal with the complex legacy that comes with it, i.e. seeking out unclosed files after the restart to close them and stuff. For simple one-off things and for talking to simple device drivers, I will take my bag of bytes any moment.
- Aloha 5y ago
  Being able to sort records with their systems tools, was astounding to me as someone who gets unix pretty clearly.

by Aloha 5y ago

skissane 5y ago

I don't hate COBOL either. And you are right, there are some positive aspects of COBOL, including some of the data modelling ideas in the DATA DIVISION. However, I think if you look at PL/I, you'll find most of the same ideas present, but on the whole it is a nicer language. Some people hate PL/I too, and no doubt it can be overcomplicated (which is part of why PL/I subsets were so popular in the 1970s and early 1980s), but I think PL/I has most of COBOL's strengths with fewer of COBOL's weaknesses.

Aloha 5y ago
I think of PL/I as a systems programming language, and COBOL as an application programming language, much in the same way you'd look at C/C++ and Java in the Unix world, I think (I think that analogy is actually almost directly applicable, though maybe Pascal is a closer fit? I'm not sure). Different tools designed to do different things. I'd actually like to learn PL/I (or COBOL beyond a cursory knowledge), I'm someone who has a great deal of knowledge of the thought patterns of programming (as well as how you architect software, systems design, etc), without knowing any one tool well, I tend to learn a tool for a task, then forget the tool when I no longer require it anymore. My job is.. hard to explain, but its quasi programming, but also very much not aside from helper scripts I write now and again (I use all of the thought patterns of programming, without any of the tools). I enjoy writing software, but only have so many itches to scratch in my personal time.
- skissane 5y ago
  > I think of PL/I as a systems programming language, and COBOL as an application programming language, much in the same way you'd look at C/C++ and Java in the Unix world, I think PL/I is a general purpose applications programming language. Its primary design goal was to unify COBOL, FORTRAN and ALGOL into a single language, and as such was intended to meet the needs of both business and scientific application programmers. IBM invested heavily in trying to convince business software developers to move from COBOL to PL/I - see for example [0] - but, while there was a decent amount of business software development done using PL/I in the 1970s, it never had the success in that market which IBM had hoped for, PL/I ended up being an also-ran to COBOL instead of what it was meant to be, the successor. PL/I proper was generally not used as a systems programming language. On the one hand, it had a number of features (decimal arithmetic, formatted and record IO and multithreading support built-in to the language syntax) which while useful in applications programming were unavailable or unsupportable or not useful in systems programming. On the other hand, a lot of features which are valuable in systems programming - such as inline assembly, the ability to manually control the allocation of variables to machine registers - are not in PL/I proper. Given this, it was common to create systems programming dialects of PL/I which removed those application-centric features and added systems programming specific features. But those dialects were not properly speaking PL/I and were often called by other names - IBM’s was called BSL, later renamed to PL/S, which spawned a bunch of descendants with similar names (PL/AS, PL/X, PL/DS, PL/MI, PL/MP, PL.8). Honeywell had PL/6 which was used as the systems programming language for its CP-6 operating system (a backward compatible rewrite of Xerox CP-V). Prime Computer had PL/P as the systems programming language for PRIMOS. Gary Kildall developed PL/M in which he wrote the first versions of CP/M (later versions were rewritten in assembly to get better performance, but even in later versions PL/M was still used to implement some of the utilities.) However, none of these systems programming languages were in the strictest sense PL/I; the original unmodified PL/I (without subsetting or supersetting) was an applications programming language not a systems programming language. [0] http://bitsavers.org/pdf/ibm/360/pli/SC20-1651-1_A_Guide_to_PL_I_for_Commercial_Programmers_Apr68.pdf http://bitsavers.org/pdf/ibm/360/pli/SC20-1651-1_A_Guide_to_...
  - Aloha 5y ago

inkyoto 5y ago

> I was astounded at how easy it was to work with record data there. It's something that's several orders of magnitude harder to do in the Unix world with its "bag of bytes" data paradigm. Hear, hear. I started out in the block and record-oriented I/O world, and quickly found that being unable to make a quick use of highly advanced I/O system calls to be frustrating – for simple tasks. One had to define the record structure, typically in MACRO-11/MACRO-32 (we did not use COBOL, anyway), and only then commence the I/O. Record-oriented I/O also comes with its own wealth of quirks, e.g. if an application crashes / the OS restarts, the system administrator has to determine which files had not closed and manually close each of them off after the crash / system restart. Applications would refuse to start up if the files they operated on had not been properly closed. Blimey. Direct device I/O was even more complex. Even the block I/O wasn't as trivial to use, especially for the simple text processing as the system did not keep the used bytes counter for the last file's disk block; the app would have to read all the blocks in and then either search for a special control character that indicated the end of the text or at least one text editor reserved the very last word of the last file's disk block as the total file character counter. Wash, rinse and repeat. All in all, as soon as I could get a hold of access to a UNIX box, I ran away screaming. UNIX shifts the disk I/O complexity into the application layer (user space) and raw devices (user space + VMM bypass in the kernel space). Want to implement a record-oriented I/O? Write a user space application for it. Want to implement a high performant, record-oriented I/O? Use a raw device (Oracle absolutely wanted to give exclusive access to such one, and it was very fast for its time). That has yielded a highly successful cottage industry of databases, relational and record-oriented ones (e.g. BerkelyDB). Looking back, I have come to appreciate the record-oriented I/O, and I would love to be able to define my application's record structure in the COBOL-like way in C/Rust/whatever and use that for simple and slightly more complex things. I certainly would not want to have to deal with the complex legacy that comes with it, i.e. seeking out unclosed files after the restart to close them and stuff. For simple one-off things and for talking to simple device drivers, I will take my bag of bytes any moment.

Aloha 5y ago
Being able to sort records with their systems tools, was astounding to me as someone who gets unix pretty clearly.