Beautifully said. I was going to post a comment saying the same thing, but you've put it in much better words than I would have. Thanks.
It's sad some programmer fall into the purity trap and try to make things as functional as possible and end up taking a lot more time than they normally would have, make the code incredibly hard to understand, etc.
I once fell into this trap and paid dearly. I'm a university student and for one of my semester projects I decided to try out pure functional programming. I ended up failing that class because I didn't finish the project, and doing bad in others because I spent ridiculous amounts of time doing the impossible project. (The project itself was easy - a simple 2D sidescroller game in C++, something I could have done in a week if I had been sensible; but writing a game in functional style in C++ proved to be incredibly hard.)
You shouldn't blame a particular programming style for the failure. Your real failure was an organizational one.
It seems that you have more experience with the imperative style than the functional style. And yes, it's always good to try a new style you aren't yet comfortable with, but you shouldn't do that in an important project. Also, you might have had better luck with Haskell or Lisp rather than C++. But here again, you shouldn't do that in a time contrained project if you aren't fit in that language yet.
Instead, you could have taken the week to implement it in the style you're comfortable with, and rewriting or refactoring it into another style to play around with it. That way, you would not only have eliminated the risk of failing. You would also have learned more, being able to compare both styles side-by-side.
You may have failed classes, but the lessons learned in working on something so improbable were probably worth the price of admission.
It's good to be too pure for learning purposes, because it makes you comfortable with a lot of nitpicky stuff. When you move towards commercial software, you won't get an environment that encourages you to take on the risky stuff. "Lean and mean" is the order of the day. So having the other experience gives you an edge in perspective.
Well... you actually can try out functional approaches in C++, and even gain something out of it. It's just that doing so requires a sophisticated understanding of C++.
It's sad some programmer fall into the purity trap and try to make things as functional as possible and end up taking a lot more time than they normally would have, make the code incredibly hard to understand, etc.
I once fell into this trap and paid dearly. I'm a university student and for one of my semester projects I decided to try out pure functional programming. I ended up failing that class because I didn't finish the project, and doing bad in others because I spent ridiculous amounts of time doing the impossible project. (The project itself was easy - a simple 2D sidescroller game in C++, something I could have done in a week if I had been sensible; but writing a game in functional style in C++ proved to be incredibly hard.)