5 ms·
Note: I'm getting some hate from others who think I would pick or prefer COBOL over a modern language. I wouldn't. I was making an outside-the-box "devil's advo
by palisade 2y ago
Note: I'm getting some hate from others who think I would pick or prefer COBOL over a modern language. I wouldn't. I was making an outside-the-box "devil's advocate" objective observation. I just wanted to preface that here. Okay, the rest of my original comment remains below:
The irony is that we already had a memory safe and stable language in Cobol that was easier to read and understand than Rust. But, no one wants to use it so it is "dead" but it runs everything that made the modern age possible.
RUST:
println!("Enter number: ");
let mut input_string = String::new();
io::stdin().read_line(&mut input_string).unwrap();
let number: i32 = input_string.trim().parse().expect("Please enter a valid number.");
let result = if number % 2 == 0 {
"EVEN"
} else {
"ODD"
};
println!("The number: {}", result);
COBOL:
display 'Enter number: '
accept number
if function mod(number,2) = 0
move 'even' to result
else
move 'odd' to result
end-if
display 'The number: ',result
- sestep 2y agoThis is a weird take. Sure, plenty of cool/nice things from old languages (e.g. variable-sized stack frames in Ada) get lost, and some then get rediscovered by future languages, potentially wasting effort. And I don't know COBOL, so maybe you're actually making a good point. But I find that hard to believe. Does COBOL really solve all the same problems Rust is intended to solve? Is it as performant? Can it interface with native code from other languages in the same way? Does it have a usable and sane package manager built on top of a module system that facilitates composability and backward compatibility? Does it have a way to describe the shape of data and errors as ergonomically as Rust's algebraic data types? Genuinely curious: as I said, I don't know COBOL. I'd find it extremely surprising if the answers to all these questions are "yes," though. Just as there are reasons COBOL is still used, there are also (good) reasons new languages have been created.
- Muromec 2y agoImagine having a shell script being called from a cron job that writes data in a bunch of tab separated memory mapped files (memory mapping happens when you configure the thing), but you have more files than memory. And all the shell scripts call and include each other and have global variables too. And that underpins most of the critical infrastructure in your country.
- User23 2y agoExcept mainframe IO and interrupts actually work reliably. Unix on the other hand is a proud member of the worse is better club. It still doesn’t really handle interrupts correctly, but thanks to 40 years of kludges most people consider it close enough.
- palisade 2y agoA lot to unpack in this question. Do they solve all the same problems? No, for example COBOL lacks a modern concept of concurrency within a single program. COBOL's concurrency features are based on task-level parallelism, which involves dividing a program into multiple tasks that can be executed concurrently. Is it performant? Yes. COBOL is highly efficient particularly in handling large datasets and complex business logic and its compilers are optimized for reliability and speed. Can it interface with native code? Yes. Does it have a package manager? No. Does it describe shape of data? No. Data structures in COBOL are defined using fixed-length records. Note: I'm not a COBOL expert. I did learn it in college, though.
- Muromec 2y agoShell script is memory safe too, but you don't write anything longer than 100 lines in it for a reason.
- palisade 2y agoWhen you bank, COBOL (40% of online banks). When you use the ATM, COBOL (95% of ATM transactions). When you travel, COBOL (96% of airline ticket bookings). Healthcare, COBOL. Social Security, COBOL. Point of Sale, COBOL. IRS, COBOL. Pension funds? COBOL. Hotel bookings? COBOL. Payroll programs? COBOL. It is estimated that there is 800 billion lines of COBOL code in production systems in daily use. That is a bit more than 100 lines. This was why Y2K genuinely scared everyone and was a very real problem. The only reason we can look back at it and laugh now is that an army of engineers sat down and rewrote it all in the nick of time.
- arcticbull 2y agoLegacy code yeah, nobody's hitting File > New Project in COBOL It's just that nobody understands how the systems work and they're ossified. Those systems are going to be emulated until our grandchildren take over because nobody can understand them well enough to craft a replacement. Juuuust up until an LLM rewrites them for us. [edit] I mean those airlines systems are so old that they don't support special characters on names, passenger names are two fixed-length fields (first name, last name) and title and middle name just gets appended together. So you get LASTNAME/FIRSTNAMEMIDDLENAMENTITLE on your bookings. And each of those fields is truncated lol. and of course flight numbers are fixed at 4 digits, so we're running out of those. Not exactly a great ad.
- palisade 2y agoOof, I've got good news and bad news for you.... they still are creating new code in it. Yeah, there are fewer engineers in COBOL which is why it pays BIG bucks now. They desperately need someone to maintain that massive infrastructure that has been built up over 75 years that cannot be replaced easily or quickly.
- hollerith 2y agoBizarre comment. No developer who should be allowed anywhere near a computer would ever consider choosing COBOL where Rust is appropriate or vice versa.
- palisade 2y agoWell, I said it was ironic that we went out of our way to make a newer more complicated to read language that was memory safe when we already had a language that was simpler and readable that was safe. I didn't say I wanted to code in it, though. I'd prefer in no particular order Kotlin, Python, Go, C++, Rust, Perl, C#, Java, Zig, etc. Anything really over COBOL myself. I'm part of the problem. But, if I was hard up for money and wasn't getting nibbles for jobs? I could see getting into COBOL because there is a lot of money in it and always work available. My statement stands though, we need to do better when designing the syntax of our languages. Cobol is disliked, yet simple and readable. What does that say about our new languages. How hated are our "new" language remnants going to be when few of us are longer around to maintain them 50 - 75 years from now? And, how easy are they going to be to pick up? Addendum: I guess it won't matter if the singularity comes and just writes it all for us, of course. Then it will all just be machine code and we won't need these "only human" translation layers any longer.
- strken 2y agoIs COBOL actually memory safe in the same way Rust is memory safe? I thought it was just "we don't allow dynamic allocation", and I'd assume programmers often implement their own half-baked dynamic allocation on top.
- rightbyte 2y agoJust like Rust the 'use after free' problem becomes the 'use after it does not make sense' problem instead. Which Valgrind wont find for you either. I think new Cobol has 'allocate' and 'free' though.
- 7thaccount 2y agoI don't think the use cases for Cobol (bank software) typically overlap with those for Rust (operating systems...etc). It's like saying no gardener should be allowed near a garden that would choose a shovel over a pair of shears. Both have a place.
- kibwen 2y agoIt's a bit odd to say these programs are comparable when the Cobol version isn't handling errors whereas the Rust program is (by panicking, but that's better than the silently wrong behavior of the Cobol one). Here's a runnable version of the above Cobol program (adding the necessary boilerplate); note that it prints "even" for an input of `abc` and "odd" for an input of `12`: identification division. program-id. even-or-odd. data division. working-storage section. 01 num pic 9. 01 result pic x(4). procedure division. display 'Enter number: ' accept num if function mod(num, 2) = 0 move 'even' to result else move 'odd' to result end-if display 'The number: ', result stop run. It's peculiar to call out Rust's syntax specifically when, like most other languages these days, is mostly C-like (though with a sprinkling of OCaml). And syntax aside, Rust and Cobol have wildly different goals, so "just use Cobol" doesn't suffice to obviate Rust's purpose for existing.
- palisade 2y agoGood catch! My cobol is rust-y. :D I guess my post is getting misread as "just use cobol" when it was more of a XKCD-like reflection; e.g. why did we all do that / keep doing that. We done did Cobol, and Rust. And, one is "dead" but not really and now here we are. https://xkcd.com/927/ https://xkcd.com/927/
- erik_seaberg 2y agoSorry, https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-example-allocate-free-storage-unbounded-tables https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex... seems to be demonstrating a language that is not memory-safe (maybe it used to be, but how?) COMPUTE SIZE-NEEDED = LENGTH OF OBJ + LENGTH OF VARTAB * NUM-ELEMENTS ALLOCATE SIZE-NEEDED CHARACTERS INITIALIZED RETURNING VPTR SET ADDRESS OF VARGRP TO VPTR MOVE NUM-ELEMENTS TO OBJ MOVE BUFFER(1:SIZE-NEEDED) TO VARGRP SET VPTR TO ADDRESS OF BUFFER FREE VPTR
- palisade 2y agoThe compiler would have rejected that, if I remember correctly. I'm not in the field of cobol myself, I learned it briefly in college ages ago.
- electroly 2y agoWhich part do you think would be rejected? This code is an example from the z/OS COBOL documentation--I'm quite sure it works.
- palisade 2y agoThe heap stuff is new I guess, we didn't have that back when I was writing programs in it. So, yea, not so safe anymore. :D I take back what I said about it being safer then. I can't go back and edit my original post, it's been too long. The compiler did normally warn for data bounds checking, so I figured it would in this case. If that's not the case anymore then I'm wrong.