Given the examples that follow it seems more of an ideological stance that a practical one. C is dead so let's teach Pascal, Lisp, MIPS assembly and Smalltalk?

From a language theory standpoint C is pretty clunky but in terms of getting stuff done it's still one of the most mainstream languages out there.

>having learned C++, any student would be able to downgrade themselves into C level on per-case basis.

That's sort of how I learned C in the first place where I see where you're coming from but I don't think that's good general advice. "Don't learn C, learn C++ and figure it out from there" is sort of like saying "Don't learn Italian, learn Latin and figure it out from there". C++ is a beast of a language, if people are interested in C they should learn C.

>C only became industry relevant thanks to the widespread of UNIX clones, and in platforms like ChromeOS, Windows, Android, its relevance is slowly fading away.

I sort of agree but I'm more of a glass half full type of guy, I think C is less relevant not because it's fading away but because other languages are taking a lot more space nowadays. What used to be considered "scripting languages" are commonly used to build complex applications because we have a lot more RAM and processing power than we used to. Still, kernels and low level code are still commonly written in C or, sometimes, C++ because you need good performance and/or tight control over the application.

Have you missed the time reference?

Java still wasn't invented, Smalltalk had companies like IBM selling products written in it.

MIPS was being adopted across UNIX workstations.

People still though it was worthwhile to buy Common Lisp implementations.

Regarding language comparisons, actually C++ is Italian and C Latin.

C is C and C++ is C++. The analogy breaks down in a pretty major way because Latin has no native speakers, but important work is done in C. They didn't stop speaking Latin because it had problems as a language, they stopped because the cultural apparatus behind Latin collapsed after an exceptionally long period of dominance that Italian speakers never achieved.

I'd like to believe C has a stronger future in the academic world because it is simpler than C++, but also because C is a designed language and C++ is a cobbled-together language, and maybe that counts for something in a field where people call themselves engineers.

Anyone who sees C as a 'downgrade' has badly misunderstood what design means as an engineering concept. It doesn't mean 'does everything', it means that strategic choices were made early in the process after careful consideration.

* Serious hat *

C has a pretty well defended place in the world - it is an excellent choice for manipulating RAM and controlling the size of variables. C++ isn't as good, because its features add a lot of complexity that isn't really desirable when you have a problem that C can handle.

I wouldn't use it for string parsing. Or GUIs except as an afterthought on a project that used C for a good reason.

P.S: there's a book called "The design and evolution of C++" which you should probably read. Where can one learn more about the design of C?

I'm a huge fan of Rust and I can only dream of having all C codebases in the wild ported to it some day but I'm still writing C at work because it's faster, easier (vendors provide C libraries and code, not Rust) and it's easier to hire C coders than Rust ones.

>P.S: there's a book called "The design and evolution of C++" which you should probably read. Where can one learn more about the design of C?

I'd be surprised if C was really ever "designed" the way we would design a language these days. Basically it was a fork of earlier languages tweaked to more conveniently model the hardware of the time. It was more about getting the job done at the time than making an innovative language. At least that's what I gathered from what I know about the early days of C and it's also fairly apparent in the way the language itself is designed (the whole pointer/array shenanigans come to mind). C is many things but it's definitely not elegant or even clever.

There is an history of 10 years of systems programming languages, preceding it. Prooving one does not need to throw security out of the window in systems languages.

Had Bell Labs been allowed to sell UNIX, instead of giving it away for a symbolic price and C would have been a footnote on history of system languages.

I agree that if we're talking about why C took over in the first place it's a different discussion.

I was mainly referring to new projects, where C continues to be selected because of a myriad of reasons, none related to technical uniqueness or superiority.

This is truly infuriating, because we will collectively pay for those poor choices in security vulnerabilities.

Furthermore even brand new projects will have to interface with existing code to some extent. C bindings are everywhere, Rust not always. And even when they exist they're not always complete and are often quite experimental.

Still, I'm doing my part and I did write a few smaller components of my current project in Rust at work. But it's not surprising that the shift is not happening overnight.

AUTOSAR now requires C++14 compliance on software certification.

Android, ChromeOS, Windows, Apple OSes native components are mostly written in C++.

Finally, all major C compilers are written in C++ nowadays.

The only places where C++ is failing to replace C, is among developers unwilling to move beyond C89 on embedded space, or UNIX clones.

But it is impossible to create a beautiful, "properly designed" programming language that's also backwards compatible with C. I mean look at Objective-C :)

C is simpler than C++ until we need to manage memory or need to handle basic data structures. When that happens, C requires reinventing the wheel over and over again.

"As simple as possible, but no simpler."

In fact C++ allows for flexible memory allocation strategies per data structure, while C forces one to hand code them all and replacing something like malloc affects the whole executable behavior.

You realize that that's not exactly flexible. Tieing shape to behaviour in this way is where the pain starts.

And the fact is that it does. In the rare case that it doesn't then C++ also accomosdates those requirements if developers are willing to put in the same sort of effort that goes into implementing data structures by hand.

Well engineered tools have quality as their main focus.

C won its place in the world thanks to UNIX adoption, and its commoditization via free beer OSes, nothing else.

MIPS I concede, it was remained fairly popular for a long time.

I guess my overall point is that the subjective choices made by this university back then don't really mean much by now. The fact that they taught Pascal instead of C alone proves that they weren't particularly prescient.

>Regarding language comparisons, actually C++ is Italian and C Latin.

I thought about that while writing this bad analogy but I couldn't come up with a better one. I wasn't really talking about the historical relationship between C and C++ but rather about their relative complexities. Learning C++ is vastly more complicated than learning C. On top of that the coding style of a modern C++ application (which generally involves a lot of metaprogramming, OOP and even some functional constructs) is fairly different from a standard C codebase. You don't write C like you write C++ and vice-versa.

There's this good talk about how we should "stop teaching C" (if we want to teach C++): https://www.youtube.com/watch?v=YnWhqhNdYyk

I think the opposite holds true as well for very much the same reasons.

OTOH, C was just standardized a few years before, and linux was just a side project from an unknown student in a small university. And there was a new version of C, with objects, classes, inheritance and all those buzzwords, so why care about the old C anyway?

I don't know about you, but I haven't noticed any dramatic increase in performance - if anything - apps are slower and consume ridiculous amounts of RAM. At work I'm using PyCharm (written in Java) and somehow it's "normal" for it to consume 1Gb of memory. Now if every app would be free to use memory like that, then I wouldn't be able to run more than 8 apps on my computer.

For all the 'memory safety' and 'exception' features that Java has, in my experience - and that includes the time spent with PyCharm too - Java apps are more unstable. Sometimes the JVM downright crashes, or angrily throws a nasty exception, leaving me perplexed as to what happened and worried whether I should restart the app or not.

I don't see a reason why a program like PyCharm couldn't have been written in C. 'It's too low-level' is the common answer - I don't think so; the real reason is probably along the lines of 'I don't want to deal with manual memory management and pointers, and since there's plenty of languages that do that for me - I'll use that!'. C is bare-bones - and that's a virtue - because the programmer is in charge. Every single aspect of the program is a consequence of his decisions. It also removes the opaque 'middle layer' of cruft, like garbage collector and standard libraries.

C is the best language out there, in my opinion, sitting in the nice spot between assembly and higher-level languages. I wish there was a successor of C, which would have carried its philosophy into the 21st century (and no - I'm not talking about the abomination that is C++).

It has always been deeply important in scientifuc computing, and even now it’s very valuable to know C underpinnings of Python & Python scientific computing tools. On the scientific algorithm side I don’t see C diminishing in importance at all, and many critical systems and libraries use it and require young programmers to know it to really use them (zeromq, Postgres C api, CPython, various things written in Cython).

From the point of view of an ex-CERN, very few relevant packages are written in C.

However, my unscientific and unsupported observation is that in fields that have emerged after Fortran went out of vogue as a general-purpose language, this same process happens again, but just with a more modern language. SciPy etc. are quite common in fields like genomic analysis, and I suspect that in 20 years, this will still be the case even if almost nobody else is writing new Python code.