4 ms·

This is just not true. Many simple lines are easier to read than fewer more complex lines. It's hard to miss a bug in x = x + 1 foo[x] But easier to

by NateDad 12y ago

This is just not true. Many simple lines are easier to read than fewer more complex lines. It's hard to miss a bug in x = x + 1 foo[x] But easier to miss a bug in foo[x++]

kasey_junk 12y ago
As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless. That said, I'd add 3 points to this particular thread: 1) You cherry picked one of the most confusing uses of operators (and sources of bugs) that we have. If it weren't so ingrained in our educations/history (and so useful for old fashioned looping semantics) I think we all would have moved on from ++ syntax a long time ago. 2) As flawed as it is, it is a well studied phenomenon that LoC is nearly the only measurable statistic we have that is predictive of error rates (that is higher LoC solutions tend to have higher bug counts). 3) The bigger point about looping constructs isn't about LoC in any case. It is de-coupling 2 different areas of code responsibility. One is the mechanics of iteration and the other is what to do on each event. At the end of the day most looping constructs end up being sugar around while loops anyway, so the reductionist argument is all of it is unnecessary complication, just do everything in a while loop.
- Retra 12y ago
  > As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless. I don't know why people keep saying this. We write code to solve problems. The best code solves the most problems in the most correct and efficient ways. Regardless of your measure of efficiency, if someone cannot quickly tell if your code is correct, does what is intended, and does or does not apply to their problem, then the code isn't good. That's your measure: Can the people who want to solve the problem you are trying to solve efficiently identify, evaluate, and employ your attempted solution?
  - kasey_junk 12y ago
    Nothing in your measure can actually be "measured". That is given 2 different solutions to the same problem, how do you determine which is better? The reason people keep saying that we don't have any measures that do this, is that it is a bafflingly tricky problem that has been studied for decades with hardly any forward progress, and lies at the heart of most of the big issues in our industry.
    - Retra 12y ago
      What makes you think it can't be measured? Just because we don't have the infrastructure to do it doesn't mean it can't be done. >The reason people keep saying that we don't have any measures that do this, is that it is a bafflingly tricky problem that has been studied for decades with hardly any forward progress And what if I had a solution? How does this comment help anything? What do you think the difference is between unsolved and unsolvable, and how does your reaction not foolishly apply to both? How would you recognize progress in the context of my post? Here's a Haskell factorial function: -- Basic factorial function. fac :: Integer -> Integer fac n = product [1..n] Here's an attempt at a factorial function in another language: .r $15265f38a [] (44) ; dup n + offset; _ Which is better code? Do they both compute a factorial? Do they both terminate? How did you determine this without using any 'measurable' data?
      - kasey_junk 12y ago
        >I don't know why people keep saying this. What I'm getting at is that determining which of 2 pieces of code are better is one of the biggest open question in the computer science/software industry. Further, it has been widely studied for a long time and across a wide variety of measurements and contexts, yet remains an open question. If you have a measure that can be systematically reproduced by anyone for any 2 pieces of code that purport to solve the same problem, that would be a huge breakthrough worthy of wide publication and probable riches. If you can make that machinable (even given caveats around provably impossible things like the halting problem) you could literally transform the entire industry.
        12y ago

by NateDad 12y ago

This is just not true. Many simple lines are easier to read than fewer more complex lines. It's hard to miss a bug in x = x + 1 foo[x] But easier to miss a bug in foo[x++]

kasey_junk 12y ago

As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless. That said, I'd add 3 points to this particular thread: 1) You cherry picked one of the most confusing uses of operators (and sources of bugs) that we have. If it weren't so ingrained in our educations/history (and so useful for old fashioned looping semantics) I think we all would have moved on from ++ syntax a long time ago. 2) As flawed as it is, it is a well studied phenomenon that LoC is nearly the only measurable statistic we have that is predictive of error rates (that is higher LoC solutions tend to have higher bug counts). 3) The bigger point about looping constructs isn't about LoC in any case. It is de-coupling 2 different areas of code responsibility. One is the mechanics of iteration and the other is what to do on each event. At the end of the day most looping constructs end up being sugar around while loops anyway, so the reductionist argument is all of it is unnecessary complication, just do everything in a while loop.

Retra 12y ago
> As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless. I don't know why people keep saying this. We write code to solve problems. The best code solves the most problems in the most correct and efficient ways. Regardless of your measure of efficiency, if someone cannot quickly tell if your code is correct, does what is intended, and does or does not apply to their problem, then the code isn't good. That's your measure: Can the people who want to solve the problem you are trying to solve efficiently identify, evaluate, and employ your attempted solution?
- kasey_junk 12y ago
  Nothing in your measure can actually be "measured". That is given 2 different solutions to the same problem, how do you determine which is better? The reason people keep saying that we don't have any measures that do this, is that it is a bafflingly tricky problem that has been studied for decades with hardly any forward progress, and lies at the heart of most of the big issues in our industry.
  - Retra 12y ago
    What makes you think it can't be measured? Just because we don't have the infrastructure to do it doesn't mean it can't be done. >The reason people keep saying that we don't have any measures that do this, is that it is a bafflingly tricky problem that has been studied for decades with hardly any forward progress And what if I had a solution? How does this comment help anything? What do you think the difference is between unsolved and unsolvable, and how does your reaction not foolishly apply to both? How would you recognize progress in the context of my post? Here's a Haskell factorial function: -- Basic factorial function. fac :: Integer -> Integer fac n = product [1..n] Here's an attempt at a factorial function in another language: .r $15265f38a [] (44) ; dup n + offset; _ Which is better code? Do they both compute a factorial? Do they both terminate? How did you determine this without using any 'measurable' data?
    - kasey_junk 12y ago
      >I don't know why people keep saying this. What I'm getting at is that determining which of 2 pieces of code are better is one of the biggest open question in the computer science/software industry. Further, it has been widely studied for a long time and across a wide variety of measurements and contexts, yet remains an open question. If you have a measure that can be systematically reproduced by anyone for any 2 pieces of code that purport to solve the same problem, that would be a huge breakthrough worthy of wide publication and probable riches. If you can make that machinable (even given caveats around provably impossible things like the halting problem) you could literally transform the entire industry.
      - 12y ago