On Wed, May 10, 2017 at 12:06:46PM +0000, Patrick Schluter via Digitalmars-d wrote: > On Wednesday, 10 May 2017 at 06:28:31 UTC, H. S. Teoh wrote: > > On Tue, May 09, 2017 at 09:19:08PM -0400, Nick Sabalausky > [...] > > Perhaps I'm just being cynical, but my current unfounded hypothesis > > is that the majority of C/C++ programmers ... > > Just a nitpick, could we also please stop conflating C and C++ > programmers? My experience is that C++ programmer are completely > clueless when it comes to C programming? They think they know C but > it's generally far away. The thing is, that C has evolved with C99 and > C11 and the changes have not all been adopted by C++ (and Microsoft > actively stalling the adoption of C99 in Visual C didn't help either).
OK, I'll try to stop conflating them... but the main reason for that is because I find myself stuck in-between the two, having started myself on C (well, assembly before that, but anyway) then moved on to C++, only to grow skeptical of C++'s direction of development and eventually settling on a hybrid of the two commonly known as "C with classes" (i.e., a dialect of C++ without some of what I consider to be poorly-designed features). Recently, though, I've mostly been working on pure C because of my job. I used to still use "C with classes" in my own projects but after I found D, I'd essentially swore myself off ever using C++ in my own projects again. My experience reviewing the C++ code that comes up every now and then at work, though, tells me that the average typical C++ programmer is probably worse than the average typical C programmer when it comes to code quality. And C++ gives you just so many more ways to shoot yourself in the foot. The joke used to go that C gives you many ways to shoot yourself in the foot, but C++ gives you many ways to shoot yourself in the foot and then encapsulate all the evidence away, all packaged in one convenient wrapper. (And don't get me started on C++ "experts" who invent extravagantly over-engineered class hierarchies that nobody can understand and 90% of which is actually completely irrelevant to the task at hand, resulting in such abysmal performance that people just bypassed the whole thing in the first place and revert to copy-pasta-ism and using C hacks in C++ code, causing double the carnage. Once I had to invent a stupendous hack to bridge a C++ daemon with a C module whose owners flatly refused to link in any C++ libraries. The horrendous result had 7 layers of abstraction just to make a single function call, one of which involved fwrite()-ing function arguments to a file, fork-and-exec'ing, and fread()-ing it from the other end. Why didn't I just open a socket to the daemon directly? Because the ridiculously over-engineered daemon only understands the reverse-encrypted Klingon protocol spoken by a makefile-generated IPC wrapper file containing 2000 procedurally-generated templates (I kid you not, I'm not talking about 2000 instantiations of one template, I'm talking about 2000 templates which are themselves procedurally generated), and the only way you could speak this protocol was to use the resultant ridiculously bloated C++ library. Which the PTBs have dictated that I cannot link into the C module. What else was a man to do?) T -- Try to keep an open mind, but not so open your brain falls out. -- theboz
