6 ms·
I have not used COBOL for 30 years but the language deserves respect. The transition from assembler to COBOL was one of the biggest productivity improvements in
by hodgesrm 9y ago
I have not used COBOL for 30 years but the language deserves respect. The transition from assembler to COBOL was one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s.
COBOL is still pretty efficient for tasks like scanning data on magnetic tapes--not that most of us do that any more. In fact it was pretty good for any problem that involved reading from or writing to storage devices because you could control the data layouts very precisely. It was great on reports for the same reason. I even wrote a simple doc markdown processor in COBOL because the place I worked didn't have usable word processors and we needed something to do pagination and formatting of docs.
I don't miss the verbosity or the lack of modularity but on the other hand COBOL was an effective tool that you could use to solve problems more quickly than other tools available at the time.
- colejohnson66 9y ago> because you could control the data layouts very precisely You can do that in assembly too
- cholantesh 9y agoBut it is undoubtedly more efficient to do so in COBOL.
- lithos 9y agoCOBOL is well described as the language for regular expressions over tables.
- colejohnson66 9y agoAh. I’ve been downvoted... Guess I should’ve been more clear. I was referencing how the OP said COBOL was easier for data layouts. So, not really knowing COBOL, I was asking why. Poor wording.
- unoti 9y agoThe feature we’re talking about here is an easy to use version of doing memory layouts like you’d do with C structs and unions. And combined in with that is automatic number formatting. And all of it uses a clean concise layout that’s self documenting.
- waltman 9y agoCOBOL structures are better for fixed-length strings than C structs are because C really prefers strings do be null terminated. In C you've got to specify the length of each string, whereas in COBOL the compiler takes care of that for you.
- kazinator 9y agoI can even do that better in Lisp over C structs. In my own home-grown dialect. Suppose we have struct foo { int count; char name[16]; /* not null terminated! */ }; REPL: define an alias name foo for the type with typedef: 1> (typedef foo (struct foo (count int) (name (array 16 char)))) #<ffi-type (struct foo (count int) (name (array 16 char)))> Now put an instance of the Lisp struct into a binary buffer using this FFI type: 2> (ffi-put #S(foo count 42 name "ABCDABCDABCDABCD") (ffi foo)) #b'2a00000041424344 4142434441424344 41424344' Now, recover a new Lisp struct instance from this binary struct: 3> (ffi-get *2 (ffi foo)) #S(foo count 42 name "ABCDABCDABCDABCD") No problem; the FFI type system knows that an "array of char" is different from a null terminated string, and can make it correspond to a Lisp string in both directions. Now, for fun, let's poke a zero byte into that buffer: 4> (set [*2 8] 0) 0 5> *2 #b'2a00000041424344 0042434441424344 41424344' There it is. Now decode: 6> (ffi-get *2 (ffi foo)) #S(foo count 42 name "ABCD\xDC00;BCDABCDABCD") What's that? My UTF-8 decoder treats the 00 as an invalid byte, and maps it into the surrogate pair range U+DCXX. The otherwise optional semicolon was output because the next character in the string is a hex digit. If that U+DC00 is encoded back, it will reproduce the null byte: 7> (ffi-put *6 (ffi foo)) #b'2a00000041424344 0042434441424344 41424344'
- khedoros1 9y agoCOBOL's data types look like they're well-suited to storing fixed-width, hierarchical data, with the format of the data being specified in the data type. The numerical types are oriented toward fixed-point decimal, with explicitly specified levels of precision. Two variables holding common license plate formats might look like this: 01 LIC-PLATE1 PIC 9A(3)9(3) VALUE '1ABC234'. 01 LIC-PLATE2 PIC 9(3)A(3). VALUE '123ABC'. [edit: added a newline to separate my examples] ("9" specifies a numerical digit, "A" specifies an alphabetic character, and there are other types that deal with sign, explicit and implicit decimal points, etc). Assembly deals with memory layouts, but doesn't enforce any kind of higher-level data type, and especially not a human-oriented data specification.
- dontlikeitupem 9y agoThe best thing about COBOL is the distinct lack of hipster coders or frameworks. I worked on various COBOL code bases over the years, and they were always approachable, if a little long-winded. My cheques still process via COBOL code a friend's grandmother wrote and still runs on emulated Unisys hardware.
- goatlover 9y ago> one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s. If languages like Smalltalk, APL and Lisp aren't counted, then sure, Java was big productivity boost in the history of programming.
- kiriakasis 9y agoI think that the reach of a language need to be considered, as influential and lovable those language might be most of the effect they had was by influencing other languages.
- gumby 9y agoThere's nothing wrong with that. Algol heavily influenced the design of scheme, but I've never seen an Algol program in the wild. That doesn't mean it wasn't influential. Einstein got the Nobel for the photoelectric effect, which we take advantage of continuously every day. I'd say that was influential.
- Chathamization 9y agoFortran's older and Lisp is as old (it can be argued about whether COBOL or Lisp are older). Fortran and Lisp seem to have held up much better. ALGOL is another contemporary, and arguably the one that has the biggest impact on popular languages.
- hodgesrm 9y agoJust a note on FORTRAN (which I also used for about a decade) vs. COBOL. It's important to remember that FORTRAN could not deal easily with character data until FORTRAN-77 which introduced the CHARACTER type. Prior to that you stored character data in arrays of 4-byte words, INTs if I recall correctly. It was really painful to use for data manipulation and reports which were among the main forms of output at the time. I'm also a big FORTRAN fan, especially the VAX-FORTRAN variant DEC introduced in the 1980s. It was great for numerical analysis but also included library calls to access the operating system, much like C. Some of us were late to the Unix party, so this was a huge step forward.