I have become very framework-adverse over the past few years as I've switched from corporate programmer to startup programmer, and from OOP programmer to FP pro

I have become very framework-adverse over the past few years as I've switched from corporate programmer to startup programmer, and from OOP programmer to FP programmer. Frameworks, especially OOP frameworks, tend to throw you into a universe of nouns and verbs that can be quite complex and completely of the author's making. Everything works great -- until it doesn't. And then you're spending your valuable time and brainpower learning about some framework instead of about how to do the job you're trying to do. That's almost always a fail. As the author mentions, it just gets worse: many times you're suckered into thinking the answer for your problem is yet another plug-in or framework. Now you have even more stuff to keep track of. OOP forces you to answer the question: what does this system represent? Once you do that, then you're left with several metric tons of how to represent it well, which can lead to a _lot_ of stuff. FP, on the other hand, forces you to answer the question: what, exactly, do you want the system to do? As it turns out, unless you're strictly happy-path, the shortest way to an answer is just to do the work. (Of course, nobody is saying to throw out core libraries and start writing in machine code. But if you're bleeding to death from paper cuts on WhizBang 4.0 that you just downloaded last week, you screwed up.)