|
I've been writing Python a lot coming from a Scheme/SICP background too, and I've slowly come to a sort of solution to this problem that works for me. Basically, what it comes down to is realizing that a lot of the libraries and frameworks out there are smoke and mirrors: they provide an initial solution to a common problem, but when you start getting into the details of your problem, the problem you are trying to solve, you end up working around their crappy configuration points. In short, you stop coding and start configuring existing code which is poorly designed to solve your problem. So what I do is I stop using those libraries. I zealously guard my dependencies, only letting in things that are solid, well-designed, mature, and minimally invasive. I use minimalist frameworks, eschewing ORMs. Most of the time I avoid classes, opting instead to use closures and namedtuples. The result, my code is fast, flexible, easy to understand, easy to test. I migrated around 30,000 lines of code from Python 2.7 to 3.4 in an afternoon--my unit tests caught a few issues and once those were fixed I didn't see any regressions in the following months. I think the wall you're hitting isn't Python, it's the culture and libraries a lot of people use for Python. But there are a lot of people who don't use those things. Next time you think of reaching for pip or Django, stop yourself: do you need that? Maybe it provides a short-term solution to your problem, but in the long run it's neither a beautiful nor efficient way to write code. |
I've been bitten by the data-oriented design bug and it has made my experiences with programming so much better. It turns out Python is really good at this style of programming. There are powerful ideas in co-routines and sub-generators that make stream processing minimal and easier to grasp. Simple ideas like decision tables are so easy to implement that I cringe when I see giant state machines serialized across several classes. Implement backtracking with a stack? Why bother -- functions live on a stack and push/pop: yield-from/yield. We can serialize the state of a co-routine... boom, concurrency. Sometimes it's the little things in Python the surprise me the most and are the reason I keep using it.
Avoid classes where you can! Design your programs around your data. Python has plenty of built-in patterns for manipulating data and aggregates. It's sometimes surprising how simple your programs become when you resist the temptation to start modelling your problem as classes.
I would never discourage someone from pursuing Scheme or Lisps in general (Have you seen Hy? Homoiconic front-end to Python's AST). Scheme does encourage thinking about problems as recursive functions. If iteration is a special case of recursion than Python is breaking ground in the same direction just in different clothes.