| ▲ | stefanos82 17 hours ago |
| > Then another few decades to rewrite everything. This will never going to happen for obvious reasons; if it ain't broken, don't fix it! Create interoperability with other languages, like what Swift is currently attempting to do, yes; but to completely rewrite an entire project that consists of millions of lines, I don't think so. |
|
| ▲ | pdimitar 17 hours ago | parent | next [-] |
| > if it ain't broken, don't fix it! All the CVEs found in the last several years would like a word with you. |
| |
| ▲ | AnimalMuppet 15 hours ago | parent [-] | | All the code rewrites from the last several decades would like a word in return. A bunch of those rewrites managed to miss critical things that were encoded in the existing logic in non-obvious ways. They broke a bunch of workflows that way. A bunch of others went wildly over-budget and wound up getting shut down before they produced anything usable. But surely the documentation will tell you all the use cases, and the expected inputs and outputs, right? Right? Oh, you don't have documentation like that? Yeah, then it's used in ways you don't know about, and your rewrite is likely to break them. (And that's true even if you do have such documentation, because it's incomplete.) Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not. "But this time we're going to use Rust!" Yeah, but the thing that makes rewrites so hard was never the language, so using Rust isn't going to actually fix it. | | |
| ▲ | pdimitar 2 hours ago | parent | next [-] | | I agree with your take and want to add that "we want less CVEs" and "we want meaningful rewrites" are not necessarily at odds with each other. We can have both. I'll also note that efforts like rewriting a lot of UNIX userland in Rust also introduces the benefits of rewrites -- you have to think super hard if you want that obscure command-line switch that only works in X way if another switch has another value or it does the thing Y if two other switches have these other values. I forgot the examples but that's what happened there: people figured "we will not implement command switches X and Y" and lo and behold, people using those tools never even noticed, myself included. So, rewrites have positives as well. And not everyone doing rewrites is clueless. | | |
| ▲ | AnimalMuppet an hour ago | parent [-] | | I didn't say that those who do rewrites are clueless. I said that rewrites are really hard - far harder than most people expect. That weird switch behavior? I almost guarantee that someone, somwhere, some when depended on that behavior. Either they no longer use the switch behavior or they no longer use the tool, or they just don't use the rewritten version. But how do you know that? In the best case, the code would have a comment: "This code is to simulate Berkeley 3 behavior for users porting from..." But even that doesn't tell you whether anybody today still depends on it. I mean, it could be a valid strategy to not rewrite weird behaviors - any of them - and see what breaks, and then only add the ones that are still needed. The upside is a much cleaner rewrite, with fewer (and, hopefully, better documented) weird behaviors. The downside is that you have to break stuff temporarily to find out. (Hopefully you break it in live staging rather than in production...) |
| |
| ▲ | 8fingerlouie 8 hours ago | parent | prev [-] | | > Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not. This is a major reason why so many financial/healthcare/insurance/government institutions still runs COBOL software on mainframes. Many times, you're looking at what is essentially a monolith (in many parts, but everything is connected in some way) that was 50+ years in the making. Rewriting it is a huge and extremely expensive task, and had it not been because COBOL is considered a "bad language" by the young people, and thereby causing problems with recruitment, i'm guesssing the mainframe would be around for 100+ years to come. As it is now, these companies are forced to migrate away from COBOL, and most companies in the financial sector would probably go for Java, which is posed to becomming the new COBOL. If you start a career today as a young COBOL programmer, you will most likely have a high salary (for your career) for your entire work life. The mainframe is certainly on the way out, but it's a big beast to move, and most "estimates" i hear from financial institutions is that they plan to migrate away in 10-30 years, and predicting what happens in 30 years is kinda pointless. Suffice to say that the Mainframe and COBOL is probably here for another 30-50 years. |
|
|
|
| ▲ | cedws 17 hours ago | parent | prev | next [-] |
| All code has a lifespan, either because it rots or it becomes irrelevant/unneeded. Existing C++ code will gradually expire and the most important pieces will indeed be rewritten, accelerated by shrinking expertise. |
| |
| ▲ | davidcbc 17 hours ago | parent [-] | | This may be technically true on a long enough timeline, but COBOL is still the backbone of the financial sector even though companies have dumped millions into attempting to convert it to something new with limited success. | | |
| ▲ | cedws 17 hours ago | parent | next [-] | | For sure, we can debate the timeline, we can debate what language will replace C++. The way I read stefanos82's reply is that they don't believe C++ code will ever be rewritten, which is obviously not true. COBOL running the financial sector is a myth in my opinion. There are still companies running aspects of their business on it, but calling it the 'backbone' is an overstatement. If you tallied up lines of code by language in the sector, I would wager COBOL makes up less than 1%. | | |
| ▲ | davidcbc 16 hours ago | parent [-] | | The backbone is a minority of the bones in the body too, but without it you're screwed. My previous job was at one of the largest investment companies in the world, if the COBOL went away the company would collapse. | | |
| |
| ▲ | jamesfinlayson 15 hours ago | parent | prev | next [-] | | Yep, I've worked for two companies where Fortran handles all of a major department's business - in both cases it was buried deep under layers of more modern stuff... but it was hugely risky to change it so it stayed. | | |
| ▲ | goku12 14 hours ago | parent [-] | | While the argument is generally correct, Fortran and COBOL aren't in the same league. Fortran is still being upgraded and has some use cases that are hard to achieve in another language. I've seen the Rust subreddit recommending use of old Fortran code with Rust, rather than rewriting it in Rust. Unlike most other languages like C++ and Rust, Fortran kept its scope mostly limited to numerical processing - making it still one of the best solutions to code highly parallel numerical algorithms in. Fortran isn't surviving just because nobody wants to rewrite Fortran code. Unless you're talking about Fortran77 code. | | |
| ▲ | jamesfinlayson 13 hours ago | parent [-] | | Oh agreed - Fortran is much more alive than COBOL - but in both cases I think the Fortran had outstayed its welcome. I never saw one of the codebases but the one I did see was Fortran 77 I believe, and there were a lot of gotos and labels. |
|
| |
| ▲ | throwaway2037 14 hours ago | parent | prev [-] | | > COBOL is still the backbone of the financial sector
Really? Is that commercial banks or ibanks? I think this is a myth. |
|
|
|
| ▲ | 17 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | leptons 16 hours ago | parent | prev [-] |
| Rewriting existing code in another language might be one thing LLMs can actually get good at. I wouldn't doubt if they could convert complex projects someday, without too much error or hassle. |
