3 ms·
You're reciting an obfuscated tautology -- hard things are hard. But most things are not hard. Hard things can be dealt with if and when they come up through d
by nknighthb 12y ago
You're reciting an obfuscated tautology -- hard things are hard.
But most things are not hard. Hard things can be dealt with if and when they come up through documentation and training. Dealing with them by making easy things equally hard is silly.
- stcredzero 12y agoYou're reciting an obfuscated tautology -- hard things are hard. Try on this analogy: Moving in deep blizzard conditions is hard. Using vehicles with tracks and skids would make that easier, but that's obviously not a sensible and useful vehicle because it would suck for driving on dry highways. But most things are not hard. Hard things can be dealt with if and when they come up through documentation and training. Dealing with them by making easy things equally hard is silly. You could just as easily apply this reasoning to goto statements. Also to memory management. I'm not saying you don't have a point here -- I'm on board with "the right tool for the job" -- but your analysis could be a bit more nuanced.
- nknighthb 12y agoI don't think you understand what my reasoning is, because it would generally counsel against goto and manual memory management, which are harder tools for solving harder problems, and are usually unnecessary.
- stcredzero 12y agoI don't think you understand what my reasoning is That you shouldn't restrict the use of certain tools/constructs/features in order to make areas like concurrency easier. Apparently you misunderstood my analogy. For one thing, it is an analogy, and not a statement you would use goto and manual memory management. would generally counsel against goto and manual memory management, which are harder tools for solving harder problems, That is a matter of scale. At small scales, "just using a goto" seems easier. It's only at larger scales that it becomes untenable spaghetti, so is harder. Herein is another analogy which can be related to concurrency and parallelism.
- tbrownaw 12y agoHow am I saying that? In-thread control transfers vs in-system IPC vs network links all have very different performance (bandwidth/latency) profiles. The language should not encourage people to conflate them. They behave differently enough that making them indistinguishable is not a sane abstraction. This does not mean that they need to have wildly different interfaces. Just like 'int' and 'double' don't have wildly different interfaces, but your code still needs to specify which it's using.
- nknighthb 12y agoIf you're treating abstractions as black boxes, I can see how you would have a problem. Otherwise, I don't see one. When performance matters, specify/document the performance characteristics of your modules and their deployment proximity requirements. This is hardly unusual, I do it all the time.