[throwaway13337]

This just seems to obscure the logic. Not unlike how polymorphism can make code flow harder to read, though feel more clever.

There is a place for it - like when you're trying to express a set of logic that will be guarded by the same condition, but always at the cost of some complexity.

A set of conditionals is probably the most obvious way to express branching.

[dwb]

Try it before you knock it. I might have said something similar before getting into Haskell, but now I'm nodding along happily. Dealing in meaningful data types with small composable functions is very pleasant for me now.

[TeMPOraL]

> Try it before you knock it.

That's what I recommend too[0] - with the added caveat that you shouldn't be afraid to "knock it" if it turns out to be honestly bad.

Sometimes the idea turns out bad, sometimes it turns out great - but you'll never know it if you don't try; just be honest with yourself during that trial.

[0] - https://news.ycombinator.com/item?id=12108138

[dwb]

Absolutely, but I'd also add that what works in one language/environment may not work in another. I wouldn't be surprised if writing Haskell-style code in Python didn't work out that well, for example!

[TeMPOraL]

I agree. I used to earn my bread in PHP and now I do it in Java, while after hours I mostly code in Common Lisp. I have some experience trying to port idioms from the latter one to the former two. Sometimes it turns into a good idea (God, how much my life in one PHP project was simplified by porting over #'mapcan), sometimes you quickly realize it's stupid and makes zero sense. But I think that's again a case of taste acquired by experimentation :). A big enemy here is simply sunk costs fallacy - no matter how emotionally invested you're in some idiom, sometimes it really doesn't fit the other language.

[eru]

I have tried. Two things get in the way quickly, and that's even just expressing thing, not even looking at performance yet:

  * Python standard library functions, especially the ones on dicts, mutate and don't return the new dictionary.
  * Python's syntax for creating functions is awkward: lambdas are cumbersome, and so are the operator package and eg functools.partial; there's no really convenient way to compose functions.

[andrewaylett]

Your first point is actually something I really like about Python's API design: in general, methods operating on collections either mutate the collection /or/ they return it. So it's clear at the point of use whether you're dealing with the same object or a new one.

This is something that bugs me about the fluent builder pattern in Java -- continuing to return `this` until suddenly you don't any more, and you can't re-use 'intermediate' values because they're actually all the same object.

[eru]

Sure. I'd just like to have a nice set of operations to manipulate dicts that don't mutate and return the result, too.

[jakub_h]

> A set of conditionals is probably the most obvious way to express branching.

Besides object polymorphism and sets of conditionals, there's also generalized predicate dispatch, but that's probably an overkill for many things.