On 14 December 2013 01:42, Dicebot <pub...@dicebot.lv> wrote: > 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 :) >
Can you offer an alternative? :) 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. > Heh, this sounds pretty much like my life. The same discipline applies to any realtime embedded software (read: video game console). I'm brutally conscious of all the details you mention. I don't think D is incompatible with this at all though. It was early last year... until I convinced Walter to implement align() properly. Now we're good! :) I could still REALLY do with __forceinline though. D doesn't have an effective macro. Obviously, if by 'language X' you mean 'any non-compiled language with pointers', then I totally agree! People who make claims like you say, don't generally know what they're talking about, or what C is actually used for.