[neoncontrails]

I've been feeling the past few weeks the repeated impact of hitting a wall. Programming was starting to feel like grinding. I felt wistful for SICP, when programming was full of big ideas and elegant new approaches to problems my unprincipled brain's first instinct was to clobber by brute force -- and learned, quickly, in Scheme, it's hard to be artless. It is, I think, harder code gracelessly in Scheme than to code with grace: it has a way of bending your ideas to a form. I think that's my main complaint with Python. In Python, exactly the opposite is true: it doesn't force you to think overly hard about the way you solve problems, so you can solve more problems! Woohoo! You can Code Like Coltrane, as Rich Hickey says.

For better or for worse. Here's an unfortunate side effect I've noticed: my programs are vastly more complex and efficient than when I graduated from SICP a year ago, which is good, and yet I can't remember the last time I wrote code that was truly beautiful. Code I felt proud to call my code. Whose inner workings I could explain to a child. To me, efficient Python programs conceal so much of how they work, that striving for craftsmanship can feel alienating. It conceals so much. It's like a black box magic trick: in goes the value... (pause) oh, and there's the answer! And the obvious what's happening in between those two points, the less efficient my solution tends to be. The prize winning solutions are often the most opaque, the most dense with imported methods. And my programs look inevitably kind of haphazard and provisional. Like doodles.

My Scheme programs, on the other hand, looked like Swiss clocks. They pleased me. They wouldn't have worked any other way. They molded to the precise, regimented form they had to be. I understood them. They were good.

I like functional programming. I think the wall I'm hitting might be Python. The thought of a little Clojure or Haskell in my life right now sounds like a beach vacation.

[a-saleh]

> The thought of a little Clojure or Haskell in my life right now sounds like a beach vacation.

This is the reason, why I started to do little side-projects with clojurescript and reagent [1]

I love the way how programming with reagent is visual, with almost no friction. I just start repl, start browser, open the code, and every time I save file, I see how my program changes :-)

Compared to my work, where it can take me the first hour to get into the zone, and additional 20 minutes each time I need to switch frameworks, it really feels like a vacation :)

[1] https://reagent-project.github.io/index.html

[copsarebastards]

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.

[agentultra]

Precisely!

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.

[beatband]

would love to see an example of your code style...github account?

[copsarebastards]

A lot of my thoughts on this subject were inspired by this Tweet: https://twitter.com/garybernhardt/status/616327747435036672

Maybe check out Gary Bernhardt's code?

[copsarebastards]

Sorry, there's just no way I'm going to link this account to my real-world identity. I speak far too freely with this handle.

[jahnu]

A lot of that feeling, at least for some of us, comes from jobs which require us to implement lots of business logic.

Business logic often requires coding lots of small conditions distributed all over the code base of an application. Especially once you hit the maintenance phase.

[vladsanchez]

Sounds like a Rules Engine to me. Your description implies a brittle solution that may not be representative of the utopic circumstances pursued by our colleague. Look into Drools. ;-)

[adamc]

I dunno. I spent some time learning Clojure but came to the conclusion that it's really only a good tool if you are also heavily committed to Java -- too many Java stack traces, too many functions where the answer is "use Java", too much time looking at Java source code. I don't hate Java, but that wasn't what I was hoping for. (Haskell is a different story, very different pros and cons.)

[erichmond]

Interesting you have been spending time looking at Java source code, what problems were you trying to solve?

I have been working professionally with clojure for about a year and haven't had to look at any Java source code.

[adamc]

Mostly trying to better understand clojure constructs and their edge cases. I guess I was expecting a more lisp-y setup where high-level concepts were implemented in terms of a small number of clojure primitives, but it didn't seem to work that way. Probably made it perform better, but it also makes it harder to do anything about the endless Java stack traces.

[arkx]

ClojureScript is a very good tool without any Java commitment.

[adamc]

Interesting. I haven't used ClojureScript.

[babo]

Check some Python code from Peter Norvig and you will see a beautiful and clever style. It's not the language which stops you.

[yati]

While I've learned a lot from Norvig's posts, he tends to write Python code that many wouldn't consider "Pythonic" :)

[ww2]

That is just the point, you dont have to limit yourself to "Pythonic". your style can be language agnostic.

[erichmond]

I agree with you in spirit, but that's actually easier said then done in a professional environment.

One of the things that dissuaded me from ruby was the idioms that have surfaced recently. I was tired of submitting pull requests, only to have people tell me there was a "more idiomatic way" to do things, then rewriting things in a way I felt was less clear then what I had originally written.

My solution to that problem was to find a community who's idiomatic ideals more coincided with mine (which happens to be clojure), but I understand not everyone has that sort of luxury.

[thro1237]

I tried to use Clojure exclusively at work for couple of years. The problem was I couldn't figure out what my code when I try to go back and read it. I was able to write really succinct code by building up abstractions, but it was much harder to figure out what those abstractions meant few months down the line. I realized that inorder to figure out what the code does, I had to re-run the computations in my memory. Went back to python and I am loving it.

[taeric]

Swiss clocks feel impressive, no doubt. Quartz clocks, though, have the advantage of being accurate.

[dagw]

A lot of Swiss watches (even from the most high end brands) use quartz movements.

[taeric]

I felt it was safe to assume, for the analogy, that we were talking mechanical watches.

[59nadir]

This has absolutely no relevance to the analogy.

[taeric]

If you are expecting working code to be as elegant as a "Swiss clock," you might want to reconsider what the goal actually is.

Certainly there is something for coding in this way. Just as it can hold a certain delight to have an elegant looking watch. There is a good chance of overbuilding when I see this level of coding from colleagues. Myself included.

[dkersten]

This is sort of how I feel after moving from over a year of pure Clojure(script) development, to working with Python again. Its not that you can't write beautiful code in Python, its just that the language encourages a certain style.

[kwhitefoot]

You can write in functional style in pretty much any language. It might not look quite so pretty but it can come close. And it can often be usably efficient too.

[davexunit]

But you always have to make some serious trade-offs. Sure, maybe you can use map and friends, but you usually don't get the nice things like tail-call recursion semantics (though Clojure doesn't have that either), efficient persistent data structures, proper first-class functions (looking at you, Ruby), lexical scope, etc.

I program in a functional style in all of the languages that I get paid to use, but I'm always sad about the lack of many useful features.