3 ms·

Commenting without RTFA considered harmful. TFA talks about passing false instead of true or vice versa.

67726e 12y ago
Commenting without knowing that I read TFA is also considered harmful, but sorry I hit a nerve. I'm sure your Python/Ruby/Node is going to be nice and maintainable for years to come. Let's just hope all of your parameter names are meaningful, because hey, we have no other means to glean what should be passed in.
- cousin_it 12y ago
  The problem is that the type checker won't catch you when you accidentally call foo(true, false) instead of foo(false, true). Using enums is a valid solution, though.
  - 67726e 12y ago
    So you propose a) Having a "boolean" enum which does't solve the problem or having dozens of unique "boolean" enums which is a maintenance nightmare. Instead, I can use my IDE to tell me the names and ordering of parameters, and a type checker to verify everything at compilation. You'll never completely stop the problem of logical errors, and enums are certainly no panacae.
    - cousin_it 12y ago
      I think in languages like ML or Haskell, people are encouraged to be trigger-happy about creating enums with meaningful names for every tiny use case. That's a viable approach because defining a new enum literally takes one line, and working with enums is very natural due to pattern matching. The maintenance nightmare doesn't seem to happen. Though in languages like Java that approach would be much less convenient.
      - 67726e 12y ago
        I can understand that line of thinking, but in given the OP is talking in JS, and and that I've only ever written such languages at Uni or for practice, I don't find them applicable to my day to day. I deal with Java, Scala, JS, and a few other C-style languages. These are how I think and work, these are, and I'm going to assume (make an ass of you and me ;)) that these are what the majority of HNers deal in.
- reinhardt 12y ago
  Unless your magical statically-typed pet language can read your mind and throw compilation error when you mistakenly write "x + y" when you should have "x - y", I'm not sure what your point is.

Commenting without knowing that I read TFA is also considered harmful, but sorry I hit a nerve. I'm sure your Python/Ruby/Node is going to be nice and maintainable for years to come. Let's just hope all of your parameter names are meaningful, because hey, we have no other means to glean what should be passed in.

cousin_it 12y ago
The problem is that the type checker won't catch you when you accidentally call foo(true, false) instead of foo(false, true). Using enums is a valid solution, though.
- 67726e 12y ago
  So you propose a) Having a "boolean" enum which does't solve the problem or having dozens of unique "boolean" enums which is a maintenance nightmare. Instead, I can use my IDE to tell me the names and ordering of parameters, and a type checker to verify everything at compilation. You'll never completely stop the problem of logical errors, and enums are certainly no panacae.
  - cousin_it 12y ago
    I think in languages like ML or Haskell, people are encouraged to be trigger-happy about creating enums with meaningful names for every tiny use case. That's a viable approach because defining a new enum literally takes one line, and working with enums is very natural due to pattern matching. The maintenance nightmare doesn't seem to happen. Though in languages like Java that approach would be much less convenient.
    - 67726e 12y ago
      I can understand that line of thinking, but in given the OP is talking in JS, and and that I've only ever written such languages at Uni or for practice, I don't find them applicable to my day to day. I deal with Java, Scala, JS, and a few other C-style languages. These are how I think and work, these are, and I'm going to assume (make an ass of you and me ;)) that these are what the majority of HNers deal in.
reinhardt 12y ago
Unless your magical statically-typed pet language can read your mind and throw compilation error when you mistakenly write "x + y" when you should have "x - y", I'm not sure what your point is.