Comment by simias | Hacker News Reader

Comment by simias | Hacker News Reader

Parent Full thread

In my early 20's I got the appeal of that I think. I wrote a lot of C++, learned all the (then) new features and design patterns. I had a bunch of C++ books covering various advanced topics. I felt like a rockstar implementing ultra-sophisticated generic libraries.

I think I remember what the breaking point was for me. I had a custom serialization format (something YAML-like, because of course I had to implement my own custom format) and I wanted to pretty print it. I needed to implement some kind of indentation routine, you know, add a number of spaces at the start of a line depending on the current nesting level.

I wrote an indentation class that was fully generic. As in, the whole concept of indentation was abstracted away, I wasn't dealing with line buffers and characters, I had generic streams of objects and everything was templated and Boosted to the max. Must have taken about 20minutes to compile on the CPUs of that time. I was proud of my mad cpp skillz too.

And then the absurdity of it struck me. Over the next few years I found myself returning to the simplicity of C more and more (not that I would recommend C as a replacement for C++ in the general case, mind you).

Often when I read C++ discussions these days I think I detect the same kind of hubris I used to experience. Just writing ultra-complicated code for the sake of some perverted notion of purity and elegance.

So when you mix that mindset with the "and the kitchen sink too" ethos of the C++ language committee, you end up with the unmaintainable monstrosity that's modern C++.

You just described me in my 20s as well. I used to revel in my knowledge of C++ minutiae and being able to quote parts of the standard and recognize obscure undefined behavior.

Then I started a company and hired people to work with me and it hit me just how much of an absolute waste of time it is to know that stuff. It doesn't translate or generalize well, most C++ is a special kind of complexity that is only relevant to C++, and then when you hire people you can actually assign a dollar cost to the complexity and that cost is simply not worth it.

I still use C++ at my company, but I now use a very simple and straight forward subset of it, basically along the lines of C with classes and namespaces. No more boost, no more elaborate SFINAE, no more writing things to be so generic and obtuse and avoiding parts of the language that are too abstract.

In that vein I also avoid all of the mess introduced by C++20. Concepts were a missed opportunity, modules are beyond useless, and the fact that C++20 has both coroutines and ranges just shows how the language is designed in a Frankenstein manner. A good solution for coroutines would make the use of ranges unnecessary, and a good solution for ranges would make coroutines unnecessary.

Instead C++20 provides half-assed implementations of both.

I find myself largely agreeing with you about the hubris and complexity behind most c++14/17/20 discussions today. and often feel adding complexity for the sake of intellectual satisfaction is pointless and should be avoided.

My view is that we mostly read code a lot more than write it and code is basically the low level fabric on with we build higher level abstractions like business logic (except for some ultra specialized cases like shaders or vector assembly). My problem is that any senior engineer shouldn't have to waste brain cycles figuring out the language antics when reading code because that takes you away from the reality you really want to get to (the business logic or the intent of code). for a reasonbly senor coder the language really should be out of teh pecture. these antics often end up wasting attention and sometime resources because likely somebody would use that code in a way its not intended and it will have a subtle failure like using extra resources etc

PS: apologies for misspells in above para, was hoping to make a point.

I believe that deep, down its a question of identity and incentives. The right thing to do is reduce complexity.

But the thing that optimizes for nerd status and job security and resume building is to increase complexity, because most people cannot appreciate the sophistication of simplicity in some technological niche, and it is not easily communicated.

And then there is the question of what gives you joy? I find that for most coders, their primary motivation is not to solve a customer problem in the quickest, simplest and most efficient way, but to challenge themselves with riddles and learn new tech and follow fashion. This definitely varies by culture - Golang and Haskell are on opposite ends in that spectrum.

Overcoming delusion means to exit one's own mind and observe the real world. Looking at useful and well-made software, in which language is it implemented in? A Haskell fan will have no trouble talking for hours about how its concepts are superior. But he will not notice that there is barely any popular software written in Haskell out there, and he will not understand what that implies.

You hit the nail on the head I think. A few years into my career I was enamored by learning new programming languages, in particular functional ones. I was fully drinking the koolaid, too - pure functions and immutability would surely make writing web crud a blissful experience, right?

At some point I realized that the nice examples from the books never mapped to the real world as cleanly. Exceptions were pretty useful, local mutability made lots of things easier, and category theory has no place in calling JSON apis over http.

I think a great number of talented programmers never learn that lesson, and continue futzing about with theoretical purity for its own sake.

On the other hand there is value in learning different languages and concepts, and possibly applying them in your day to day job if it makes sense. It makes you a better programmer. But one is a means to an end, and the other is... I don't know, a philosophy? L'art pour l'art?

"But the thing that optimizes for nerd status and job security and resume building is to increase complexity, because most people cannot appreciate the sophistication of simplicity in some technological niche, and it is not easily communicated."

I think you're on to something there, except for the "job security" part. I've met very few people in tech who are concerned about losing their jobs, and fewer of them would make things much more complex---they didn't have the skills.

In fact, most of the majority I have known who produced complexity were optimizing for nerd status and resume building, but would quit rather than maintain their own complex code.

you can limit your code to a subset of c++, make it like a c with free ctor/dtor and simple classes, then it's not that complex.

I think this kind of philosophy is what ended up driving Go's simplicity.

Less infatuation with the tool, more focus on shipping maintainable code the first time.

Reply on news.ycombinator.com