The top answer seems to be for the question "How do I learn to program Python using only the functional style". Which is <i></i>FAR<i></i> from being a Python Guru. A Guru knows how to use Python for many styles and to mix them for optimal effect.<p>#11 "balance" is laughable based on the preceding ten.<p>Some things missing include:<p><pre><code> * properties (glaringly so)
* slots
* meta classes
* dynamic code generation / data as code
* emulating various types and the rest of __methods__
* know thy standard lib
* distribution setup tools, et al
* documentation epydoc, sphinx, docutils, et al
* profiling and performance
</code></pre>
Also from the top answer.<p>"... Python class. Claim it could be "better" implemented as a dictionary plus some functions"<p>Um, that is almost all a Python Class is.
I'm really into the whole "code as craft" idea, though a lot of my thoughts on the subject aren't fully baked.<p>It seems to me that we're at a place with software where we were with, say, civil engineering in roughly 2000 BC or something. This date is horribly wrong, but what I mean is that we're building basic structures, and we're okay at it, but when we try to do anything larger, we're failing.<p>At some point, we'll be able to make larger buildings, bridges, and roads... but we're not there yet. It seems like the best path forward is to follow is to do exactly what early engineers did: an apprenticeship model. Yes, software is based in math, but so are bridges. We've got a better grip on the math now, and it does help us build modern bridges, but at first, we had to schlep along.<p>I'm starting to ramble slightly, so I'll cut this off. And as I said, this is only a half-baked thought... but I think this 'apprentice -> journeyman -> master' path is an intriguing way to move forward with software.
This is like saying you can be fluent in Japanese by learning the grammar and saying nothing about the vocabulary. Fluency with the libraries python offers is far more important than whether you express yourself imperatively or functionally.<p>That said, I'm off to the library to borrow a copy of <i>Real World Haskell</i>.
The first answer is interesting but I don't understand step 10. Imperative is a model with state and deterministic sequence and Haskell constructs like state and IO monads form imperative DSLs (with some typing burden/advantages). I don't see why the strategy pattern is particularly interesting here (but I see why imperative structures like mutable arrays and associative arrays are interesting). I don't see either why I would especially forget all those design patterns outside of imperative code : for instance the presentation of Connal Elliot "Tangible Functionnal Programming" is a great exemple of the use a kind of MVC pattern precisely to avoid using imperative constructs.<p>For me at least, the balance lies more in the use of state (easy in python) or the cost of abstraction (no inling and TCO).