From 03416b1f02644c34a77fe3aa0c43e786ade30dd6 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Thu, 5 Mar 2020 10:56:03 -0300 Subject: [PATCH] Updated some wording in the FRP post --- .../books/functional-reactive-programming.md | 60 +++++++++++-------- 1 file changed, 35 insertions(+), 25 deletions(-) diff --git a/content/reviews/books/functional-reactive-programming.md b/content/reviews/books/functional-reactive-programming.md index 3067faa..fb5729e 100644 --- a/content/reviews/books/functional-reactive-programming.md +++ b/content/reviews/books/functional-reactive-programming.md @@ -21,42 +21,52 @@ features and less time fixing problems. {{ stars(stars=0) }} -* (-) Some phrase constructions are a bit hard to read. Maybe it's because I'm - not a native English speaker, but some phrases are akin to "my beautiful - nature photos", which you can read in different ways ("my beautiful - photos of nature", "my photos of beautiful nature") and I had to backtrack - and read the whole thing again. -* (-) Code is a mess. Long listings with no separation of concerns. I mean, - ok, you can use lambdas for simpler functions, but when you keep piling - lambdas over lambdas, things get a bit out of hand. Trying to explain - some functionality in a 200 line function is not actually helpful. +* (-) Some phrases are a bit hard to read. Maybe it's because I'm + not a native English speaker[^1], but some are akin to "my beautiful + nature photos", which you can read in different ways ("my beautiful photos + of nature", "my photos of beautiful nature") and I had to backtrack and + read the whole thing again. +* (-) Code listings are a mess: long and with no separation of concerns. It is + ok if you use lambdas for simpler functions, but when you keep piling + lambdas over lambdas, things get a bit out of hand. Trying to explain some + functionality in a 200 line function is not actually helpful. * (-) The ePub version seriously need another check. Some code listings are - pure text, so it follows the user font size; but other are - screenshots/images of code, which get way out of hand, as some listings - had fonts that where 1/5 of the font I use to read (yes, I use a large - font, I'm reading at night without my glasses, but the point remains). + pure text, following the font size the user set in their reader; other are + screenshots/images of code, which get way out of hand, as some of those + had a font 1/5 of the size I set up (yes, I use a large font, I'm reading + at night without my glasses, but the point remains). * (--) There is very little explanation on what FRP really is, but a lot about - how to do things with Sodium, the authors library. Instead of focusing on - how to build your own FRP system, using Sodium as reference, the books - focuses _a lot_ in using Sodium and why that implementation is FRP instead + how to do things with Sodium, the authors' library. Instead of focusing on + how to build your own FRP system, using Sodium as reference, the book + focuses _a lot_ in using Sodium and its relationship with FRP instead of explaining the concept behind the FRP functionality itself. -* (--) The authors shows some weird prejudices against TDD. For example, they +* (--) The authors show some weird prejudices against TDD. For example, they say that FRP doesn't require TDD and that using TDD is actually _harmful_ - for FRP, "unless you test logic". I mean, seriously? What do you think TDD - is about? Lines of code? TDD says that "tests should validate behaviors, - not implementation" and I'm wondering why the authors are so reticent - against TDD when their concept of TDD seems completely out of place. + for FRP (!!![^2]), "unless you test logic" (???[^3]). I have to ask: Seriously? + What do you think TDD is about? Lines of code? TDD says that "tests should + validate behaviors, not implementation" and I'm wondering why the authors + are so reticent against TDD when their concept of TDD seems completely out + of place. * (---) There is a strong gatekeeping in the book. While talking about other - frameworks, the authors, they decide to focus more on "why this framework + frameworks, the authors decided to focus more on "why this framework is not pure FRP, while Sodium is" instead of, again, focusing on the concepts of FRP itself. "FRP says so and so, you can build this with framework X using that and that" is a good way to do it; "FRP says so and so, framework X do this which is not what the FRP says, so framework X is not FRP, but Sodium is!" is a dickish way to downplay other frameworks. - Also, it's weird that every time Sodium breaks some FRP rule (rules that + Not only that, but every time Sodium break some FRP rule (rules that the authors themselves keep listing), they put a long explanation on why - it's ok to break the rule there, saying that it's ok that Sodium breaks - it. + it's ok for you to break the rule there when using Sodium, but Sodium, + although requiring you to break some FRP rule, is actually a pure-FRP + framework, and not those pesky other frameworks that are not pure-FRP + frameworks. Honestly, I read the book and I still don't understand FRP; all I got was some concepts for a Sodium framework. + +--- + +[^1]: ... which may appear as no surprise, with the amount of grammar mistakes + in this post. :p +[^2]: That's surprise. +[^3]: That's confusion.