C is a terrible cross platform assembly b/c it doesn't allow you the level of control which one would expect in this day and age. Maybe it was written in the days when CPUs were brain-dead simple, but basic things that are available on most architectures aren't part of the language. It has no notion of a CPU cache, it has no notion of branching (you can't tag a likely branch and an unlikely one), it even goes as far as to ignore user keywords for inlining and provides no keyword for blocking inlining. RVO is implicit magic that you just pray happens. Const != immutability.

When you write C you have no notion of what the compiler is going to output whatsoever

A lot of these things are available through compiler extensions (so great, now it's not cross-platform), but even still the language is broken. "Expert C Programming" has a really long chapter that goes over all the more confusing subtly problems C has beyond just arrays being pointers-but-not-really.

I have to use C pretty regularly and all I can think is "God.. why hasn't anyone made this better yet"

Well, sort of... but what language isn't that true of? And really, what language isn't that more true of than C?

And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you?

I really am sorry you have to use it, but there are rather large populations of people who go completely untroubled with it.

The current ones might be like C on that part, might do something different. I haven't evaluated that. Here's a few:

http://www.astrobe.com/Oberon.htm

http://www.mikroe.com/mikropascal/#

http://www.mikroe.com/mikrobasic/

SFAIK, ( meaning I don't really ) the various "Mikro" probably do the same thing that the native toolsets for , say PIC, do and simply add default, built-in symbols for bits in control registers and things like turning interrupts off/on. That keeps the amount of assembly further down.

I feel confident in saying that because they'd want to make defection from the default say, AVR compiler chain as painless as possible.

And of course, Linux drivers/ioctl() help a lot with bringing kernel mode things into user space. Using assembler in a driver is just one of those things we find acceptance with.

"large populations of people who go completely untroubled with it."

Stockholm syndrome.... Or a lack of imagination about how things could be better. There really is a cult-like adoration of C - I think mostly by people that don't use it and learning it in college and long for something as simple

I've used it for 30+ years. It's not the only thing I've used. But I've used it a lot, for deployed systems that Just Work(ed)(tm). They don't have a lot of UI, usually.

You don't get "cross-platform assembly" in a complete 100% sense and get the enjoy the fruits of hardware diversity. An escape to inline assembly is PERFECTLY FINE.

The Linux kernel doesn't use that much assembly. But yeah - "just write inline assembly" is exactly how it's done. And as someone who's done a few Board Support Packages for Linux and other O/S-es, it's not a huge risk - there's generally a port for a processor, so a small number of people write the inline assembly and it gets distributed widely.

I don't think people who don't like 'C' should use 'C'. I don't like Java too much, so I pretty much refuse to work in it. I don't touch Web stuff at all, beyond a few weeks here and there.

You have to use a pretty weird process to write robust and reliable systems in 'C' but it's not exactly difficult. It just takes... six months of knuckle busting most people don't have. Maybe three months. You have to smooth over learning some arcane rules.

I think that the emphasis we see online on 'C' comes from open source, in particular the Linux kernel, and it causes this weird ...status rift to open and people fall into it.

I'd been programming professionally for twelve or so years prior to even seeing Linux. In 'C', Pascal for a couple years before 'C'. I FIRMLY believe that 'C' is the mechanism to get the most reliable and deterministic solution to problems. Note I didn't say "fastest". But that's when I do it; after the last few years, there's enough whining about how bad 'C' is that I kinds shrug and say "hey, if it hurts you're doing it wrong. Make yourself happy."

but I'm on teams with people who use all the fancy high level stuff and ... frankly, it's not my stuff that doesn't work. Because I've done this for 30+ years.

What language has all of these covered? (Rust?)

None that I know of from the last 20 years or so.

> inlining

This one is tricky. Sure, GCC ignoring the inline keyword is annoying, but sometimes figuring out if something is inline-able is undecidable, and sometimes things just aren't capable of being inlined.

> blocking inlining

This is something that I don't understand why we don't have. Sure, lots of times you would rather inline than not, but sometimes inlining the wrong expression can subtly change the performance / lookup / dispatch semantics in weird ways. I've no hard examples of this, but it should be easy enough for almost every language to have a --no-inline flag.

> RVO

C++11 and up somewhat handle this with move semantics. Having a separation of rvalues / lvalues certainly helps, but the distinction could probably be clearer, as it can get to be a gruesome and hairy topic depending on your types.

> const != immutability

That you can often just "cast the const away" is really the problem here. I think Rust improves on this space as there is no safe cast to remove const-ness, but if you ever find yourself or somebody else casting away const, you / they should realize that they are going against the design of the system. I'm still undecided if "mutable" keyword in C++ classes is so horrible in this context, as it certainly helps in making const-types usable with the rest of the language (which is inherently non-const).

It would be fair to ask whether that intent was a good idea. It would also be fair to point out that many (most) times people cast away const-ness simply out of expediency, rather than using it the way it was intended.

A false argument that's easy to counter with itself:

COBOL is over 50 years old and still in widespread use by businesses, even though there have (supposedly) been better languages targeting the same use cases for decades now. There is more to it than just inertia.

Nope, it's just inertia. Specifically, the risk of breaking stuff by rewriting it to work better, preservation of backward compatibility as a business benefit, prior investments in tooling, what people are already using vs what's new, and laziness far as hobbyists that started with it. Same reasons C and UNIX problems didn't get fixed. Sociology and economics trump technical points in adoption or continuation of languages, platforms, etc. The meme for this, per Gabriel, is "Worse is Better."

Second: I would suspect that there are far more new projects started today in C than there are in COBOL. C is in use (at least sometimes) as a voluntary choice, and COBOL is not.

I hear lots of interpretations of it. I could be misremembering. I'll take another look at it. Appreciate the specific points to look into. :)

"Second: I would suspect that there are far more new projects started today in C than there are in COBOL. C is in use (at least sometimes) as a voluntary choice, and COBOL is not."

If we're using that constraint, then Java and PHP are the example with Java for about any kind of app. A lot of people even like Java. They think it's great and hate C. So on and so forth. Yet, the popularity still tells me nothing as I got to watch Java get forced by Sun and others into its position step-by-step with insane amounts of work to get it to match performance and productivity of better-designed languages... partly successful there. It was actually experience of Java IIRC (later C#) that was the reason many people didn't think an OS could be done in a GC'd language. They mentally associated GC'd language with stuff like that. That a small team pulled it off in Oberon with a handful of people at a time porting or extending it is always news to Java developers I meet here.

Lack of context, bad design, meant to replace prior languages for most applications, platform orientation, and massive ecosystem + uptake + tooling make it a better comparison. So, I'll use it and COBOL next time.

Maybe anything that winds up trying to play in that "language for big corporate enterprise software" winds up like that?

What they have in common, as with C, is they were pulled or pushed in for ecosystem benefits + marketing then spread and sustained on that bases mostly. So much stuff written in them with so many talent or tools that they're self-perpetuating. I'm claiming most C adoption & entrenchment is the same phenomenon outside embedded or ultra-high-performance applications where use is quite practical. You constrained the COBOL example but I recalled popularity effect applied to Java, too.

I don't think anyone really likes COBOL. And I don't think anyone would start a new project in COBOL given the choice.

"I don't think anyone really likes COBOL."

COBOL was like the Visual Basic of mainframes. It looked close enough to pseudo-code or business problems that even lay people could learn to write mediocre code in it. They could Get Stuff Done. Versus assembly, ALGOL, or C, they'd prefer it since they can grok it. Truth is that those people probably don't need to be coding business-critical apps but that plus mainframes making compilers for it gave COBOL an adoption advantage. Much like relationship between cheap hardware, spread of UNIX, and C compiler availability.

Personally, I can't stand to look at COBOL. I tried to do my part ridding us of it by forwarding things like Semantic Designs Inc to COBOL shops where possible. Very entrenched, though, due to inertia of tons of software written in about a billion lines or so of it in shops where it's what most people know. Sound familiar?

But COBOL alternatives won. Where COBOL used to rule, Java rules now and .NET languages follow closely. People want to throw COBOL away but can't.

C alternatives just can't get past their niches. Even when people don't have to use C, they choose C. It's more than clear to me that this happens because people like C and actively work to keep it entrenched.

And liking C doesn't mean being unaware of its problems. But it means people want those problems fixed while keeping the core of what they like. I believe C alternatives fail because they go too far. They fix its shortcomings but also go for a different aesthetic.

So yes, my point is largely non-technical. However, our industry is full of examples of things that "won" for largely non-technical reasons.