Comments by "MrAbrazildo" (@MrAbrazildo) on "Declarative vs Imperative in Functional Programming" video.

  1. I guess by now everybody understood TDD is good. You should now become more technical. Let's say I have a f() that makes several steps to reach a goal. It has several steps because they are private to it, they would not make sense outside of it - it could be prone to errors if called outside . And that f() also updates variables in other classes, because otherwise this should be scheduled to do later, and before some certain other actions take place - and would be prone to errors too, if this schedule fails to complete or, in worse cases, fails to follow a certain order too . By what I understood so far, TDD would demand that a f(), which would be written like that, be splitted in several small f()s. So, to avoid a disaster, I think 2 possible solutions: a) Each f() like this should become a class, with all those private steps being private f()s from it. Tests would have plenty of access to those f()s, most of them not tagged as 'const'. Fortunately, tests are small, and compile-time prone to be implemented. So, tests are unlikely to cause bugs - and easy to fix if that happens. Pros: each test would be executed only 1 time . Cons: kind of a "risky" design . b) Any f() like this stays the same, but its steps could become lambdas, in order to be tested, and this would be made inside that "big f()", each time anyone calls it. To avoid repeated tests execution (hence consuming performance), they could only communicate in case of failing. Since they are compile-time (according to your examples), the optimizer could solve them, realizing that they work, meaning they would do nothing, and then it could decide to eliminate them at compile-time, "because they are useless" (unreachable code). For the tests that accuse an error, the programmer should fix them right away, in order to them become potentially "useless" too - thus eliminated too. Pros: design continues to be as safe as before, despite tests intrusion . Cons: tests would be processed several times, unless the optimizer decides to wipe them out .
    1