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
>>> 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!
>> 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