A few notes on choosing between Go and D for a quick project

[CraigDillabaugh via Digitalmars-d]

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.