3 ms·
Yes, there's definitely a kind of complexity that _doesn't_ stem from the problem domain, and it can often be eliminated. Stuff like over-abstracting, insane d
by emilecantin 6y ago
Yes, there's definitely a kind of complexity that _doesn't_ stem from the problem domain, and it can often be eliminated.
Stuff like over-abstracting, insane default values, duplicated state that needs to be synchronized (e.g in React components) or just overly-repetitive code, for example.
- msla 6y agoManual memory management is accidental complexity unless very strict memory usage rules are part of the specification. Some kinds of type systems similarly lead to accidental complexity, for example in the form of repetitive code because the type system makes sufficient abstraction impossible. It's possible for some kinds of requirements to mandate very concrete types with no room for abstraction in some parts of a program, but even then the compiler can do most of the work with making sufficiently abstract code concrete and performant.
- elteto 6y ago> Yes, there's definitely a kind of complexity that _doesn't_ stem from the problem domain, and it can often be eliminated. Yes, it can be eliminated, but only to some extent. Programming languages add a baseline of complexity by themselves that _can't_ be removed: programming languages are not infinitely flexible so there will always be problem characteristics (invariants, data structures, etc) that will not be easily expressible. Those are new sources of complexity. Think how Java simplifies manual memory management when compared with C or C++. Or how the Rust borrow-checker provably prevents a whole class of bugs. But these are all tradeoffs, both Java and Rust are ill-suited to express other problems.