Hacker News Reader

Comment by WalterBright | Hacker News Reader

Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D).

But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close.

For example, the C preprocessor is surprisingly complicated. I had to scrap it and rewrite it completely 3 times. If you try to make use of all those oddities, my advice is don't waste your time. Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better.

View on HN

I couldn't agree more. After spending many years working with LLVM, which is at its heart a C compiler, and understanding why it has to do the sometimes-terrifying things it has to do to get C to run well, I've become very paranoid when writing C or C++. My C/C++ code is as boring as possible.

(In fact I try to avoid writing C or C++ whenever possible these days; undefined behavior in the language is too pernicious and unfixable without breaking compatibility. I think both languages are approaching obsolescence.)

What would we write drivers in then if C was obsoleted?

pcwalton might have an opinion :). He is Rust lead designer.

Not lead designer :)

But yes, Rust, or even in userspace, as newer and/or more microkernel-ish OS's allow for. Apple is doing work to allow drivers to be written in Swift...

I believe DriverKit is still C++.

...and of course pre-Apple, DriverKit was Objective-C.

And pre-OS X, Mac OS was Object Pascal. :)

Just some parts of it.

Some device classes (not to mix with OOP ones) can only be programmed with C++, while others can be developed in any compiled language able to link to the OS APIs.

There is a WWDC session on it.

I watched it, and they're pretty clear that driver extensions (using DriverKit, like I mentioned) must be written in C or C++. System extensions can use any language.

I was thinking about whole driver feature set, so got it wrong.

C has a standard with multiple competing compilers.

Rust does not have these same features to date.

With multiple slightly incompatible competing compilers.

The Oberon system has drivers in, well, Oberon (which is a high-level Pascal successor with garbage collection). Low-level memory access is done through magical peek/poke functions, in which all the dirtyness is concentrated (and these might not be allowed in user programs - not sure). This means the language as a whole is not littered with unsafe pointers just to service the tiny subset of programs that need them.

And it is used commercially.

Astrobe has been selling development kits for ARM based boards for years now.

D as BetterC !

Rust? I know a lot of people evangelise rust — to the point of annoyance of others — but as we move into an era where the entire world is run on computers, it is just not acceptable to have decades old infrastructure susceptible to bugs often caused by someone not understanding undefined or implementation dependent behaviour.

Is still a little early, but as someone who works at the bare metal level, Rust shows early promise.

The features required are still unstable (as in not in the stable version of the compiler), but it’s getting there, and doing it fast.

In any case, firmware behaves a lot like banking software, language change will take time

Cargo feels like too bloated to me for it to be something suitable for something low level like embedded. Unless the rust team can make it more appealing to use the language without cargo, I don't think there's much future.

We use rust in embedded and love cargo! Coming from C++ and the endless mess of build systems that exist there, cargo is a breath of fresh air! What don't you like about it?

In bare metal systems, cargo would run on the developers host system, so that should not be an issue.

Also, most toolchains of the sector are way more complex to maintain and way more bloated.

Apple says the future is C++ and Swift.

Microsoft says the future is a mix of constrained C++ (Core Guidelines), Rust and AOT C#.

Google says the future is C++ and Java (as of Treble) on Android, with Go, C++ and Rust on ChromeOS and Fuchsia.

ARM says C++ on mbed.

GenodeOS says C++ and Ada.

Newton, Symbian, Bada and BeOS used C++.

C is married with UNIX, they were born to each other, other OSes have long followed other paths.

Minor point, but isn't Android moving to Kotlin? I don't think they see Java being a sustainable choice for the long term.

Yes they are, but in what concerns Treble and platform libraries, they plan to keep their Java 8 variant around.

Apparently they are also adding support for desugaring Java 10 language features (yep 10 not 12) that don't rely on new JVM bytecodes (as per Google IO talk about state of Android tooling).

At least for now.

Zig

> My C/C++ code is as boring as possible.

One advantage to being an older programmer is I don't feel any need to show off any more. I try to make it so obvious that anyone would look at it and think that's so simple, anyone could do it.

It's surprisingly hard to write simple code. Any idjit can come up with Rube Goldberg code.

Though different people consider different things simple. To one a loop is fine, to another a map is a better choice.

map/filter/reduce is simpler, but it takes some getting used to. Loops have worn a deep rut in my brain.

As someone who was introduced to programming via map/filter/reduce, for loops are incredibly more complicated.

I don’t think I’ve ever written one correctly on first try.

Are you primarily a JS/front-end dev?

Because this is crazy to me! Some languages only use for loops (Go).

Full-stack, spent most of my time on the backend in ruby or scala.

Unfortunately, loops still seem to be the easiest way to iterate over two collections simultaneously.

“#zip”?

Or maybe I’m misunderstanding the use case?

Which only works if the sequences align perfectly. Handling misaligned collections is more awkward with functional constructs.

Functional graph programming is also still a bit of an open problem. There are awkward scenarios in both cases.

Ah, I see what you mean. Yeah, that’s always awkward

Not sure how you deal with that with for loops either. Increment the iteration var in the body of the loop? (Seems scary to me, but like I said, I’ve got terrible intuition with them)

For something like iterators:

    var ie1 = foo.GetEnumerator();
    var ie2 = bar.GetEnumerator();

    while(true)
    {
        var has1 = ie1.MoveNext();
        var has2 = ie2.MoveNext();
        if (!has1 && !has2)
            break;
        if (has1)
            // do something with ie1.Current
        if (has2)
            // do something with ie2.Current
    }

> I don’t think I’ve ever written one correctly on first try.

Please don't take offense, but this is odd to me. I honestly severely doubt I am some sort of programming super genius, but I have never had any issues setting looping logic correctly. (I took four years to teach myself programming & CS and now I've been at my first professional dev job for ~6 months.) None of my colleagues seem to have such issues either. What are you experiencing trouble with most? Off-by-one?

I mean, I've written at most a couple dozen in my 7 years as a professional programmer (usually tight loops for perf), so sheer unfamiliarity is a big factor.

But yeah, syntax (what order the arguments go in) and off-by-one issues are the majority, I think. Plus figuring out what my initial accumulator needs to be.

Idk, map/filter and friends are just a much more direct mapping of how I think of programming.

For those who may have trouble with loops, take heart: after 45 years of non-stop programming, often 10+ hours a day, I still find myself sometimes doing mental loop simulations with small (few element) data to make sure a loop is correct.

It's usually much easier to take extra time to make sure it's right than to debug it later.

I've used loops so much I don't even see the loop anymore as a collection of constructs, I see it as a single thing. There are a lot of easy mistakes to make with loops, but I don't make them anymore (of course, by writing that, I will make one!). For example:

    #include <stdbool.h>
    #include <stdio.h>
    typedef long T;
    bool find(T *array, size_t dim, T t) {
      int i;
      for (i = 0; i <= dim; i++);
      {
        int v = array[i];
        if (v == t)
          return true;
      }
   }

There are 5 errors in that example.

Is the fifth error that there are only four errors?

> to another a map is a better choice.

Are you thinking more of JS or another functional scripting language than C/C++? C doesn’t have map, so it’s not an option, and in C++ it’s called something else.

In JS, I so wish that I could switch to functional constructs like map permanently, but map and foreach are much slower than loops, an order of magnitude or more for tight loops. I’m still forced to use loops in performance critical code, even if I consider map a better choice.

Coming back to C++ after having been in JS land for 5 years, C++ feels constantly difficult to use, and all the names for the functional primitives don’t seem to make intuitive sense like they do in JS.

> order of magnitude or more for tight loops

I just learned this about JS's map/foreach a few weeks ago. I didn't think it was possible to be more disappointed by JS than I already was, but somehow I managed it.

Same here.

C++ only when Java or .NET need it's assistance, or integration with OS APIs that require C++ (NDK, WinUI, DX).

Then C only when there is no alternative (customer wants it, we only do C here, required lib is C only e.g. SDL, ...).

It is an herculean project, but maybe some day LLVM could be rewritten into something else. After all it isn't the first compiler stack, just the one that got most famous.

And that's why people claiming that C++ is more complicated than C because it has an even bigger specification miss the point.

What counts is how easy to use in practice. You can get along just fine in C++ without knowing the exact aliasing rules from C or or how to specialize a template. What matters is that the extra features of C++ makes actual programming simpler, not harder. (for example destructor (RAII), standard library, classes, ...)

> You can get along just fine in C++ without knowing the exact aliasing rules from C

Nope, you can't. These are exactly the things that introduce undefined behavior (i.e. total breakage) if you aren't very careful about what you're doing at all times. Don't take my word for it, check out what the C++ designers themselves state about the issue in the C++ Core Guidelines. C/C++ is far from simple, and thinking that you can just make things up as you go along is a serious mistake.

You are absolutely right, but my point is that when you do modern C++, in the application code, it is very unlikely that you need to use reinterpret_cast in your code, and therefore you don't need to know all the subtlety about it.

So despite C++ being more complex than C, if you limit yourself to some practical subset, it is actually easier than C.

Same can be (and has been) said about JavaScript. Or C. Or any language with any kind of issues.

And it doesn't work in practice.

I think it does sometimes? At least for enterprise software.

We use both C and C++ embedded as well as C++/Qt for the desktop control system, and we have no issue keeping to a sane subset of C++.

There are clearly defined rules and code review does the remaining enforcement. And it's not even hard or time consuming as everyone is pretty much aligned and every small issue can be easily resolved with a quick chat.

Strong agreement here.

You can limit yourself by choice to certain areas of the language that you know inside out (you know the asm they produce, etc.) and use it to solve problems. Don't worry about every single corner case. As you said, you can easily forget those things, especially if it's not your day-to-day job.

The same idea and principle can be found in "JavaScript - The Good Parts".

Having recently been doing some web development, I'd argue that JavaScript's design (even today, despite some modern additions) is so conducive to undebuggable spaghetti code (i.e. this ) that there really are no good parts.

Sometimes the technology is objectively the wrong choice i.e. compiling javascript to native code (Not a JIT).

Some languages do fight your attempts to write good code every step of the way :-)

No, I won't name names.

I'm currently writing a library that loads, parses and includes c headers at compile time, in D.

It's not finished but let's just say I've managed to make yours and Andrei's thoughtful design into a monster

Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better.

I don't get it. If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them?

My goal as a developer is to write clean performant bug-free code... not to make life easy for compiler developers.

> If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them?

The problem is they don't make code easier to read and understand. Worse, the unhygienic nature of C macros makes it hard to contain them.

I haven't seen your code, so I'm speaking based on what I've seen of mine and others' code. If you dial it back, the person who has to deal with your code after you leave will appreciate it.

More generally speaking, if you're doing metaprogramming with the C macro system, you've outgrown the language and should consider a more powerful one.

I once worked at a place that had a platform specific "DEBUG" log macro.

It worked something like: DEBUG(msg); Except, it was defined in such a way that you actually had to have two closing parens, like DEBUG(msg)); It looked syntactically invalid, but whatever the macro did required it.

The entire code base was littered with WTFs like that...

I hated debug macros. There just was never a clean way to write them. I was determined that D would not suffer from that problem. `debug` is a keyword in D, and you can do things like:

    debug printf("I got here\n");

and the printf only gets compiled in when compiling with -debug. (Any statement can be used after the printf.) Even better, semantic checks for debug statements are relaxed - for example, purity is not checked for them.

Meaning you can embed debug printf's in functions marked 'pure', instead of having to use a monad.

Can you assure that your preprocessor tricks always generate compliant code?

For me writing embedded code is the ultimate test for your programming skills, since a lot of C toolchains for embedded devices (as in bare metal embedded) are unstable, only almost compliant and full of weird behaviors and hacks.

Here's an example: https://github.com/Tarsnap/libcperciva/blob/master/datastruc...

As long as you invoke use it properly, e.g.

ELASTICARRAY_DECL(PTRLIST, ptrlist, void *);

there's no way it will create non-compliant code.

Because when you work on a team, not everyone is a C Gandalf, probably not even yourself a couple of months later when fixing a bug with everyone screaming that the system is down.

Exaggerating here, but rule of thumb is that it takes twice to debug as it takes to write it, so how long do you want to take to do maintenance fixes?

rule of thumb is that it takes twice to debug as it takes to write it

Ok, so... macros which let me write code faster should help with debugging time as well? ;-)

It is an exponential curve with cleverness as input parameter.

So it depends how complex they are.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

--Brian Kernighan

How ('yeah im going to write this') do you start such project like a c compiler? Seems like a huge thing to write. What did you write first? Did you already have a lot of compiler knowledge so you had a good idea/structure/flow etc in your mind already? And how long did it take you?

tia

A compliant C compiler is probably a year's work in a modern language give or take?

It takes 3-5 months just to write a compliant preprocessor. Writing a basic code generator is a year, writing a basic optimizer is another year.

But if you want a competitive compiler, better pencil out 10 years.

I'd written a couple compiler like toys before, but nothing like a real compiler. I just started writing it. Took a couple years.

> at one point I knew everything there was to know about C

after taking the test, wouldn't this be:

at one point I knew everything there was to know about (my implementation of) C

also: one time long ago I tried to use the c-preprocessor to preprocess a data file. ha ha ha ha ha. (conclusion: don't do that)

Somewhat related, what would you recommend for someone who has never programmed in C?

Reply on news.ycombinator.com