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

John Colvin via Digitalmars-d digitalmars-d at puremagic.com
Wed Mar 18 09:30:55 PDT 2015

On Wednesday, 18 March 2015 at 13:27:54 UTC, CraigDillabaugh 
> 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.

More information about the Digitalmars-d mailing list