Hacker News Reader

Comment by linuxlizard | Hacker News Reader

I work with a large vendor code base that is ~300k lines of C. There are 515 different #ifdef conditional symbols (thank you, grep). The code base started probably >20 years ago and has has who knows how many engineers working on it. There are 20+ years of standards' evolution in this code, across who knows how many chipsets, the vendor changing hands, etc. And yet, in spite of the maze, the code works very well!

I would love to see a new language, technology, something, take on this sort of problem. C works so well in this sort of problem because of the preprocessor's ability to strip out bits & pieces that aren't necessary at the time.

We need something that will allow us to fall into the pit of success rather than succumb to the easy solution of using #ifdef for new, optional features.

View on HN

Is anything new really needed here? The problem that the kernel etc. solves with ifdefs and function pointers doesn't seem that different than what one can do with interface inheritance in just about any OO language. With smart inlining and LTO it can even be efficient. The problem is how to do those platform/feature checks at build time instead of run time, but I'd say that's the build system's problem ('make' or equivalent) not the language's. Ifdef there makes a lot more sense, even for languages that use modules.

Well a language could have more expressive and clean macros that can still access compiler some variables.

> I would love to see a new language, technology, something, take on this sort of problem.

I know for a fact that Rust can do this[0], though I couldn't speculate as to whether it would be better or worse than the equivalent done with the CPP (I am fairly convinced it would be harder to fuck up at least), and I would be very surprised if the other modern systemsy languages (D, zig, etc.) didn't offer similar things.

I suppose you mean something besides dead code elimination? Because that looks like it could be solved with proper encapsulation and abstraction mechanisms in the language, which C lacks.

It's a pretty amazing problem--a wifi chipset. The driver runs on Linux and Windows, also supports 3x different CPU architectures (x86, mips, arm) and multiple bus interfaces (SoC internal, usb, pci). Supports disabling optional features so 2.4Ghz only chipsets have a smaller memory footprint. Can build with/without different security options. And that's just starting in on the huge number IEEE 802.11 standards across the last 20 years. Some chips support some of the features, some don't -- but the driver still has to work on all of them.

Linux kernel is an amazing example of how to do ^^^that and still produce beautiful code. The Linux kernel uses a great number of function pointers to accomplish their encapsulation goal.

I see where you're coming from. The description already gave me nightmares.

Dead code elimination would require all code paths to be compilable by the compiler being run.

That need not be the case, and typically isn’t. If you do

   #if USE_FOO
     #include <foo.h>
   #endif

the foo.h header only need to be present on platforms where USE_FOO is defined, and need only be compilable on those platforms (it might use nonstandard compiler extensions, for example containing assembly instructions)

> We need something that will allow us to fall into the pit of success

This is a tremendous phrase.

https://blog.codinghorror.com/falling-into-the-pit-of-succes...

Most likely reference.

Yes, I definitely learned it from a Spolsky & Atwood podcast. Not my own term (I'm nowhere near that clever).

This is something Common Lisp does with its reader macros. There's a global variable FEATURES, which is populated by one's implementation (and so might indicate OS, implementation &c.). When one reads in a file of code, there're two reader macros #+ & #- which conditionally include code, based on whether or no symbols are present in FEATURES. E.g.:

    (defvar *foo* #+sbcl(sb-sys:thing) #-sbcl(portable-thing))

The elided code isn't even truly read in, so it's not an error to refer to the package SB-SYS in a non-SBCL implementation.

I wouldn't claim that this is the end-all, be-all of code, but it does make for some reasonably compact platform-dependent-but-portable code.

Have you seen ziglang.org?

Reply on news.ycombinator.com