On Thursday, 12 December 2013 at 13:17:14 UTC, Manu wrote:
But that's not a concern for typical programmers. That the responsibility
of sysadmins.
What I meant was, 'what's more valuable [to a programmer]...'

Leaning dangerously close to philosophy here :)

Did you use many different compilers? I am afraid that doing that on a
common basis is feat of strength beyond my imagination :)


Yup. Over the past 10 years, my day job involved:
...

Well, you are much more proficient and experienced C programmer than me :P (And than I will ever be considering I have no desire to return to that world) It is clearly beyond my imagination. I have been investigating dissassembly only to verify which stuff actually gets there and which not and debugging of course.

And of course I am speaking about drivers / kernels / barebone. I can't imagine any other domain where using C is still absolutely necessary for
practical reasons.

You mean C-like-native-languages? There's not really anything C offers that
C++/D doesn't also offer at the lowest level.

Right now problem is not with stuff C offers and D not. It is stuff that D offers on top and you are forced to fight to get back to C level of simplicity.

Our choice to use C rather than C++ was in a sense, a funny way to enforce a coding standard. Like I say, it forces simplicity, and a consistent
approach to problems.

When I was speaking about "domains where C is still necessary" I was not opposing it to C++ but other modern languages in general. Even real-time service development is quite possible using stuff like Erlang these days. Okay, there is also gamedev which I won't dare to speak about :) But in general there is no much sense to speak about replacing C and imagining any "normal" userspace application, even performance-critical.

Some time ago I have been part of project that completely changed my image of what C domain can be. It remains most mind-blowing experience in my programming history (which is damn short of course but can't resist dramatical intro). Project was in mobile networking / LTE domain with huge amount of people involved all over the world. Specifically our team in Latvia was responsible for node cluster software which acted essentially as a giant router + firewall. Actual nodes were custom multi-core MIPS machines with h/w implementation of event loop and part of IP stack handling. All actual packet processing code ran as barebone executables - no OS, not virtual memory or any fancy stuff, just platform SDK you take to build single processing binary which is than loaded at hard-coded memory address (all remaining memory is pre-allocated for packet handling purposes). No really complicated processing algorithms or anything like that but everyone was extremely picky about tiny details how this binary was actually running - making sure no instruction cache misses happen under normal workflow for each core, connection context struct fits into single cache line and stuff like that. And one of my responsibilities was actual performance testing of that system so I could have observed how much of an impact those seemingly small tweaks have made.

And now every time I hear that "language X can do all stuff C can" I imagine myself trying to sell this to other guys working on that project and have an extremely hard time doing this even in my imagination.

Reply via email to