3 ms·

mmh, no. Functional programing is declarative, but I does not mean I don't declare utterly wrong and nonsensical things to my compiler. That's why I have not on

by plesn 16y ago

mmh, no. Functional programing is declarative, but I does not mean I don't declare utterly wrong and nonsensical things to my compiler. That's why I have not only a type system, but also testing tools even for pure code: see Quickcheck in Haskell. But, yeah, I often have less state to manage and patterns that avoid a lot of buggy boilerplate.

DanielBMarkham 16y ago
I'd really love it if you would explain yourself a little better. Remember the title is about TDD and functional programming, not about testing in general. Of course you'd still test, and debug, and all the other things involved with programming. If you have more to offer, I'd love to hear it. I couldn't understand what you meant from your comment.
- plesn 16y ago
  FP code can still be in mismatch with your thoughts about it, so functionnal programming does not magically "just work", nor does "it works or it doesn't work" (except in the dumb sense of this sentence which applies to all code). You still write tests even for pure functions to check that certain assumptions hold just like you would in Python, except you also have types to prove certain assumptions. It is not always trivial to see pitfalls in pure code either (think of a complicated function like a parser). Whether you write your tests before or after you write code, you always have a at least one form of testing written (or infered) first: types. And yes, the shape of your code is influenced by your types and your tests (e.g. by making code easily testable with more meaningfull tests/propositions about it).
  - DanielBMarkham 16y ago
    Meh. I'm not buying it. I never said it was trivial. And when I said it works or doesn't work, the implication was that transforms more naturally map to requirements, not that the requirements are always understood. I guess I could have written a more complicated article full of all of these caveats, but I'm happy that testing and developing functional code is much different than imperative. Things like parsers and ASTs are more complex concepts, sure, but they are common concepts that leave little room for doubt. I think data structures become much more important in FP for some of the reasons you've outlined. Hence my comment that those OOP skills and Codd comes in handy. This is also why used the SQL example. But thanks for clarifying yourself. At least now I know that I disagree with you and you misunderstood the article, instead of just wondering wtf you were talking about. I'll make a note on the article to help clear up this confusion.
    - plesn 16y ago
      Ok, so I (think I) agree with you that the following poperties make it compelling to test/develop/refactor code: purity / statelessness, algebraic properties of programs (transforms…), high level (brevity). Where I (think I) disagree, is that I think methodology stays globally the same: I would even say that it desn't throw away TDD but gives tools to reinforce it. FP removes whole classes of nasty bugs and so it makes you test more essential stuff ; secondly the tools help you more because the compiler and the testing library know more, so for example in Haskell statistical tests are easy to write, pervasive, and often very meaningfull.
      - DanielBMarkham 16y ago
        I really like your statistical testing example. I haven't seen a lot in the agile community about statistical testing, but in data transformation-like code, as you say, it can be very meaningful.

by plesn 16y ago

DanielBMarkham 16y ago

I'd really love it if you would explain yourself a little better. Remember the title is about TDD and functional programming, not about testing in general. Of course you'd still test, and debug, and all the other things involved with programming. If you have more to offer, I'd love to hear it. I couldn't understand what you meant from your comment.

plesn 16y ago
FP code can still be in mismatch with your thoughts about it, so functionnal programming does not magically "just work", nor does "it works or it doesn't work" (except in the dumb sense of this sentence which applies to all code). You still write tests even for pure functions to check that certain assumptions hold just like you would in Python, except you also have types to prove certain assumptions. It is not always trivial to see pitfalls in pure code either (think of a complicated function like a parser). Whether you write your tests before or after you write code, you always have a at least one form of testing written (or infered) first: types. And yes, the shape of your code is influenced by your types and your tests (e.g. by making code easily testable with more meaningfull tests/propositions about it).
- DanielBMarkham 16y ago
  Meh. I'm not buying it. I never said it was trivial. And when I said it works or doesn't work, the implication was that transforms more naturally map to requirements, not that the requirements are always understood. I guess I could have written a more complicated article full of all of these caveats, but I'm happy that testing and developing functional code is much different than imperative. Things like parsers and ASTs are more complex concepts, sure, but they are common concepts that leave little room for doubt. I think data structures become much more important in FP for some of the reasons you've outlined. Hence my comment that those OOP skills and Codd comes in handy. This is also why used the SQL example. But thanks for clarifying yourself. At least now I know that I disagree with you and you misunderstood the article, instead of just wondering wtf you were talking about. I'll make a note on the article to help clear up this confusion.
  - plesn 16y ago
    Ok, so I (think I) agree with you that the following poperties make it compelling to test/develop/refactor code: purity / statelessness, algebraic properties of programs (transforms…), high level (brevity). Where I (think I) disagree, is that I think methodology stays globally the same: I would even say that it desn't throw away TDD but gives tools to reinforce it. FP removes whole classes of nasty bugs and so it makes you test more essential stuff ; secondly the tools help you more because the compiler and the testing library know more, so for example in Haskell statistical tests are easy to write, pervasive, and often very meaningfull.
    - DanielBMarkham 16y ago
      I really like your statistical testing example. I haven't seen a lot in the agile community about statistical testing, but in data transformation-like code, as you say, it can be very meaningful.