The author is not saying "write C in Python," he's saying "Aim for C-style abstractions in Python." i.e. build the codebase around the bread-and-butter: function calls, iteration, reference-passing and mutability, and not around abuse of the numerous higher-level abstractions available(meta-programming, yield, exec()...). It's a lesson learned regularly by programmers as they gain experience and move towards conservativism, after having seen all their silver bullet attempts go up in flames.
A similar tenet holds for the opposite direction - the performance junkies; the tendency with experience to move away from locking in specs early and doing heavy micro-optimization, towards writing the initial code in a way that tries intentionally to make it easy to modify.
> The author is not saying "write C in Python," he's saying "Aim for C-style abstractions in Python." i.e. build the codebase around the bread-and-butter: function calls, iteration, reference-passing and mutability, and not around abuse of the numerous higher-level abstractions available(meta-programming, yield, exec()...). It's a lesson learned regularly by programmers as they gain experience and move towards conservativism, after having seen all their silver bullet attempts go up in flames.
Amen to that. I've been programming in Python for 7 years now, but lately I had started to see more and more of my fellow Pythonistas dropping "yields" all over the place, using "generator this / generator that" etc. I thought I was either getting too old or maybe I was not smart enough, because to me Python it's 99% about writing and manipulating nice hash tables (dictionaries, as they are called) and lists (I love those list comprehensions).
Again, maybe is just me, I just felt that adding another layer of abstraction would get between me and the data I'm trying to manipulate when I write my programs.
Worst programming advice ever IMHO. As Sir Isaac Newton used to say: "If I have seen further it is only by standing on the shoulders of giants." If you think and program in simple abstractions, you'll be unable to solve complex problems.
Newton is a great choice to use in the example as he invented calculus which is an incredible abstraction. I tend to look at the lambda calculus in the same way. Yes, calculus is more complex than algebra but once you understand it you can solve much more challenging problems because of the abstraction inherent in the notation.
A similar tenet holds for the opposite direction - the performance junkies; the tendency with experience to move away from locking in specs early and doing heavy micro-optimization, towards writing the initial code in a way that tries intentionally to make it easy to modify.