Hacker News Reader

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

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

Higher level ones who's compilers can better reason about the code? See for example more generally Fran Allen's comments in Coders At Work for how desolate a optimization wasteland is C.

I think you're looking at this backwards from clifanatic's point. The more a higher-level compiler can reason about the code, the more optimizations it can perform, the less the compiler output resembles the source code input I gave it.

'C' is quite sufficient for micros and drivers. Micros are supposed to be small. Python's catching on with the kids for systems programming because of Arduino. Drivers are ... well, drivers. If you write 'C', you have to look at the assembly.

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.

"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?"

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/

Why is it we're not all using Oberon again? :) Ah, I remember having meetings about things like that... now that was inertia.

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.

right, but once you start writing inline assembly it's no longer a "cross platform assembly" - and I think there is a demand for that. For instance the Linux kernel supports a mind-boggling amount of different architectures and "just write in-line assembly" probably doesn't cut it

"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

You forgot old people. I'm positively ancient :)

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.

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.

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

> branching

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).

Well, in C++, "const" isn't actually intended to mean "literally const", it's supposed to mean "const in spirit". You can be const and still change some of the bits of an object if that change doesn't (semantically) change the object. To be able to do that, you need to be able to cast away const-ness. (No, I can't think of a reasonable example at the moment.)

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.