On 12 December 2013 22:21, Dicebot <pub...@dicebot.lv> wrote: > On Thursday, 12 December 2013 at 11:42:12 UTC, Manu wrote: > >> I've built a C codebase from the ground over the course of a decade with >> ~25 programmers. >> It takes discipline, and a certainly sense of simplicity in your >> solutions. >> > > It may work if you can afford to guarantee certain level of competence of > majority of programmers in the team but I think is exception in practice, > not rule. Also I had a bit larger teams in mind as it tends to happen with > enterprise C :)
Completely true. Fortunately I've always worked on tech/engine teams, which are mostly populated with seniors, or competent up-and-comers. and what is more valuable than a >> programmers time? >> > > At some point new servers + server maintenance becomes more expensive than > programmers time. Much more expensive. 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]...' I still consider C a macro assembler... I can easily (and usually do) >> visualise the asm output I expect the compiler to produce while I'm >> coding. >> If I'm writing performance intensive code, I am constantly disassembling >> and checking that the compiler is producing the code I am expecting. This >> feels normal to me. >> > > 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: VisualC (it's changed a LOT over the years), GCC (for many architectures), CodeWarrior (for many architectures), SNC (for many architectures), Clang, and some other proprietary compilers. You learn each of their quirks with time, and also how to reconcile the differences between them. You also learn every preprocessor trick imaginable... Worse than the compilers is the standard libraries, which are anything but standard. In the end the ONLY function from the CRT that we called, was sprintf(). We had our own implementations of everything else we used. I'm absolutely conscious of these sorts of issues when I consider my approach to D. Many of my vocal opinions stem from a desire to mitigate these sorts of problems in the future, and make sure it is possible to directly express codegen concepts that I've previously only been able to indirectly express in C compilers, which often requires some coercion for different compilers, and invariably leads to #ifdef. It's important to be able to explicitly express low-level codegen concepts, even if these are rarely used features, it means it's possible to write code that is reliably portable. Sadly, most people really don't care too much about portability. What would you want inline assembly for in D? Inline assembly is almost >> always a mistake, unless you're writing a driver. >> > > I can't find code Adam used to provide minimal d runtime stubs to compile > C-like programs but he was forced to use in-line assembly there in few > cases. Can't remember details, sorry. > Right. It's usually necessarily for hacks that have to interact with, or bend/subvert the ABI. But that's a pretty rare necessity, not a requirement in day-to-day code. 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. 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. You can't possibly >> schedule code better than the compiler. >> ... >> > > I am not implying that one should do anything by hand because compiler is > bad at it. I have not actually used inline assembly with C even a single > time in my life. That wasn't about it. > The only thing I've ever had to use it for in recent years is manually fiddling with flags registers, or interacting with hardware-specific concepts that C/C++ doesn't have ways to express (interrupt levels, privilege control, MMU control, context switching). Also, SIMD. C++ compilers traditionally didn't have any vector support, so before intrinsics were common, you had to do all SIMD code in asm >_< .. Fortunately, that's a thing of the past.
