4 ms·

I wasn't saying there can't be a good way to put a feature to use. And, like any programmer that is maintaining a level of pride, I'm aware I am constantly look

I wasn't saying there can't be a good way to put a feature to use. And, like any programmer that is maintaining a level of pride, I'm aware I am constantly looking for reasons why certain features aren't needed or are even bad in the global picture, at least in a given context. Looking for a minimal set of axioms to build the world on does make sense. Language feature can be seen as axioms in the sense that it's hard or impossible to break them down, since they're hidden in the compiler. Regarding OOP syntax specifically, let us agree that it is a question of religion if writing foo.bar() instead of foo_bar(foo) is really a huge saving of work. There are numerous counter-arguments (language-specific ones as well as more general ones) why it could be not, and could in fact be detrimental. I disagree with the view that using any feature to quickly get something done leaves more time to make the program better. In my view, less focus on syntactic superficialities like OOP method syntax, and premature optimizations like using std::sort, leaves more time to focus on what really matters, to understand what a program does and needs to do on a global scale, and it holds me back less waiting for slow builds. All of that is pretty subjective, and there are certainly good examples for many different approaches, and naturally one is most familiar with those that one likes personally. The important thing is to be happy and be / feel productive.

ncmncm 4y ago
OOP is absolutely not about syntax. At all. The differing syntax is nothing but a visual clue, for benefit of readers, that some late binding might be going on. Literally anything that takes your attention necessarily takes it away from something else. Anything that does not need your attention anymore frees it up for important things you now have more time for. That is true for everyone, unless you waste it on looking at cat pictures (or, here) instead. Failure to understand the uses and consequences of unfamiliar language features is not a virtue. Every single line of code anyone writes does not use almost all features of a language. All that is different in your case is failure to use features in those places where using them correctly would have made your code better. The important thing is good code. If your code is not improving, you short-change yourself.
- jstimpfle 4y ago
  I often like your comments but sometimes not. Here I would definitely downvote if I could, let me explain why. - You are disagreeing with me on things I did not say and that were not the subject of discussion. ("OOP is not about syntax") - You are "teaching" me, from a high point, quite arrogantly. I'm particularly irritated by this: "The important thing is good code. If your code is not improving, you short-change yourself." Suggesting I am not improving, and giving commonplace advice as if I wouldn't realize that. - You're suggesting a "failure" of mine to take an appropriate action, without an existing situation to judge. - You are disagreeing with something I said and that I made an effort to create a reasonable argument for, but you're not presenting a counter-argument and instead are just repeating what you said before. - While I think you might be super smart, I feel it was altogether a low quality comment of yours with little grounding in reason. Let me go back to this: "Failure to understand the uses and consequences of unfamiliar language features is not a virtue". Not that I ever claimed it was. Conversely, do you think that understanding the uses and consequences of all or most language features is a virtue? Do you think tools matter over results? Do you think a mathematical theory is more beautiful if you introduce more concepts than necessary to elegantly transport the message? Do you agree that features have a utility but also a cost? Can you see how writing a piece of code using a new feature creates new interactions and complexities with the rest of the code (including seemingly unrelated parts), producing new headaches? (easy examples: isn't it enough to use functions? Why should I use methods, creating new problems when I need to take a function pointer and making it harder to find places of usage? Why should I use private methods, when there is no good reason to declare them in the header in the first place (static functions in the implementation file are just fine!) especially if this exposes implementation details?) Do I have to apologize that while there might be theoretically ways to accommodate uses of many different features, I'm simply not willing to invest the effort to figure those out - effort that I'm not sinking into problems that I'm more interested in? I simply don't feel like the programming language I use (I like C) is holding me back from what I'm interested in doing.
  - ncmncm 4y ago
    First: I apologize for my tone. You did not deserve to be talked down to. In answer to questions. Yes, it is a virtue to understand more language features, even in languages one doesn't use. Nobody understands all features in all languages. Many think they understand features they do not. (It appears, by your remarks, that you do not understand features that support OOP, so cannot reason reliably about their potential value for particular cases.) A program using more powerful features, where they contribute something useful, will be shorter and clearer, and offer less scope for mistakes, than one with the same semantics cobbled together from low-level primitives. Anyone reading the latter has to dig down to see whether it really attempts what it seems to, and really does what it attempts. There are no such doubts about standard features. A proof that relies on previously proven results is usually considered more elegant, but one that relies more on axioms may have more generality, which is also desired. The analogy to code would be a program relying on fewer third-party libraries, making it more portable and less fragile. That reasoning would not apply to language features, which are more akin to axioms. (Euclid proved as much as he could without using the fifth axiom, which turned out millennia later to make those results applicable in spherical and hyperbolic geometry. This does not seem analogous to anything on-topic.) Do features have a cost? Everything costs, so the cost of one choice can only be compared to the cost of another. Some costs are borne once, e.g. learning a feature. Some cost at build time. Some cost at runtime. We need to know which is which. Any abstraction used imposes the cost of knowing its domain, and, where that is limited, ensuring each use entirely fits in it. This cost is balanced against the load of extra detail exposed in not using it. Results and tools are not at odds. Results include more than program output; the program itself is a result. Drawing upon the full suite of available tools produces better results. A screwdriver handle might substitute for a hammer, but it is not a thing to brag on. Using a feature that doesn't contribute anything is just flailing. Everything in a program should bring it closer to achieving its goals. Not knowing to use a feature where it would have helped is paying a cost in every such case just to avoid the one-time cost of learning the feature, generally without even knowing we are paying it. Features are added to languages always against enormous resistance. Any that make it in have passed the test of making important programs better. Not learning an available feature has the consequence of not knowing where using it would have made one's program better. Not using a feature because you don't understand it is very different from not using the same feature because you have adjudged that it adds not enough value. Our tools affect us more than we imagine. What we are interested in doing is always affected by what we know how to do, or know can be done. We attempt more if we know more. Attention is always the scarcest resource. Spending it learning language features takes it away from other things. But learning language features is an investment that pays back anywhere the feature might be useful, even where we don't end up using it.

ncmncm 4y ago

OOP is absolutely not about syntax. At all. The differing syntax is nothing but a visual clue, for benefit of readers, that some late binding might be going on. Literally anything that takes your attention necessarily takes it away from something else. Anything that does not need your attention anymore frees it up for important things you now have more time for. That is true for everyone, unless you waste it on looking at cat pictures (or, here) instead. Failure to understand the uses and consequences of unfamiliar language features is not a virtue. Every single line of code anyone writes does not use almost all features of a language. All that is different in your case is failure to use features in those places where using them correctly would have made your code better. The important thing is good code. If your code is not improving, you short-change yourself.

jstimpfle 4y ago
I often like your comments but sometimes not. Here I would definitely downvote if I could, let me explain why. - You are disagreeing with me on things I did not say and that were not the subject of discussion. ("OOP is not about syntax") - You are "teaching" me, from a high point, quite arrogantly. I'm particularly irritated by this: "The important thing is good code. If your code is not improving, you short-change yourself." Suggesting I am not improving, and giving commonplace advice as if I wouldn't realize that. - You're suggesting a "failure" of mine to take an appropriate action, without an existing situation to judge. - You are disagreeing with something I said and that I made an effort to create a reasonable argument for, but you're not presenting a counter-argument and instead are just repeating what you said before. - While I think you might be super smart, I feel it was altogether a low quality comment of yours with little grounding in reason. Let me go back to this: "Failure to understand the uses and consequences of unfamiliar language features is not a virtue". Not that I ever claimed it was. Conversely, do you think that understanding the uses and consequences of all or most language features is a virtue? Do you think tools matter over results? Do you think a mathematical theory is more beautiful if you introduce more concepts than necessary to elegantly transport the message? Do you agree that features have a utility but also a cost? Can you see how writing a piece of code using a new feature creates new interactions and complexities with the rest of the code (including seemingly unrelated parts), producing new headaches? (easy examples: isn't it enough to use functions? Why should I use methods, creating new problems when I need to take a function pointer and making it harder to find places of usage? Why should I use private methods, when there is no good reason to declare them in the header in the first place (static functions in the implementation file are just fine!) especially if this exposes implementation details?) Do I have to apologize that while there might be theoretically ways to accommodate uses of many different features, I'm simply not willing to invest the effort to figure those out - effort that I'm not sinking into problems that I'm more interested in? I simply don't feel like the programming language I use (I like C) is holding me back from what I'm interested in doing.
- ncmncm 4y ago
  First: I apologize for my tone. You did not deserve to be talked down to. In answer to questions. Yes, it is a virtue to understand more language features, even in languages one doesn't use. Nobody understands all features in all languages. Many think they understand features they do not. (It appears, by your remarks, that you do not understand features that support OOP, so cannot reason reliably about their potential value for particular cases.) A program using more powerful features, where they contribute something useful, will be shorter and clearer, and offer less scope for mistakes, than one with the same semantics cobbled together from low-level primitives. Anyone reading the latter has to dig down to see whether it really attempts what it seems to, and really does what it attempts. There are no such doubts about standard features. A proof that relies on previously proven results is usually considered more elegant, but one that relies more on axioms may have more generality, which is also desired. The analogy to code would be a program relying on fewer third-party libraries, making it more portable and less fragile. That reasoning would not apply to language features, which are more akin to axioms. (Euclid proved as much as he could without using the fifth axiom, which turned out millennia later to make those results applicable in spherical and hyperbolic geometry. This does not seem analogous to anything on-topic.) Do features have a cost? Everything costs, so the cost of one choice can only be compared to the cost of another. Some costs are borne once, e.g. learning a feature. Some cost at build time. Some cost at runtime. We need to know which is which. Any abstraction used imposes the cost of knowing its domain, and, where that is limited, ensuring each use entirely fits in it. This cost is balanced against the load of extra detail exposed in not using it. Results and tools are not at odds. Results include more than program output; the program itself is a result. Drawing upon the full suite of available tools produces better results. A screwdriver handle might substitute for a hammer, but it is not a thing to brag on. Using a feature that doesn't contribute anything is just flailing. Everything in a program should bring it closer to achieving its goals. Not knowing to use a feature where it would have helped is paying a cost in every such case just to avoid the one-time cost of learning the feature, generally without even knowing we are paying it. Features are added to languages always against enormous resistance. Any that make it in have passed the test of making important programs better. Not learning an available feature has the consequence of not knowing where using it would have made one's program better. Not using a feature because you don't understand it is very different from not using the same feature because you have adjudged that it adds not enough value. Our tools affect us more than we imagine. What we are interested in doing is always affected by what we know how to do, or know can be done. We attempt more if we know more. Attention is always the scarcest resource. Spending it learning language features takes it away from other things. But learning language features is an investment that pays back anywhere the feature might be useful, even where we don't end up using it.