Mental models of programs [was A few notes on choosing between Go and D for a quick project]

[Paulo Pinto via Digitalmars-d]

On Thursday, 19 March 2015 at 08:17:42 UTC, Russel Winder wrote:
> On Wed, 2015-03-18 at 13:27 +0000, CraigDillabaugh via 
> Digitalmars-d wrote:
>> 
> […]
>> 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.
>
> Each imperative statement may (or may not) be easier to 
> understand,
> but the problem is putting them together in combination. The 
> issue
> here is creating chunks on which you put a label for reasoning 
> with.
> Everything is about the abstractions you reason with. A person 
> who is
> familiar only with C-style programming (as per OPs code 
> fragment) has
> built up various abstractions, but they are nonetheless at a 
> very low
> level and so many have to be combined.
>
> Someone who has learned the internal iteration abstraction and 
> higher-
> order functions is actually working at a higher level of 
> abstraction
> and generally needs to combine fewer things to achieve the 
> overall
> goal. Cramming operations on a line is nothing to do with the
> abstractions, that is to do with some people playing code golf.
>
> If you find yourself reading declarative style code and having 
> to
> unroll to imperative equivalent to understand, it just means 
> you have
> not yet internalized the declarative abstraction yet into your 
> mental
> model and personal programming language.
>
> There is a lot of work on all this sort of stuff in the 
> psychology of
> programming research literature. We can speculate all we like 
> here
> based on personal experience and anecdotal evidence, they do
> experiments and have real data. Of course if you see any 
> experimenting
> on first and second year undergraduates of computer science, 
> ignore
> the results. I am talking about those who experiment with 
> practicing
> programmers, people with real experience and expertise.

I just saw a talk of one of those studies.

One of the points was that curly braces languages lead to more 
bugs than languages that follow the Algol more verbose style.

CodeMesh 2014 - Andreas Stefik - The Programming Language Wars

https://www.youtube.com/watch?v=mDZ-QSLQIB8

Quite interesting when one mixes psychology research with 
language features, backed by validated research data.

--
Paulo