3 ms·

I was wondering which of the examples you think particular fall into this category of making the code more opaque? I actually went into this with similar misgi

I was wondering which of the examples you think particular fall into this category of making the code more opaque? I actually went into this with similar misgivings. A lot of "get rid of ifs" advice, particularly from OOP people ends up making things more complex IMO. However most of the advice other than the "Switch to Polymorphism" seem very down to earth and a simplification. Less about getting rid of ifs as if their mere presence was a stain on humanity and more how to rewrite what they are doing more clearly.

d--b 8y ago
Sorry I answered as a top level comment. Im on my phone
- meheleventyone 8y ago
  No problem! It seems that the issue is less that the code is made more opaque but that you can quickly think of some counter-examples or nitpicks that make the advice less valid to you? I think the problem of not being universal is true of most programming advice. So I don't necessarily see it as a reason to discount it. I also think in contrast to a lot of articles the author has done a great job to couch their advice as being contextual. For example for your criticism of Pattern 4 the author does actually point out the obvious solution to these complex expressions. To split them out into several parts. Which is what you get with if statements to an extent but spread out much more with a lot of clutter. Some of your criticism also seems to be based on a misreading of the authors intent. For example Pattern 5 where the goal isn't to remove the if statement but prevent having to repeat the same error checking pattern everywhere.
  - d--b 8y ago
    Well despite a few sentences like “remember, if statements are not all bad”, the author still makes a case that if statements are generally to be avoided. My point is that this in itself is bad advice. Overuse of oop concepts is just as harmful (if not more) as overuse of if statements.
    - meheleventyone 8y ago
      Overuse of anything is generally harmful (since it suggests doing too much of it) otherwise it would just be use! But I'm fairly convinced the author isn't saying that they are to be generally avoided, to quote directly: > If statements usually make your code more complicated. But we don’t want to outright ban them. I’ve seen some pretty heinous code created with the goal of removing all traces of if statements. We want to avoid falling into that trap.
    - hellofunk 8y ago
      > Overuse of oop concepts is just as harmful The author's examples are not all about oop -- many of them having nothing to do with oop, they are just good advice for clean code in general.
phaedrus 8y ago
I still "believe in" OOP, but there's something that is increasingly troubling me lately: I keep thinking about the difference between the unbounded set of possible derived classes which could be substituted for a base class, versus the small (probably 1-3) number of different actual implementations are ever used in a real program. It seems like this disparity indicates the mechanism we're using is overly general. Maybe this is an argument for Sum Types as opposed to runtime polymorphism. It seems the biggest thing OOP polymorphism has going for it is that it is "open", that is, the possible derived classes need not be known in advance. But, the fact that our toolchains use a separate link step, and that linkers remain primitive and link-time code generation is not widespread, is merely an historical accident. There's no a priori reason things have to be this way. For example, an alternative would be if all of the source for an executable were in a single image file a la Smalltalk, and compilation consisted of converting this "database of code" into a single executable (no shared libraries!) in one big-bang compilation step (no object files, no static libraries!) You could even have something which syntactically resembled open polymorphism, maybe even using existing languages almost as-is, but instead of compiling down to type erasure and dynamic pointer casts, would compile down to Sum Types (variants). (The compiler could scan the image to find all of the derived types it could be and could construct a variant out of that.) I'm not saying this is better, just putting it forth as an example of how things could be radically different than they are now (even for statically typed, compiled languages), had we made different choices. Consider the alternative, the situation we have now: we use a technique which could support anywhere from 1 to infinity polymorphic derived classes to implement interfaces which probably have approximately 2 different implementations in a typical finished program. Perhaps an analogy would help: If we approached hardware the way we approach software, we would be using connectors which support between 1 and infinity pins everywhere when connectors which support N pins would suffice.
- meheleventyone 8y ago
  I didn’t mean to do down OOP. I think there are a lot of useful concepts to be had looking at it. Polymorphism for extension is definitely one of those. It’s more a lot of the more ‘interesting’ takes I’ve seen to replace ifs come from that direction and seem to be an exercise in decreasing complexity in the small (easier to understand methods) whilst increasing it a lot in the large (harder to understand architecture). Your idea of replacing polymorphic variants with sum types sounds interesting. It also strikes me as quite similar to compile time polymorphism (e.g. generics) where you are 1 to infinity in the design space but the generated program boils down to only the variants created. Language wise I really like the mix of sum types, traits and generics in Rust.

d--b 8y ago

Sorry I answered as a top level comment. Im on my phone

meheleventyone 8y ago
No problem! It seems that the issue is less that the code is made more opaque but that you can quickly think of some counter-examples or nitpicks that make the advice less valid to you? I think the problem of not being universal is true of most programming advice. So I don't necessarily see it as a reason to discount it. I also think in contrast to a lot of articles the author has done a great job to couch their advice as being contextual. For example for your criticism of Pattern 4 the author does actually point out the obvious solution to these complex expressions. To split them out into several parts. Which is what you get with if statements to an extent but spread out much more with a lot of clutter. Some of your criticism also seems to be based on a misreading of the authors intent. For example Pattern 5 where the goal isn't to remove the if statement but prevent having to repeat the same error checking pattern everywhere.
- d--b 8y ago
  Well despite a few sentences like “remember, if statements are not all bad”, the author still makes a case that if statements are generally to be avoided. My point is that this in itself is bad advice. Overuse of oop concepts is just as harmful (if not more) as overuse of if statements.
  - meheleventyone 8y ago
    Overuse of anything is generally harmful (since it suggests doing too much of it) otherwise it would just be use! But I'm fairly convinced the author isn't saying that they are to be generally avoided, to quote directly: > If statements usually make your code more complicated. But we don’t want to outright ban them. I’ve seen some pretty heinous code created with the goal of removing all traces of if statements. We want to avoid falling into that trap.
  - hellofunk 8y ago
    > Overuse of oop concepts is just as harmful The author's examples are not all about oop -- many of them having nothing to do with oop, they are just good advice for clean code in general.

phaedrus 8y ago

I still "believe in" OOP, but there's something that is increasingly troubling me lately: I keep thinking about the difference between the unbounded set of possible derived classes which could be substituted for a base class, versus the small (probably 1-3) number of different actual implementations are ever used in a real program. It seems like this disparity indicates the mechanism we're using is overly general. Maybe this is an argument for Sum Types as opposed to runtime polymorphism. It seems the biggest thing OOP polymorphism has going for it is that it is "open", that is, the possible derived classes need not be known in advance. But, the fact that our toolchains use a separate link step, and that linkers remain primitive and link-time code generation is not widespread, is merely an historical accident. There's no a priori reason things have to be this way. For example, an alternative would be if all of the source for an executable were in a single image file a la Smalltalk, and compilation consisted of converting this "database of code" into a single executable (no shared libraries!) in one big-bang compilation step (no object files, no static libraries!) You could even have something which syntactically resembled open polymorphism, maybe even using existing languages almost as-is, but instead of compiling down to type erasure and dynamic pointer casts, would compile down to Sum Types (variants). (The compiler could scan the image to find all of the derived types it could be and could construct a variant out of that.) I'm not saying this is better, just putting it forth as an example of how things could be radically different than they are now (even for statically typed, compiled languages), had we made different choices. Consider the alternative, the situation we have now: we use a technique which could support anywhere from 1 to infinity polymorphic derived classes to implement interfaces which probably have approximately 2 different implementations in a typical finished program. Perhaps an analogy would help: If we approached hardware the way we approach software, we would be using connectors which support between 1 and infinity pins everywhere when connectors which support N pins would suffice.

meheleventyone 8y ago
I didn’t mean to do down OOP. I think there are a lot of useful concepts to be had looking at it. Polymorphism for extension is definitely one of those. It’s more a lot of the more ‘interesting’ takes I’ve seen to replace ifs come from that direction and seem to be an exercise in decreasing complexity in the small (easier to understand methods) whilst increasing it a lot in the large (harder to understand architecture). Your idea of replacing polymorphic variants with sum types sounds interesting. It also strikes me as quite similar to compile time polymorphism (e.g. generics) where you are 1 to infinity in the design space but the generated program boils down to only the variants created. Language wise I really like the mix of sum types, traits and generics in Rust.