3.5* = It was a decent book, but I likely wouldn't read it again unless someone did some serious convincing.
The book gets so close to being really goo3.5* = It was a decent book, but I likely wouldn't read it again unless someone did some serious convincing.
The book gets so close to being really good, but unfortunately it just wasn't technical enough for my personal preference. It is very much written to be read by someone of low to moderate technical knowledge.
I'm a software engineer, so I naturally wanted a more technical guide. For instance, there was only one small section on auto-generated specifications, which only listed the cons of using such a process (there was another mention in the final chapter but wasn't given its own section). I would have enjoyed an explanation of why you might use a generation library, what an example usage might be, and compare that to the manual process.
The best thing the book did was to give me an overview of what needs to be done, and an awareness that API guidelines exist and should be considered before reinventing the wheel.
Another complaint I have is that the book is full of huge diagrams with paragraphs of filler. The author creates these often complicated diagrams that are self-descriptive and can be fully understood without much supporting text, then proceeds to describe each part of the diagram in excruciating detail. Or throws in redundant diagrams that add nothing to my comprehension or paragraphs that seem to repeat early points. It felt very much like filler to make sure the book met some quota on length....more
The most useful aspect of this book, in my opinion as a C# programmer, would be the introduction of functional concepts through examples of C#. HoweveThe most useful aspect of this book, in my opinion as a C# programmer, would be the introduction of functional concepts through examples of C#. However, after completing this book I came to the conclusion that C# just isn't the language to perform functional programming in. There are a lot of trials and tribulations that come with attempting to make an object-oriented language perform functional actions, and many of those woes could seemingly be overcome by utilizing a more purpose-driven language like F#, Haskel, or any of the other functional-first languages. There is more than one occasion in which the author mentioned a functional concept that just simply wasn't possible in C#.
If I were to re-write this book (not that I could), I would focus on using idiomatic C# concepts to perform function actions, rather than using more functional concepts. Using `Select` instead of a `Map` function or `SelectMany` rather than `Bind`. While it is mentioned in the books how these concepts are essentially interchangeable, it would simplify my understanding of the concepts if each time I didn't need to perform the translation in my head. It would also be beneficial to use a more established library like `LanguageExt` rather than rolling a custom library (`LaYumba`), which would alleviate some of the tribulations I encountered when attempting to apply these concepts with new vocabulary that didn't match those taught in the author's library.
But on a more uplifting note, I think the book did effectively introduce me to concepts. I found that it didn't give me a deep enough understanding of them that I could effectively use them without much issue (there was a lot of stumbling when I attempted to apply these concepts to a demo application without any handholding). However, it did make me aware of the concepts and help me know what I needed to look up; it gave me a glimpse of the end goal so that I could pave my own way there.
I'm not sure I would recommend this book as a good way to learn a functional language. I think there may be other, better alternatives out there that use C# as a demonstration. However, I don't think I would discourage anyone from trying it and wouldn't try to convince them to pick an alternative if they've already decided on this one. The book was reasonably effective and I cannot fault it for it's ability to introduce concepts....more
At this point, this book is pretty far out of date. It doesn't cover hooks at any point, which is the main casualty of the publish date. The book is sAt this point, this book is pretty far out of date. It doesn't cover hooks at any point, which is the main casualty of the publish date. The book is so old at this point that the demo website doesn't even work any longer; the code may work, but the code-base is so large that it's overwhelming and I found that I had zero interest in pulling it down. The examples would have been far better suited as small, self-contained demonstrations instead of trying to connect to a larger website. At the very least they could have been integrated better. Pages of the book were dedicated entirely to examples which were nearly carbon copies of previous examples.
If you're going to learn React, I'd recommend just reading the React Documentation. It reads easier than you'd think and is much more beginner-friendly....more
I went into this book with pretty large expectations. I had heard the book was great, but I realize now I never really heard why it was great. The rumI went into this book with pretty large expectations. I had heard the book was great, but I realize now I never really heard why it was great. The rumor mill just told me that it was the book to read if you wanted to learn refactoring.
Unfortunately, I found myself very disappointed by the book. The first four chapters could be compared to Clean Code in many ways; they introduce some good practices of coding and how to perform a refactoring safely. But beyond that it is just a reference list of all the different types of refactoring. On some level I understand why he went into as much detail as he did, but there were a few that just felt extremely long-winded for how simple they are. I don't really need an example of `rename field`.
But that was another criticism I had about this book; the refactoring difficulty levels were wildly different. Some of the refactoring steps were so simple that any modern IDE can handle it without even pausing (rename field, move declaration, delete unused code), while others were very highly involved changes that could have long reaching impacts across the entire system, most notably "introduce polymorphism". So in terms of the book, renaming a variable is equivalent to introducing a series of classes and polymorphism into your application. Perhaps what the book needs is some sort of difficulty rating, that way I at least get the sense the author realizes not all refactorings were created equal.
Rants about difficult levels aside, this book really does turn into a reference book. It simply lists every refactoring, no matter how trivial, and tells the motivation, process, and an example (or several). That's it. The motivation is almost never more than a paragraph or two, so in terms of hard thinking, you won't be doing much for this book. I would certainly not recommend this book to a programming book club; we found ourselves struggling to come up with topics of conversation at times since everything was so straightforward. And we found ourselves skipping most, if not all, of the examples by the end of the book. It just wasn't worth the time to read how to do the refactoring.
I won't say that the book is bad, because it isn't. And it certainly isn't a bad concept. But I will say it wasn't an exciting book. I didn't learn anything new that I'm excited to implement in my daily programming life. It's like brushing my teeth; it's not fun, it's not exciting, but it's very important to do....more
While I think this book has a lot of really great advice, I didn't particularly enjoy the writing style. Everything seems so finite and certain, despiWhile I think this book has a lot of really great advice, I didn't particularly enjoy the writing style. Everything seems so finite and certain, despite the fact that they repeatedly walked back on arguments they had made in the first edition. The tone of the book was just a little too casual. It felt like I was getting a lecture by my grandfather instead of a professor.
Tone aside, the concepts in the book are really really solid and I think it's what we all should strive for. But reality is often disappointing. These suggestions work in the real world, and yes it would be interesting to work in a place that had all of these suggestions. But it'd also be nice if unicorns were real.
I also didn't particularly like how the coding examples were all in different languages depending on the section. It's not that it's hard to understand, but wouldn't it have been easier to lock in the concept more solidly if I could see it in my "native language?" The authors boast about the automation of their publishing scripts, so why couldn't one of those steps have been replacing all the code samples with a particular language. Naturally, you would end up with a litany of versions, but since they own the publishing company (and the website), this feels easily manageable using the PDF version. Now perhaps this is me missing the point, but I think it would still be beneficial. For example, during the section discussing the use of preconditions, post-conditions, and invariants, I had to look up online how my favorite language, C#, handles the process. And it was significantly different than the ideal example they presented in the book, and really isn't nearly as practical as they made it sound, nor as recommended.
Overall, I would tell everyone to read this book, but I would also say take it an open mind. These are things the ideal programmer should be doing, not the average programmer. Take steps to meet these goals but don't beat yourself up if you don't attain all of them within the next decade....more
I never got to the end of this book because of how poorly it was written. Every explanation is done in a long-winded manner that only serves to confusI never got to the end of this book because of how poorly it was written. Every explanation is done in a long-winded manner that only serves to confuse me more than it does explain things. The first chapter starts off with an explanation about the difference between parallelism and concurrency; it took this author an entire chapter to confuse me about the concept, and it took the authors of The Pragmatic Programmer (which I started reading a while after) only one paragraph. I was forced to seek external sources just to understand the simple concept.
There are a litany of errors, ranging from typos to copy-pasted links and sentences. I took to pulling out an orange highlighter every time I read just so I could record all the errors. Most don't hamper your understanding, which is good, but the real issue is that it speaks to the quality of the book and its editing. If they can't even catch such simple errors, how can I trust the book?
The book states early on that a knowledge of F# is not necessary to read, and that you can get along just fine. Yet every chapter, half the pages will be in F# and expect me to understand what the language is doing. And if you are going to read the book, do yourself a favor and don't read the appendix on F#; it will only serve to confuse you and in some spots give false information.
I really wanted to like the book, I have purchased many Manning publications in the past, but there was just too much wrong with it. I may try again some day when I have more time on my hands to really focus in and do web-searches for all the concepts, but I imagine I won't get a full benefit from the book until I know F# in depth....more
Loading...
