On Wednesday, 18 March 2015 at 13:27:54 UTC, CraigDillabaugh
wrote:
clip
Bearophile,
You said that "Unfortunately" this thinking is going out of
style "for good reasons". I am confused (sorry, I am at
work, and didn't have time to watch the 1+ hour video you
linked to - maybe some clues were there)!
I often find myself feeling a bit like Elazar. Not long ago
I wrote some Python code using a bunch of the functional
style programming tools and I was very please with the very
concise code I had generated. Then, I had to make some
modifications to the code. It took me an inordinate amount of
time just to figure out what the code was doing, and I had
written it myself just a few days earlier!
Craig
Maybe your years of practice and deep familiarity with
imperative code patterns - both general and individual to
yourself - might have skewed the result somewhat.
It seems to me that much of practical programming is about
having set up "quick paths" in your brain for recognising and
manipulating common patterns. There's a big gap between
understanding something intellectually and understanding
something intuitively.
There is quite possibly something too that, and as I imagine
with more functional experience it will come easier to me.
However, I still think imperative code is generally easier to
reason about because (usually) each line of code is performing
a single task, whereas with functional coding the goal seems
to be to cram as many operations as possible into a single line
(I know that isn't the real reason, it just seems that way at
times). Trying to 'unroll' everything in your head can be a
challenge. Throw in a lambda function or two with
the mess of braces/symbols and then you have a real puzzler.
Careful formatting is really important for long UFCS chains using
lots of lambdas etc. in D for exactly this reason. It's very easy
to go "ooooooo, that's so neat, it's all one 1 line!" but it's
often better to spread it out to make the semantics more obvious.
