[kaba0]

I don’t know, people who go too hard on simplicity often don’t even grasp the underlying problem in a given case (looking at this utterly dumb piece of text as an example: http://harmful.cat-v.org/software/) - sure, no sane people would want to deliberately introduce complexity/abstractions, but abstraction is the only weapon we have against complexity. Problems have an inherent complexity which simply cannot ever be reduced. If you do have to make it work, what else can you do?

I think go is a good example for this fallacy, it claims that it is a simple language, but ad absurdum asm should also be trivial to understand as every line is also easy to grasp, right? Low expressivity just creates chaotic complexity, won’t reduce it.

[yung_steezy]

Some people seem to really struggle to understand that abstraction is intrinsic to computer science. Trying to get as close to the metal as possible while using your daily driver is a fun hobby but there is nothing innately virtuous about it.

[ternaryoperator]

I quite agree. I take it a step further: I think devs should be taught how to handle complexity better. It's a skill that some programmers have and that others sorely lack, but AFAIK, it's not a skill taught at all in CS programs.

[scoutt]

Complex problems and complex solutions are two different things. The genius is in solving complex problems with simple solutions. While it might seem that adding a crate to solve a problem is a simple thing, from the system programmer point of view (mine), it is not.

[kaba0]

But it is simply not possible to solve many many complex problems with simple solutions, no matter how hard you try.

Also, using a (hopefully) well-tested library that someone wrote is absolutely a good (and only significant, as per Brooks) way to increase productivity - but also correctness! Do I really have to write a matrix library myself? Sure, I can probably write a function that multiplies two matrices, but will it have sane numerical stability? [1]How can I even test that out? It is a whole separate field, where I likely overestimate my knowledge about. Was it really worth that extreme amount of time to write an almost surely buggy and slower implementation than depending on someone else’s work?

The art of programming is also about knowing when to reach for other tools.

[1] Hell, multiplying multiple matrices already “needs” a dynamic programming algorithm to decide how to associate pairs of them

[scoutt]

I would definitely do like you and reach for math libraries/crates whenever I can, since I suck at complex math. But this also means three things: there is the chance we are both no geniuses, we added a complex "black box" solution (who knows how this library/crate work?) and now we have to babysit a dependency.

[javajosh]

>abstraction is the only weapon we have against complexity

I don't agree with this. We also have stinginess and stubborness as potent weapons against complexity. If we are stingy with our time and effort then we insist on getting much use out of every tool we learn. We are stubborn, and so we do not add new tools quickly, or throw old ones away quickly, and we are skeptical of easy solutions. tldr: first cut away needless complexity, then use abstraction on what remains.

[kaba0]

Do note that I was talking about essential complexity, not accidental. The latter can and should indeed be dealt with.