3 ms·

There's a distinct difference between complexity and complication, which I think is what the author is looking to convey. Complexity is just inherent to the sy

There's a distinct difference between complexity and complication, which I think is what the author is looking to convey. Complexity is just inherent to the system you are building. The only way to decrease complexity is to do less. Hiding it only moves it somewhere else. There's a whole school of thought around the idea of reduced functionality, and in fact it's baked into the UNIX ethos of "do one thing well". Complication, on the other hand, is what I would call "unnecessary complexity" that gets added to a system as you bolt on more things to give it more potential, or to support legacy. We see this in a number of programming languages, most famously C++. Adding more capabilities to the language requires you to have more knowledge before you can effectively use it. Adding features to something not designed for it (cough Java) results in some very annoying complications. And THIS is where the call for simpler languages comes from. The misunderstanding between complexity and complication is what causes for example golang to be such an annoying language. They sought to reduce complication (a laudable goal), but conflated that with complexity and only managed to move it elsewhere (because that's all you can actually do with complexity). We see similar problems in data formats. JSON has lax standards and limited type support, which forces the complexity onto the user in the form of string serialization and base64 and all sorts of incompatible custom secondary codecs. Is the format itself simple? Sure! The spec fits on one page! Is it simple to use? Absolutely not! It's a minefield and a security nightmare. Data is complex, and any decent data format will have to be just complex enough to support the majority of use cases in a consistent fashion.

kaba0 5y ago
I generally agree with you (with the addition of it being often referred to as essential (which is non-reduceable) and accidental complexity=complication in your words). May I ask you why do you think Java is an example of adding features it was not designed to have? In my opinion, even with the original warts of the language, it is one of the few long-running languages that managed to withstand adding every feature and the kitchen sink, and additions are thoughtful and deliberately slow (late-movers advantage, it let’s other languages make mistakes with a feature first, avoiding bad ideas like async). Generics was added very cleanly to the language seeing the constraints of the time, lambdas are also more than good in my opinion (with the only wart being around checked exceptions, unfortunately). The new direction with algebraic datatypes (record, sealed classes) and pattern matching is also an example of a feature that was known forever (ML), but the general developer community got to like it only recently. it is only bad in the context of managed languages that can do better. It is a “necessary evil” in case of rust for example
- kstenerud 5y ago
  Generics were a necessary thing, but the type erasure is a huge problem, and unfortunately one that can't be fixed without a completely new bytecode format. Also, annotations, while a necessary thing to bring it up to speed with modern practices (such as nullability contracts), add to the bureaucracy of Java and make it more painful to work in. Don't get me wrong; I do like Java, and have written hundreds of thousands of LOC in it over my career. But there's only so much it can do without breakage, and only so much that can be papered over and worked around. Even Kotlin suffers from the JVM it rests upon.
  - kaba0 5y ago
    Why do you think type erasure is problematic? Haskell and basically every language absolutely gets away with type erasure so it really shouldn’t pose a serious problem, other than for reflection usages which are rare.
    - kstenerud 5y ago
      It was too long ago so I can't remember why it was problematic, only that it was, and required a bunch of workarounds in some cases to get what you take for granted in other languages.

kaba0 5y ago

I generally agree with you (with the addition of it being often referred to as essential (which is non-reduceable) and accidental complexity=complication in your words). May I ask you why do you think Java is an example of adding features it was not designed to have? In my opinion, even with the original warts of the language, it is one of the few long-running languages that managed to withstand adding every feature and the kitchen sink, and additions are thoughtful and deliberately slow (late-movers advantage, it let’s other languages make mistakes with a feature first, avoiding bad ideas like async). Generics was added very cleanly to the language seeing the constraints of the time, lambdas are also more than good in my opinion (with the only wart being around checked exceptions, unfortunately). The new direction with algebraic datatypes (record, sealed classes) and pattern matching is also an example of a feature that was known forever (ML), but the general developer community got to like it only recently. it is only bad in the context of managed languages that can do better. It is a “necessary evil” in case of rust for example

kstenerud 5y ago
Generics were a necessary thing, but the type erasure is a huge problem, and unfortunately one that can't be fixed without a completely new bytecode format. Also, annotations, while a necessary thing to bring it up to speed with modern practices (such as nullability contracts), add to the bureaucracy of Java and make it more painful to work in. Don't get me wrong; I do like Java, and have written hundreds of thousands of LOC in it over my career. But there's only so much it can do without breakage, and only so much that can be papered over and worked around. Even Kotlin suffers from the JVM it rests upon.
- kaba0 5y ago
  Why do you think type erasure is problematic? Haskell and basically every language absolutely gets away with type erasure so it really shouldn’t pose a serious problem, other than for reflection usages which are rare.
  - kstenerud 5y ago
    It was too long ago so I can't remember why it was problematic, only that it was, and required a bunch of workarounds in some cases to get what you take for granted in other languages.