5 ms·

Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm

Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)? In this case right here, what's your counter-example, or what would you use instead of their specific approach?

lmm 8y ago
> Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)? No, or at least not often enough to be worth thinking about. It is of course possible to use abstractions badly, but the problems that business software has to solve are always fairly simple because they're human problems; human business processes were never that complex. So if a program looks really complicated, the overwhelmingly likely cause is failing to use appropriate abstractions. > In this case right here, what's your counter-example, or what would you use instead of their specific approach? As others have said, a result type would greatly simplify this code without sacrificing any safety. No doubt after such a simplification made the code shorter and easier to comprehend, further simplifications would become apparent.
- femiagbabiaka 8y ago
  Your metaphor doesn’t really apply — this isn’t business software, it’s part of a distributed job scheduler. That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE. It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing logic branch completeness that door is open. Code might even convince the k8s team to change what you think is misguided behavior.
  - lmm 8y ago
    > That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE. Sometimes the best software is no software. Kubernetes exists to solve problems that people using better languages don't generally have. > It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing logic branch completeness that door is open. The "Please do not attempt to simplify this code" comment suggests otherwise. In any case, the team have chosen a language in which good solutions are not possible.
    - barrkel 8y ago
      > Kubernetes exists to solve problems that people using better languages don't generally have This statement doesn't make sense, and the arrogant tone just stinks of ignorance. Kubernetes isn't perfect, but if there's better provider-agnostic language-agnostic way to dynamically scale an application written in heterogeneous languages across a cluster or on a competitive choice of cloud platforms with dynamic provisioning, I'd like you to tell us, and explain why it's better than Kubernetes. Language agnosticism isn't something to discard lightly. Different languages have different strengths and weaknesses.
      - lmm 8y ago
        In my experience the costs of language agnosticism outweigh the benefits even without considering deployment. Good languages are general-purpose; a language that is drastically unsuited to some particular thing is probably not worth using at all, and if you're using a language that is decent at most things then the overhead of switching languages is higher than the benefit of using a language that gives a small advantage in some specialised area.
        barrkel 8y ago
        a language that is drastically unsuited to some particular thing is probably not worth using at all SQL and grep. Prolog and sed. Ruby and Rust. Yacc and Coq. These are not small advantages. They are great yawning chasms of usability and functionality.
  - chrisdone 8y ago
    If you're saying they should have solved a distributed problem with a distributed language like Erlang, I'd probably agree.
- dblotsky 8y ago
  > “human business processes were never that complex.” That’s a falsifiable claim. Human problems / laws are some of the most difficult to code for, IMO. Examples: legal software, economics software, etc. Usually complexity increases as you delve out of the abstract and deal with real-life processes with humans.

lmm 8y ago

> Would you agree that sometimes, abstractions can just distribute and hide complexity whereby actually all of that context is needed to comprehend the algorithm or process at hand (some things just ARE complex)? No, or at least not often enough to be worth thinking about. It is of course possible to use abstractions badly, but the problems that business software has to solve are always fairly simple because they're human problems; human business processes were never that complex. So if a program looks really complicated, the overwhelmingly likely cause is failing to use appropriate abstractions. > In this case right here, what's your counter-example, or what would you use instead of their specific approach? As others have said, a result type would greatly simplify this code without sacrificing any safety. No doubt after such a simplification made the code shorter and easier to comprehend, further simplifications would become apparent.

femiagbabiaka 8y ago
Your metaphor doesn’t really apply — this isn’t business software, it’s part of a distributed job scheduler. That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE. It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing logic branch completeness that door is open. Code might even convince the k8s team to change what you think is misguided behavior.
- lmm 8y ago
  > That is inherently complicated. There is of course an open argument of language choice, but I think there’s something to learn from the lack of software built in $BETTER_LANGUAGE. Sometimes the best software is no software. Kubernetes exists to solve problems that people using better languages don't generally have. > It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing logic branch completeness that door is open. The "Please do not attempt to simplify this code" comment suggests otherwise. In any case, the team have chosen a language in which good solutions are not possible.
  - barrkel 8y ago
    > Kubernetes exists to solve problems that people using better languages don't generally have This statement doesn't make sense, and the arrogant tone just stinks of ignorance. Kubernetes isn't perfect, but if there's better provider-agnostic language-agnostic way to dynamically scale an application written in heterogeneous languages across a cluster or on a competitive choice of cloud platforms with dynamic provisioning, I'd like you to tell us, and explain why it's better than Kubernetes. Language agnosticism isn't something to discard lightly. Different languages have different strengths and weaknesses.
    - lmm 8y ago
      In my experience the costs of language agnosticism outweigh the benefits even without considering deployment. Good languages are general-purpose; a language that is drastically unsuited to some particular thing is probably not worth using at all, and if you're using a language that is decent at most things then the overhead of switching languages is higher than the benefit of using a language that gives a small advantage in some specialised area.
      - barrkel 8y ago
        a language that is drastically unsuited to some particular thing is probably not worth using at all SQL and grep. Prolog and sed. Ruby and Rust. Yacc and Coq. These are not small advantages. They are great yawning chasms of usability and functionality.
- chrisdone 8y ago
  If you're saying they should have solved a distributed problem with a distributed language like Erlang, I'd probably agree.
dblotsky 8y ago
> “human business processes were never that complex.” That’s a falsifiable claim. Human problems / laws are some of the most difficult to code for, IMO. Examples: legal software, economics software, etc. Usually complexity increases as you delve out of the abstract and deal with real-life processes with humans.