3 ms·

Would be interesting to read a rebuttal of the presented definition.

by dgb23 5y ago

dahart 5y ago
I like the definition “Simple means not tangled.” But that definition isn’t objective, it depends on what you think is tangled. The author claims “Simplicity is objective because - if we can distinguish them - we can count how many simpler elements are there, tangled together.” This admits that objectivity depends on distinguishing what the elements are, which is often subjective. So this claim can be seen as false in the sense that you can’t make something objective out of subjective parts, or true in the sense that it’s trying to punt by treating the whole as a separate thing from the elements that comprise it. One good example of subjective elements is the discussion on state - “State is never simple because it complects - tangles - time and value.” I agree with this, but it’s important to note that state does not encode time explicitly. Time and state are byproducts of assignment. We can remove the notion of time (assignment) from some bit of code and make the code functional. But we can’t move the notion of time to an element of it’s own. And if we could, and then compose it with an element of value, we’d end up right back where we started with some state. Generic discussions on state can be hard to parse too since there doesn’t exist a computer program without state. We move it around, organize it in various ways. We hide it with interpreters and compilers. But it’s always there. At a high level, there’s no way to detangle time and value when users and user input are involved. A feedback-response cycle often is state at a fundamental level (unless your program is idempotent, such as limited to database lookups). You can’t create anything in a stateless system. The “What’s in your Toolkit” chart is pretty bad as a supporting argument for what “simple” means, IMO. Methods vs namespaces functions does not have a meaningful difference in this context; namespacing is an organizational tool, it doesn’t simplify things or protect you from complexity. Data vs Syntax is not a choice in any programming language that exists, all of them have both. Actors vs Queues doesn’t make sense to me, I don’t understand what they were trying to say, and suggesting queues are simpler than actors seems backwards from a game programming perspective. Consistency and Inconsistency are things you can have in any programming language at any level of complexity.
- greymalik 5y ago
  The chart comes from Rich Hickey’s Simple Made Easy presentation. Watching that will provide missing context that may answer some of your questions. https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
- raspasov 5y ago
  Tangled is that which measurably interacts with something else for any practical purposes at the current level of analysis. If there's a function A that does not call function B (and vice versa), they are not tangled. They are separate (assuming the functions are pure, no global shared state, etc). Now we can go down the physics rabbit hole and start arguing that everything is tangled at some level but I don't think that's useful for a discussion at this level of analysis. I think we can stick to the definition that if function A does not call function B, they are completely separate for the purpose of this discussion.
- dgb23 5y ago
  Appreciate the answer! > But we can’t move the notion of time to an element of it’s own. And if we could, and then compose it with an element of value, we’d end up right back where we started with some state. I see this differently. If you compose a timestamp with a value, it is still a value. This is the essence of temporal data modelling and accounting. > You can’t create anything in a stateless system. Agreed. The idea is however to avoid state whenever possible, pushing it to the edges. > Methods vs namespaces functions does not have a meaningful difference in this context Depends on how you use them. Classes and methods can be used as quasi namespaces. The nice thing about namespaces is that they provide you with that one, "simple" thing, while classes and methods are overloaded with semantics and utility. > Data vs Syntax is not a choice in any programming language that exists, all of them have both. The question is the degree. There are languages with minimal syntax that express more via data and there are languages with differing degrees of homoiconicity. I agree with the rest of your critique generally, as in that the context and the assumptions around a given model are typically subjective, we objectively deduce the parts from these assumptions. Say for example from my point of view a given tool might be simple, because I only use it to do that one thing, but you have to use it for that other (maybe intended) purpose as well, so you perceive it as complected.

Would be interesting to read a rebuttal of the presented definition.

by dgb23 5y ago

Would be interesting to read a rebuttal of the presented definition.

I like the definition “Simple means not tangled.” But that definition isn’t objective, it depends on what you think is tangled. The author claims “Simplicity is objective because - if we can distinguish them - we can count how many simpler elements are there, tangled together.” This admits that objectivity depends on distinguishing what the elements are, which is often subjective. So this claim can be seen as false in the sense that you can’t make something objective out of subjective parts, or true in the sense that it’s trying to punt by treating the whole as a separate thing from the elements that comprise it. One good example of subjective elements is the discussion on state - “State is never simple because it complects - tangles - time and value.” I agree with this, but it’s important to note that state does not encode time explicitly. Time and state are byproducts of assignment. We can remove the notion of time (assignment) from some bit of code and make the code functional. But we can’t move the notion of time to an element of it’s own. And if we could, and then compose it with an element of value, we’d end up right back where we started with some state. Generic discussions on state can be hard to parse too since there doesn’t exist a computer program without state. We move it around, organize it in various ways. We hide it with interpreters and compilers. But it’s always there. At a high level, there’s no way to detangle time and value when users and user input are involved. A feedback-response cycle often is state at a fundamental level (unless your program is idempotent, such as limited to database lookups). You can’t create anything in a stateless system. The “What’s in your Toolkit” chart is pretty bad as a supporting argument for what “simple” means, IMO. Methods vs namespaces functions does not have a meaningful difference in this context; namespacing is an organizational tool, it doesn’t simplify things or protect you from complexity. Data vs Syntax is not a choice in any programming language that exists, all of them have both. Actors vs Queues doesn’t make sense to me, I don’t understand what they were trying to say, and suggesting queues are simpler than actors seems backwards from a game programming perspective. Consistency and Inconsistency are things you can have in any programming language at any level of complexity.

greymalik 5y ago
The chart comes from Rich Hickey’s Simple Made Easy presentation. Watching that will provide missing context that may answer some of your questions. https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
raspasov 5y ago
Tangled is that which measurably interacts with something else for any practical purposes at the current level of analysis. If there's a function A that does not call function B (and vice versa), they are not tangled. They are separate (assuming the functions are pure, no global shared state, etc). Now we can go down the physics rabbit hole and start arguing that everything is tangled at some level but I don't think that's useful for a discussion at this level of analysis. I think we can stick to the definition that if function A does not call function B, they are completely separate for the purpose of this discussion.
dgb23 5y ago
Appreciate the answer! > But we can’t move the notion of time to an element of it’s own. And if we could, and then compose it with an element of value, we’d end up right back where we started with some state. I see this differently. If you compose a timestamp with a value, it is still a value. This is the essence of temporal data modelling and accounting. > You can’t create anything in a stateless system. Agreed. The idea is however to avoid state whenever possible, pushing it to the edges. > Methods vs namespaces functions does not have a meaningful difference in this context Depends on how you use them. Classes and methods can be used as quasi namespaces. The nice thing about namespaces is that they provide you with that one, "simple" thing, while classes and methods are overloaded with semantics and utility. > Data vs Syntax is not a choice in any programming language that exists, all of them have both. The question is the degree. There are languages with minimal syntax that express more via data and there are languages with differing degrees of homoiconicity. I agree with the rest of your critique generally, as in that the context and the assumptions around a given model are typically subjective, we objectively deduce the parts from these assumptions. Say for example from my point of view a given tool might be simple, because I only use it to do that one thing, but you have to use it for that other (maybe intended) purpose as well, so you perceive it as complected.