5 ms·

Computers are metal but programming languages are for humans. The purpose of functional abstractions is primarily to help humans produce correct code, not neces

by kyllo 12y ago

Computers are metal but programming languages are for humans. The purpose of functional abstractions is primarily to help humans produce correct code, not necessarily to optimize for speed. Referentially transparent functions, immutable data and type checking are meant to provide guarantees that reduce complexity, make a program easier to reason about and help stop the programmer from introducing costly and dangerous bugs. It doesn't matter how fast your "fugly imperative code" is, if it's incorrect. And the lesson we've learned the hard way over and over again is that humans are just not smart enough to reliably write correct fugly imperative code.

kasey_junk 12y ago
I'm not sure I buy your argument, but even if I did, there is no evidence as of yet that says that fugly functional abstractions provide for lower error rates. Further, performance is part of correctness for nearly any real word example.
- DanWaterworth 12y ago
  > 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...

by kyllo 12y ago

kasey_junk 12y ago

I'm not sure I buy your argument, but even if I did, there is no evidence as of yet that says that fugly functional abstractions provide for lower error rates. Further, performance is part of correctness for nearly any real word example.

DanWaterworth 12y ago
> 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...