4 ms·

I like the idea of only allowing one expression per switch case.

by dqpb 4y ago

kiliancs 4y ago
I think it's short-sighted. Separation of concerns is not a rule to be applied blindly: it requires understanding that separation also increases the complexity of the system. Deciding where to split, what abstractions to create, is not easy. Naming is hard, and yet here we are required to come up with names for these functions that could perfectly be inlined without any negative consequences. I get that long switch cases get tedious, but the same applies to any piece of code, including a function. I don't think this is a solution, but rather, an annoyance.
- dqpb 4y ago
  > Separation of concerns is not a rule to be applied blindly A switch statement that only calls functions is almost like a state machine transition table (granted not a very good one). Organizing conditional logic into a state machine is an excellent separation of concerns. The state machine becomes essentially an abstract model of your system that says what to do and when to do it, but not the low level details of how to do it. The functions that define how to do it are the refinement of the model. You then have something thats directly mappable to TLA+, which you can use to model check your system.
topaz0 4y ago
Always good to have many little "functions" that modify global variables lying around.
- dqpb 4y ago
  With good organization and model checking, I bet you could write better software in this language than 95% of developers write in popular languages. I agree with Leslie Lamport - the problem is not the programming language, it’s the way you think about systems.
  - topaz0 4y ago
    Thanks for the vote of confidence, but maybe it would be more relevant to ask whether I could write better software in this language than I could in other languages (taking as given good organization and model checking). I agree with your paraphrase of Lamport as far as it goes -- the language will not save you if you don't have a clear model of the problem. But languages are more or less suited to mapping from algorithms to code, and (relatedly) organization of that code.

I like the idea of only allowing one expression per switch case.

by dqpb 4y ago

I like the idea of only allowing one expression per switch case.

I think it's short-sighted. Separation of concerns is not a rule to be applied blindly: it requires understanding that separation also increases the complexity of the system. Deciding where to split, what abstractions to create, is not easy. Naming is hard, and yet here we are required to come up with names for these functions that could perfectly be inlined without any negative consequences. I get that long switch cases get tedious, but the same applies to any piece of code, including a function. I don't think this is a solution, but rather, an annoyance.

dqpb 4y ago
> Separation of concerns is not a rule to be applied blindly A switch statement that only calls functions is almost like a state machine transition table (granted not a very good one). Organizing conditional logic into a state machine is an excellent separation of concerns. The state machine becomes essentially an abstract model of your system that says what to do and when to do it, but not the low level details of how to do it. The functions that define how to do it are the refinement of the model. You then have something thats directly mappable to TLA+, which you can use to model check your system.

topaz0 4y ago

Always good to have many little "functions" that modify global variables lying around.

dqpb 4y ago
With good organization and model checking, I bet you could write better software in this language than 95% of developers write in popular languages. I agree with Leslie Lamport - the problem is not the programming language, it’s the way you think about systems.
- topaz0 4y ago
  Thanks for the vote of confidence, but maybe it would be more relevant to ask whether I could write better software in this language than I could in other languages (taking as given good organization and model checking). I agree with your paraphrase of Lamport as far as it goes -- the language will not save you if you don't have a clear model of the problem. But languages are more or less suited to mapping from algorithms to code, and (relatedly) organization of that code.