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

[John Colvin via Digitalmars-d]

On Wednesday, 18 March 2015 at 12:45:50 UTC, CraigDillabaugh 
wrote:
> On Wednesday, 18 March 2015 at 12:11:52 UTC, bearophile wrote:
>> Elazar Leibovich:
>>
>>> I personally, would have no idea what this piece of code is 
>>> doing upon first sight. I'll have to look at the 
>>> documentation of
>>> at least two functions to understand that, and I'll have to
>>> think carefully about what and who would throw in case of an 
>>> error.
>>>
>>> Something like
>>>
>>>   while (n != EOF) {
>>>       n = read(fd, buf, sizeof(buf));
>>>       if (n==-1) throw(...);
>>>       if (strcmp(buf, PREFIX) == 0) {
>>>            return buf;
>>>       }
>>>   }
>>>   return NULL;
>>>
>>> Requires no prior knowledge, and have similar effect.
>>>
>>> I'd rather have a loop written by hand in my production code 
>>> any day, so that when debugging it, and reading it I'll have 
>>> easier time
>>> to understand it, even though it would cost me a few more 
>>> lines
>>> when writing the code.
>>
>> Unfortunately your thinking is mostly obsolete, the 
>> programming world (well, most of it, Go is one exception) is 
>> going in the opposite direction, and for good reasons. An 
>> explanation:
>> https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning
>>
>> Bye,
>> bearophile
>
> 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.