"The truth is, everyone is going to hurt you. You just got to find the ones worth suffering for."
To some degree or another, everything sucks and complexity is unavoidable. You just have to find the type of complexity you're willing to live with.
That being said --
I suppose if you're used to that kind of complicated stuff and used to typing out the boiler plate code, it doesn't seem quite so inscrutible. Tedious, but it doesn't blow up in your face.
It's like I had a hard time understanding the strategy pattern the first time I saw it, especially when generics were involved. It felt mind bending.
Now I happily use it and it's all straightforward. The formerly intellectually difficult parts are now autopilot for me. And it's a hell of a lot less stressful than adding another set of random if statements to an important code path.
And keep in mind many of these phrases are very fancy ways of something that makes intuitive sense if you're familiar with it.
But see, the difference is something that is confusing to a beginner is quite a bit different than something that is just overwhelmingly complex for anyone.
And "simple" code has far more risk of side effect than well architected code, which is quite the opposite of what you assert.
Getting to the bottom of what you need to change is complicated if you're new, but once you get past the learning curve it's straightforward.
On the other hand, a "simple" code structure can becoming a steaming pile of garbage if you want to make any real changes to it.
To be very clear, I'm talking using something like composition instead of making a big file with cyclomatic complexity -- not arguing for some of those other things, which in all honesty I'm not completely familiar with.
Really just arguing that sometimes this stuff seems impossible and dumb when you're starting out, but easy and intuitive when you learn more.
> I pity the guy trying to fix some old legacy code base, while also trying to figure out what the hell a combinator is
That goes to my other point: it's wrapped up in excessively formal language, but the actual ideas are simple. I think they might be for instance just advocating the use of functional programming, and juniors use Javascript lambdas every single day without knowing what the hell a combinator is.
Even though they might feel the same, on a human level, there’s clearly a difference between being early in the learning curve and facing down a complex system.
> But maintainable code is about allowing other people to easily work on it.
But as OP said, it is selective. For instance, I would much rather have the OP use the strategy pattern. I have used it before, I will recognize it and it will take me tons of time when trying to understand the codebase and making a change that doesn't break things.
We cannot find a global optimum, we have to decide if we prefer to make it easier for experts/experienced developers or for beginners. I prefer the former and then teach beginners to become experts/experienced (in some area) as quickly as possible. That costs resources but pays off in the end.
Google went the opposite way. They created Go to be beginner's friendly but at the same time hurting productivity of more experienced developers. Let's see how that turns out in the end.
> Google went the opposite way. They created Go to be beginner's friendly but at the same time hurting productivity of more experienced developers. Let's see how that turns out in the end.
well, they started the Fuschia kernel in C++, not in Go... that should be telling enough :)
"The truth is, everyone is going to hurt you. You just got to find the ones worth suffering for."
To some degree or another, everything sucks and complexity is unavoidable. You just have to find the type of complexity you're willing to live with.
That being said --
I suppose if you're used to that kind of complicated stuff and used to typing out the boiler plate code, it doesn't seem quite so inscrutible. Tedious, but it doesn't blow up in your face.
It's like I had a hard time understanding the strategy pattern the first time I saw it, especially when generics were involved. It felt mind bending.
Now I happily use it and it's all straightforward. The formerly intellectually difficult parts are now autopilot for me. And it's a hell of a lot less stressful than adding another set of random if statements to an important code path.
And keep in mind many of these phrases are very fancy ways of something that makes intuitive sense if you're familiar with it.