Follow-up post explaining research rationale

[Chris via Digitalmars-d]

On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:
[snip]
> Let me give you a sense of the sorts of issues I'm thinking of. 
> Here is a C sample from ProgrammingSimplified.com. It finds the 
> frequency of characters in a string:
>
> int main()
> {
>    char string[100];
>    int c = 0, count[26] = {0};
>
>    printf("Enter a string\n");
>    gets(string);
>
>    while (string[c] != '\0')
>    {
>       /** Considering characters from 'a' to 'z' only
>           and ignoring others */
>
>       if (string[c] >= 'a' && string[c] <= 'z')
>          count[string[c]-'a']++;
>
>       c++;
>    }
>
>    for (c = 0; c < 26; c++)
>    {
>       /** Printing only those characters
>           whose count is at least 1 */
>
>       if (count[c] != 0)
>          printf("%c occurs %d times in the entered 
> string.\n",c+'a',count[c]);
>    }
>
>    return 0;
> }
>
[snap]

I went to www.programmingsimplified.com/c-program-examples and 
found that this was example 48 out of 59. The examples start with:

- Hello world
- Print Integer
- Addition
- Odd or Even
- Add, subtract, multiply and divide
- Check vowel
- Leap year
- Add digits
- [...]

and so on, with increasing complexity.

Nobody starts with examples like the one above. More likely with 
number 1 in their list:

#include <stdio.h>

int main()
{
   printf("Hello world\n");
   return 0;
}

Not so difficult to understand.

A Python version similar to the example you gave above looks like 
this [1]:

def char_frequency(str1):
     dict = {}
     for n in str1:
         keys = dict.keys()
         if n in keys:
             dict[n] += 1
         else:
             dict[n] = 1
     return dict
print(char_frequency('google.com'))

Throw this at the uninitiated newbie and s/he will have similar 
difficulties in understanding it at first sight. You're talking 
about showing someone who's beginning how to learn guitar charts 
from Paco de Lucía's masterpieces.

It's not the syntax, it's being used to thinking in a certain 
way, and this takes time and practice (like an instrument). Once 
you've reached a certain level you can parse things at sight.

More important than syntax, in my opinion, are language features, 
i.e. what can be expressed in and with a language. If you look at 
both of the examples above, they tackle the same problem from a 
slightly different angle. But it's still the same underlying 
logic. That's why it is not hard for programmers to edit/write 
code in languages they don't know well. They know _what_ to do, 
and just look at _how_ they can best do it in a given language.

And this is where D kicks in. D and other languages explore how 
abstract concepts and problems can best be solved, what tools 
should be available etc. If anything, you should concentrate on 
matching the world to the machine using programming languages, 
instead of focusing on trivial syntax features. It's like 
discussing whether it's important to write the expression "in 
spite" as one word or two, while what counts is its function:

Inspite of the bad weather, we could get to the conference in 
time.

It's the same as

In spite of the bad weather, we could get to the conference in 
time.

The important thing is that we have the concept of "in spite", 
and we can add more concepts and more ways of expressing them. 
Syntax is trivial. Syntax is a mere convention that can be 
learned and, what is more, is confined to a closed domain that 
rarely interferes with other "realities".

[1] 
http://www.w3resource.com/python-exercises/python-data-type-exercise-7.php