His 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.
50 years of C, the good, the bad and the ugly [video]
11–20 of 257 posts
Re: 50 years of C, the good, the bad and the ugly [video]
#12His 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.
Is that even possible as long as the Linux kernel is written in C? I wonder if telling people not to learn C will have a long-term effect on being able to find competent contributors to the kernel.
Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html
It might take another decade for a C-free build to be possible, though.
Re: 50 years of C, the good, the bad and the ugly [video]
#13Earlier quoted context omitted.
Is that even possible as long as the Linux kernel is written in C? I wonder if telling people not to learn C will have a long-term effect on being able to find competent contributors to the kernel.
> Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.
Rewriting that amount of code in ten years sounds very very hard, at least.
Re: 50 years of C, the good, the bad and the ugly [video]
#14His 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.
Namely, if it has to be "replaced", that would be with something with a much simpler syntax, which will require a bit more of finger power. We don't want to find ourself locked-in by very few compiler vendors (open source or not), that only because it is not reasonable to code a real-life alternative with a small team of averagely skilled devs in a reasonable amount of time.
This language should build on C though: no enum/typedef/_generic/switch/etc, only 1 loop keyword (loop{}) only explicit sized types, no integer promotion, no implicit casts (except maybe void* pointers but number literal casts should be) but explicit casts (compile-time and runtime, without that horrible c++ syntax), explicit compile-time const (we have only runtime consts which could be optimized as compile-time consts), enforce extern for functions (and don't try to put the binary format, elf/coff/etc, semantics into the language syntax or worse, the OS interface semantics), etc.
With enough discipline (and compiler warnings), we could get close to such language.
I did not check the latest and greatest rust syntax, but is what's above its explicit goals?
That said, I am a "everything in 64bits RISC-V assembly with x86_64/arm64 legacy ports kind of guy"... if RISC-V is successful (I wish). We could think of high-level language interpreters (coded in assembly, for instance a RISC-V coded python/lua/javascript/etc interpreters).
Re: 50 years of C, the good, the bad and the ugly [video]
#15Earlier quoted context omitted.
Is that even possible as long as the Linux kernel is written in C? I wonder if telling people not to learn C will have a long-term effect on being able to find competent contributors to the kernel.
> Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.
AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C.
Re: 50 years of C, the good, the bad and the ugly [video]
#16His 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.
Or maybe they will, given how much consultants in those languages happen to be paid, as no one else wants to touch them.
Re: 50 years of C, the good, the bad and the ugly [video]
#17Earlier quoted context omitted.
> Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.
Wow that sounds fantastically optimistic, or pessimistic depending on your point of view I guess. Rewriting that amount of code in ten years sounds very very hard, at least.
Now, rewriting everything, including all the legacy drivers? Yeah, never happening even if Rust succeeds utterly.
Re: 50 years of C, the good, the bad and the ugly [video]
#18Earlier quoted context omitted.
> Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.
Only a decade? I don't think so. AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C.
Re: 50 years of C, the good, the bad and the ugly [video]
#19His 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…
Re: 50 years of C, the good, the bad and the ugly [video]
#20Great talk. Borland should have rated a mention though, their C compiler really popularized C development on Windows.
Even Petzold embraced C++, even if superficially,
"This third edition has several changes. First, all programs are now compilable with either the Microsoft or the Borland compiler. All make files are generic and use environment variables for compiler flags, link libraries, and so forth. Second, all programs are now compilable in C++ mode. Although I don’t use any C++ specific features, compiling first in C++ mode is helpful if C++ features are to be added later to the code"
-- https://archive.org/details/programming-windows-31-3rd-ed/pa...