5 ms·

> there is no evidence as of yet that says that fugly functional abstractions provide for lower error rates. Sure there is. Compare the incidence of buffer ove

> there is no evidence as of yet that says that fugly functional abstractions provide for lower error rates. Sure there is. Compare the incidence of buffer overflows in C programs vs Haskell ones. > performance is part of correctness for nearly any real word example. No it's not. See the definition of correctness [1]. [1] http://en.wikipedia.org/wiki/Correctness_%28computer_science%29 http://en.wikipedia.org/wiki/Correctness_%28computer_science...

dragonwriter 12y ago
In most real world software, performance constraints are part of the specification, and thus, performance is part of correctness by the definition you cite. (And where they aren't part of the formal specification, it often is later discovered that that was simply a failure of requirements gathering/analysis, in that the specification did not completely capture the expectations of the entity that the software was being built for.)
- kyllo 12y ago
  What you're saying is that performance constraints are often part of the business requirements. Business requirements are not the same thing as program correctness.
  - kasey_junk 12y ago
    Ok, if you are going to be pedantic about it, you need to go back to your original claim about it not being important how fast your code is if it isn't correct. Proving something is partially correct is not important, if the program in question doesn't provide an answer in the required timeframe.
    - kyllo 12y ago
      Also true, and that's when you need to optimize your code, which sometimes means doing away with abstractions that are slowing it down, which can mean replacing elegant functional code with fugly imperative code like the OP discusses. But then after you optimize it to meet the business requirements on speed and size, it still needs to be correct. And of course, while we're talking about business requirements, there is always project speed and budget size to account for. When optimizing for program running time and memory cost, you don't want to blow up the project's running time and dollar cost. Productivity is a huge reason why abstractions need to exist.
kasey_junk 12y ago
"Compare the incidence of buffer overflows in C programs vs Haskell ones." It's true that 1 particular instance of a functional language removes 1 particular class of problems from another non functional language. But there is no evidence that these error rates are lower in general because other classes of errors creep in. For instance, space leaks due to laziness are a class of error you are unlikely to encounter in C, but are common in Haskell.
- kyllo 12y ago
  Sure, but in C you get memory leaks due to simply forgetting to call free...

dragonwriter 12y ago

In most real world software, performance constraints are part of the specification, and thus, performance is part of correctness by the definition you cite. (And where they aren't part of the formal specification, it often is later discovered that that was simply a failure of requirements gathering/analysis, in that the specification did not completely capture the expectations of the entity that the software was being built for.)

kyllo 12y ago
What you're saying is that performance constraints are often part of the business requirements. Business requirements are not the same thing as program correctness.
- kasey_junk 12y ago
  Ok, if you are going to be pedantic about it, you need to go back to your original claim about it not being important how fast your code is if it isn't correct. Proving something is partially correct is not important, if the program in question doesn't provide an answer in the required timeframe.
  - kyllo 12y ago
    Also true, and that's when you need to optimize your code, which sometimes means doing away with abstractions that are slowing it down, which can mean replacing elegant functional code with fugly imperative code like the OP discusses. But then after you optimize it to meet the business requirements on speed and size, it still needs to be correct. And of course, while we're talking about business requirements, there is always project speed and budget size to account for. When optimizing for program running time and memory cost, you don't want to blow up the project's running time and dollar cost. Productivity is a huge reason why abstractions need to exist.

kasey_junk 12y ago

"Compare the incidence of buffer overflows in C programs vs Haskell ones." It's true that 1 particular instance of a functional language removes 1 particular class of problems from another non functional language. But there is no evidence that these error rates are lower in general because other classes of errors creep in. For instance, space leaks due to laziness are a class of error you are unlikely to encounter in C, but are common in Haskell.

kyllo 12y ago
Sure, but in C you get memory leaks due to simply forgetting to call free...