Comments by "MrAbrazildo" (@MrAbrazildo) on "You're Not Qualified To Have An Opinion On TDD | Prime Reacts" video.

  1. 0:59, no fun? It's awesome! 10:33, I watched a presentation in which some dude said his team failed badly with Haskell. And if we add to that the Haskell motto, "Fail at all cost!" , we can assume many had tried... and failed badly! I can imagine why: there's an obsession about pure f()s. The real world needs don't embrace that, most of the time. So 1 has to update variables outside the already precarious encapsulation of a f(), to fulfill the side-effect needs, so avoided by the language. Thus, everything becomes periculous. The disaster is just a matter of time. 12:50, what does that mean? Once you used htmx, you just use it, without an opinion? The perfect pragmatic tool?
    1
  2. ​ @digitalspecter If variables should not be created, everything could be pure f()s. But there are reasons why things once obtained should be memorized: either performance (expensive to get them again), tied 1 to another (need to be changed together), and so on. Depending on the project complexity, there's not much space for pure f()s. i.e. if you turn the head of character in a videogame, changing his angle of view, even if not changing anything in the game, variables x,y,z need to change in some place, and memorized, because they'll be asked later. Now imagine if you split the f(), which calculate changes, to make it pure, letting the variables attribution for another place. So we have the calculating and the changing f()s: Pros: - Code become more conceptual, where more actions have a name. - 1 can shine in Haskell community, by making more elegant code. Cons: - Looses encapsulation: things that could better fit in 1 f() are now scattered in 2 or more f()s. - Harder to debug: more places to look. It's needed to look the production of the value (pure f()) and also the attribution. They should be 1. - Even worse: the rest of the project can now see and call those new f()s (btw, C++ allows the user to forbid that) . I'm not advocating to have less f()s. But create them just to feed the Haskell utopian idea to has a "pure project" is bad, dangerous, even prone to disaster!
    1