50 years of C, the good, the bad and the ugly [video]
streaming.media.ccc.de
50 years of C, the good, the bad and the ugly [video]
1–10 of 257 posts
Re: 50 years of C, the good, the bad and the ugly [video]
#2His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.
Re: 50 years of C, the good, the bad and the ugly [video]
#3His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.
There are certainly some key libraries that use Fortran still. But I wouldn't say it's still "around". As a language for new projects, it's extremely niche. That's probably what "go" means in your comment.
I assume you're being facetious with the "recently came across", since scipy is so common, but I will add that nearly every math-intense library is a clever wrapper for some Fortran code.
I would be perfectly happy to see many hardened C libraries become the foundation of the next gen systems/ embedded languages. It does bother me slightly when we abandon the past entirely and attempt to "rewrite it in X"
Re: 50 years of C, the good, the bad and the ugly [video]
#4His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.
There are certainly some key libraries that use Fortran still. But I wouldn't say it's still "around". As a language for new projects, it's extremely niche. That's probably what "go" means in your comment. I assume you're being facetious with the "recently came across", since scipy is so common, but I will add that nearly every math-intense library is a clever wrapper for some Fortran code. I would be perfectly happy…
In part that is because once a piece of software has been part of a certification process it can be very hard to replace it by something newer, no matter how shiny or how much faster. You can see quite a bit of this in aerospace, civil engineering and so on. Nobody wants to be the one to replace the Fortran based FEA package with something novel and end up being liable for a bug.
Re: 50 years of C, the good, the bad and the ugly [video]
#5Great talk. Borland should have rated a mention though, their C compiler really popularized C development on Windows.
Re: 50 years of C, the good, the bad and the ugly [video]
#6His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.
There are certainly some key libraries that use Fortran still. But I wouldn't say it's still "around". As a language for new projects, it's extremely niche. That's probably what "go" means in your comment. I assume you're being facetious with the "recently came across", since scipy is so common, but I will add that nearly every math-intense library is a clever wrapper for some Fortran code. I would be perfectly happy…
No, I was not being facetious. I am not a regular user of Python, mostly have been writing/maintaining software in C++ and (in the past three years) C#. I came across it because a colleague (fluent in Python) had used scipy.interpolate in some experimentation and now the algorithm he came up with has to be implemented in C#, so I investigated whether scipy.interpolate could be called from C# and then found out that its source was in Fortran.
But just like Fortran is still used for nearly every math-intense library, mostly invisible for most of the users, I suspect that C will still be around in 50 years from now.
I agree, with his observation that C should be no longer your language of choice for new projects. I personally still prefer using C/C++ for my private software projects, simply because it is the language I am most fluent in. This year I used it for AoC.
Re: 50 years of C, the good, the bad and the ugly [video]
#7Earlier quoted context omitted.
There are certainly some key libraries that use Fortran still. But I wouldn't say it's still "around". As a language for new projects, it's extremely niche. That's probably what "go" means in your comment. I assume you're being facetious with the "recently came across", since scipy is so common, but I will add that nearly every math-intense library is a clever wrapper for some Fortran code. I would be perfectly happy…
No, I was not being facetious. I am not a regular user of Python, mostly have been writing/maintaining software in C++ and (in the past three years) C#. I came across it because a colleague (fluent in Python) had used scipy.interpolate in some experimentation and now the algorithm he came up with has to be implemented in C#, so I investigated whether scipy.interpolate could be called from C# and then found out that i…
Significant chunks of numpy and scipy, the "main" python packages for numerical algorithms, are wrappers around classic libraries such as BLAS, LAPACK and ARPACK, which are Fortran. Fortran was the de-facto language of scientific and numerical programming for a long time, back to the 60s even. These libraries are battle tested more than anything else out there, they literally have decades behind them, so they are industry standard and are used wherever possible.
Re: 50 years of C, the good, the bad and the ugly [video]
#8His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.
I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that make it annoying to program in. But since Zig 1.0 is unlikely until 2026 I'd say we wouldn't start seeing Zig majorly displace any C programs until about ten years after 1.0, which would be 2036. Rust 1.0 was in 2015 and we are just starting to see it in the Linux kernel ~ 8 years out, so that seems like a good timeline. Then just give it another 40 years and I could see a future where Zig and Rust replace all code where C is currently used. Sure there might be some ancient legacy systems that use C, but just like COBOL, would not be something that you would come across unless you wanted to.
Re: 50 years of C, the good, the bad and the ugly [video]
#9His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.
I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that mak…
Is there a reason Zig is taking so long to go 1.0? The language itself feels mature.
Re: 50 years of C, the good, the bad and the ugly [video]
#10His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.
We can replace COBOL with a Java backend to keep the enterprise feeling going, but what would C's replacement be in this case?