Re:Let’s stop copying C (2016)
by notacoward on Wednesday January 23, 2019 @12:17PM
(#18980204)
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.
Re:Let’s stop copying C (2016)
by MrBuddyCasino on Wednesday January 23, 2019 @09:29AM
(#18978349)
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.
Re:Let’s stop copying C (2016)
by linuxlizard on Wednesday January 23, 2019 @10:27AM
(#18978929)
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.
Re:Let’s stop copying C (2016)
by MrBuddyCasino on Wednesday January 23, 2019 @11:18AM
(#18979543)
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
> 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.
Re:Let’s stop copying C (2016)
by linuxlizard on Wednesday January 23, 2019 @10:20AM
(#18978840)
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))
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.
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.