Time to make C the COBOL of this century
-
This post did not contain any content.
-
System shared this topic on
-
This post did not contain any content.
No.
C is going to be around and useful long after COBOL is collecting dust. Too many core things are built with C. The Linux kernel, the CPython interpreter, etc. Making C go away will require major rewrites of projects that have millions upon millions of hours of development.
Even Fortran has a huge installed base (compared to COBOL) and is still actively used for development. Sometimes the right tool for a job is an old tool, because it is so well refined for a specific task.
Forth anyone?
The rewrite-it-in-rust gang arrives in 3, 2 ...
-
No.
C is going to be around and useful long after COBOL is collecting dust. Too many core things are built with C. The Linux kernel, the CPython interpreter, etc. Making C go away will require major rewrites of projects that have millions upon millions of hours of development.
Even Fortran has a huge installed base (compared to COBOL) and is still actively used for development. Sometimes the right tool for a job is an old tool, because it is so well refined for a specific task.
Forth anyone?
The rewrite-it-in-rust gang arrives in 3, 2 ...
"It's too much work, so let's just not do anything and stubbornly stick with a problematic unsafe language that fewer and fewer people are willing to learn"
-
"It's too much work, so let's just not do anything and stubbornly stick with a problematic unsafe language that fewer and fewer people are willing to learn"
Certainly, if I had said that.
It's like the Brits trying to convince everyone else to switch to their electrical socket. Sure, the design is better for higher voltage and current, has all these extra safety features, etc. But you cannot dramatically shift an entrenched ecosystem for free.
-
This post did not contain any content.
My wife was telling me at her work they're desperate for cobol programmers, as they're all retiring boomers leaving behind a giant code base. At my work, it's legacy fortran that's all over the place, but we're a much smaller company.
-
My wife was telling me at her work they're desperate for cobol programmers, as they're all retiring boomers leaving behind a giant code base. At my work, it's legacy fortran that's all over the place, but we're a much smaller company.
I know COBOL, its pretty easy to pick up honestly. Its just the 40+ years of context and the "WHY"s that they did what they did that is hard.
-
This post did not contain any content.
These tech images are getting pretty ridiculous. What even is this thumbnail?
-
My wife was telling me at her work they're desperate for cobol programmers, as they're all retiring boomers leaving behind a giant code base. At my work, it's legacy fortran that's all over the place, but we're a much smaller company.
Can I take a a guess? If not, please ignore the next sentence.
Finance companies with a "database" is a gigantic flat file?
-
Certainly, if I had said that.
It's like the Brits trying to convince everyone else to switch to their electrical socket. Sure, the design is better for higher voltage and current, has all these extra safety features, etc. But you cannot dramatically shift an entrenched ecosystem for free.
Yea, mb, on reread yea.
But still, nothing new should be written in it and everything old should be rewritten or deprecated over time. Entrenched and around, yes, useful....no
There's very little benefit to starting something new in C and a whole lot of downsides. At least FORTRAN and COBOL have niche use cases. C doesn't really have a good niche case that something else newer and more secure can't fill AFAIK
-
These tech images are getting pretty ridiculous. What even is this thumbnail?
Only ones who knows how to make proper tech images are the folks at O'Reily publisbing
-
I know COBOL, its pretty easy to pick up honestly. Its just the 40+ years of context and the "WHY"s that they did what they did that is hard.
What's the latest news?
-
What's the latest news?
I work in a field that is 1. in the news every day and 2. is seeing HEAVY changes. Im sure you can figure it out ;).
They cant fire me, but I might be on accident haha.
-
This post did not contain any content.
It’s great that there are new languages coming along that strike a balance between performance and safety. However, there’s always going to be a need for unsafe, low-level code. I work in semiconductors and occasionally have to write firmware and drivers for our devices. There’s no avoiding C in those environments.
-
Yea, mb, on reread yea.
But still, nothing new should be written in it and everything old should be rewritten or deprecated over time. Entrenched and around, yes, useful....no
There's very little benefit to starting something new in C and a whole lot of downsides. At least FORTRAN and COBOL have niche use cases. C doesn't really have a good niche case that something else newer and more secure can't fill AFAIK
The problem is switching for enterprises because of how much momentum there is. Especially in embedded.
I worked on a 30 year old C code base that’s still being developed now for future products. Some components are literally 20+ years old mostly untouched. Sure they could switch to Rust or something but they’re fucked since nearly none of the staff have relevant experience in anything but the in house C build system and changing over multiple thousands of C files to another language will literally take years even if you got people trained up.
Plus, in embedded pretty much no big HW supplier provides BSPs or drivers in anything but C. If NXP etc. aren’t giving you anything but C, management doesn’t want to start combining languages.
I advocated for Rust when we started a ground-up new project, but got shot down every which way. Only those younger than like 35 were into the idea. Old managers are scared of anything new and their whole life has been C. I don’t know how you convince those kinds of people and maybe we’ll get some movement in another 10 years but enterprises are a slow cautious mess.
-
This post did not contain any content.
Serious question: How can a programming language be more or less secure than another? I am just a hobbiest, not a professional, so I am genuinely curious.
-
Serious question: How can a programming language be more or less secure than another? I am just a hobbiest, not a professional, so I am genuinely curious.
It's mostly about memory access. Modern languages throw errors if, for example, you try to reference an element of an array that is "outside the bounds" of the array. C does not - it gladly returns whatever memory address is past the end of the array. So the programmer has to check that the index is
0 <= x < array_sizewhenever they access a an array entry. That's a pain - so they don't. -
Serious question: How can a programming language be more or less secure than another? I am just a hobbiest, not a professional, so I am genuinely curious.
Its about the type of operations the compiler allow you to do, more or less. Like sharing mutable references, that can be independently changed in a 'hard to keep track of'- manner. Other factors the compiler tries eliminate include buffer overruns and int overflows e.t.c.
Rust for example sometimes makes trivial things a royal pain, see linked lists for example. It also has a gaping microdependency/supply chain attack prone ecosystem, and the compiler interface is also not stable (afaik, caused some issues in linux). There is also no spec.
I have experience of both, and i love both, but C is my fav. Its often trivial to imagine the codegen with C, and there are no shortage of quality compilers. The language is also small enough that implementing a compiler is actually feasible.
-
No.
C is going to be around and useful long after COBOL is collecting dust. Too many core things are built with C. The Linux kernel, the CPython interpreter, etc. Making C go away will require major rewrites of projects that have millions upon millions of hours of development.
Even Fortran has a huge installed base (compared to COBOL) and is still actively used for development. Sometimes the right tool for a job is an old tool, because it is so well refined for a specific task.
Forth anyone?
The rewrite-it-in-rust gang arrives in 3, 2 ...
Making C go away will require major rewrites of projects that have millions upon millions of hours of development.
Yep. And it'll be done. Yes it'll take a while, but this is what it means for C to be like COBOL (which also still exists). But the more and more it can be marginalized the better we'll all be security-wise.
The rewrite-it-in-rust gang arrives in 3, 2 …
Cattle not pets. They're just computer languages.
-
Can I take a a guess? If not, please ignore the next sentence.
Finance companies with a "database" is a gigantic flat file?
Lol yeah she's in insurance! I bet you could probably also infer from the fortran that I work for a science-y outfit.
-
Serious question: How can a programming language be more or less secure than another? I am just a hobbiest, not a professional, so I am genuinely curious.
Concrete technical answer (one of many): imagine you have a list ("array") of 5 numbers, and you try to print the 10th number in the array. A secure language will say "error! it's a list of 5 numbers, there is no 10th one!!". C will just print some random garbage (whatever happens to be in the part of memory following the 5 element list) without indicating anything has gone wrong. There are many other issues like this with C.
Abstract philosophical answer: Secure languages like Ada and Rust are designed to help you ensure the absence of unwanted behaviours, rather than just the presence of wanted ones. If you want behaviour X, the goal of old languages like C was to make sure you could write a program in which X was present. That was a big enough challenge in the old days that language designers stopped once they reached that point. If you don't want behaviour Y (let's say Y is a security attack), it's up to you to just write the program without behaviour Y. 50+ years of experience have shown that to be inhumanly difficult once the program gets complicated, so you really do need help from the language.
This is the classic problem of proving a negative, so there are limits on how thorough the checking can be, and the technical features (like the notorious Rust borrow checker) can be difficult to use. But if you're willing to endure a certain amount of pain and runtime inefficiency (requiring the program to do a little extra work at each operation to make sure the result makes sense, like the example of the 10th element of the 5-element list), you can make programs much safer than you can in C.
Does that help?
