Hacker News Reader

Comment by pcwalton | Hacker News Reader

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

View on HN

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

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

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.

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?

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.

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

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

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
    }

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.

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

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.

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.

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.

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?

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.

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

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.

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

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

C has a standard with multiple competing compilers.

Rust does not have these same features to date.

With multiple slightly incompatible competing compilers.

D as BetterC !

Zig

Reply on news.ycombinator.com