www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Follow-up post explaining research rationale

reply Joe Duarte <jose.duarte asu.edu> writes:
Hi all,

As I mentioned on the other thread where I asked about D syntax, 
I'm a social scientist about to launch some studies of the 
effects of PL syntax on learnability, motivation to pursue 
programming, and differential gender effects on these factors. 
This is a long post – some of you wanted to know more about my 
research goals and rationale, and I also said I would post 
separately on the gender issue, so here we go...

As you know, women are starkly underrepresented in software 
engineering roles. I'm interested in zooming back to the 
decisions people are making when they're 16 or 19 re: programming 
as a career. I'm interested in people's *first encounters* with 
programming, in high school or college, how men and women might 
differentially assess programming as a career option, and why.

Let me note a few things: Someone on the other thread thought 
that my hypothesis was that women don't become programmers 
because of the semicolons and curly braces in PL syntax. That's 
not one of my hypotheses. I do think PL syntax is a large 
problem, and I have some hypotheses about how it 
disproportionately deters qualified women, but the issues I see 
go much deeper than what I've called the "punctuation noise" of 
semicolons and curly braces. (I definitely don't have any 
hypotheses about female perceptions of the aesthetics of curly 
braces, which some posters had inferred – none of this is about 
female aesthetic preferences.)

Also, I don't think D is particularly problematic – it has 
cleaner and clearer syntax than its contemporaries (well, we'll 
need careful research to know if it truly is clearer to a 
targeted population). I plan to use D as a presumptive *clearer 
syntax* condition in some studies – we'll see how it goes. 
Lastly, I'm not approaching the gender issue from an ideological 
or PC Principal perspective. My work will focus mostly on 
cognitive science and pedagogical factors – as you'll see below, 
I'm interested in diversity issues from lots of angles, but I 
don't subscribe to the diversity ideology that is fashionable in 
American academia.

One D-specific question I do have: Have any women ever posted 
here? I scoured a bunch of threads here recently and couldn't 
find a female poster. By this I mean a poster whose supplied name 
was female, where a proper name was supplied (some people just 
have usernames). Of course we don't really know who is posting, 
and there could be some George Eliot situations, but the 
presence/absence of self-identified women is useful enough. Women 
are underrepresented in programming, but the skew in online 
programming communities is even more extreme – we're seeing 
near-zero percent in lots of boards. This is not a D-specific 
problem. Does anyone know of occasions where women posted here? 
Links?

Getting back to the research, recent studies have argued that one 
reason women are underrepresented in certain STEM fields is that 
smart women have more options than smart men. So think of the 
right tail of the bell curve, the men and women in that region on 
the relevant aptitudes for STEM fields. There's some evidence 
that smart women have a broader set of skills -- *on average* -- 
than equivalently smart men, perhaps including better social 
skills (or more interest in social interaction). This probably 
fits with stereotypes and intuitions a lot of people already held 
(lots of stereotypes are accurate, as probability distributions 
and so forth).

I'm interested in monocultures and diversity issues in a number 
of domains. I've done some recent work on the lack of 
philosophical and political diversity in social science, 
particularly in social psychology, and how this has undermined 
the quality and validity of our research (here's a recent paper 
by me and my colleagues in Behavioral and Brain Sciences: 
http://dx.doi.org/10.1017/S0140525X14000430). My interest in the 
lack of gender diversity in programming is an entirely different 
research area, but there isn't much rigorous social science and 
cognitive psychology research on this topic, which surprised me. 
I think it's an important and interesting issue. I also think a 
lot of the diversity efforts that are salient in tech right now 
are acting far too late in the cycle, sort of just waiting for 
women and minorities to show up. The skew starts long before 
people graduate with a CS degree, and I think Google, Microsoft, 
Apple, Facebook, et al. should think deeply about how programming 
language design might be contributing to these effects 
(especially before they roll out any more C-like programming 
languages).

Informally, I think what's happening in many cases is that when 
smart women are exposed to programming, it looks ridiculous and 
they think something like "Screw this – I'm going to med school", 
or any of a thousand permutations of that sentiment.

Mainstream PL syntax is extremely unintuitive and poorly designed 
by known pedagogical, epistemological, and communicative science 
standards. The vast majority people who are introduced to 
programming do not pursue it (likely true of many fields, but 
programming may see a smaller grab than most – this point 
requires a lot more context). I'm open to the possibility that 
the need to master the bizarre syntax of incumbent programming 
languages might serve as a useful filter for qualities valuable 
in a programmer, but I'm not sure how good or precise the filter 
is.

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;
}

There's a lot going on here from a learning, cognitive science 
and linguistic encoding standpoint.

1. There's no clear distinction between types and names. It's 
just plain text run-on phrases like "char string". string is an 
unfortunate name here, and reminds us that this would be a type 
in many modern languages, but my point here is that there's 
nothing to visually distinguish types from names. I would make 
types parenthetical or use a hashtag, so: MyString (char) or 
MyString #char (and definitely with types at the end of the 
declaration, with names and values up front and uninterrupted by 
type names – I'll be testing my hunches here).

2. There's some stuff about an integer c that equals 0, then 
something called count – it's not clear if this is a type or a 
name, since it's all by itself and doesn't follow the pattern we 
saw with int main and char string. It also seems to equal zero. 
Things that equal zero are strange in this context, and we often 
see bizarre x = 0 statements in programming when we don't mean it 
to actually equal zero, or not for long, but PL syntax usually 
doesn't include an explicit concept of a *starting value*, even 
though that's what it often is. We see this further down in the 
for loop.

3. The word *print* is being used to mean display on the screen. 
That's odd. Actually, the non-word printf is being used. We'd 
probably want to just say: display "Enter a string"

4. We switch the person or voice from an imperative "do this" as 
in printf, to some sort of narrator third-person voice with 
"gets". Who are we talking to? Who are we talking about? Who is 
getting? The alignment is the same as printf, and there's not an 
apparent actor or procedure that we would be referring to. 
(Relatedly, the third-person puts command that is so common in 
Ruby always makes me think of Silence of the Lambs – "It puts the 
lotion on its skin"... Or more recently, the third-person style 
of the Faceless Men, "a girl has no name", etc.)

5. Punctuation characters that already have strong semantics in 
English are used in ways that are inconsistent with and unrelated 
to those semantics. e.g. exclamation marks are jarring next to an 
equals sign, and it's not clear why such syntax is desirable. 
Same for percentage signs used to insert variables, rather than 
expressing a percentage. (I predict that the curly brace style of 
variable insertion in some HTML templating languages will be more 
intuitive for learners – they isolate the insertion, and don't 
have any conflicting semantics in normal English.)

I realize that some of this sprouted from the need to overload 
English punctuation in the ASCII-constrained computing world of 
the 1970s. The historical rationales for PL syntax decisions 
don't bear much on my research questions on learnability and the 
cognitive models people form when programming.

6. There are a bunch of semicolons and curly braces, and it's not 
clear why they're needed. Compilation will fail or the program 
will be broken if any of these characters are missing.

7. There are many other things going on here, lots of 
observations one could make from pedagogical, logical 
representation, and engineering standpoints.


Now, there are some reasonable hypotheses having to do with 
programming/tech culture and its effects on gender diversity. I 
think some of those can intertwine with PL design issues. I also 
think there might be an issue with the quality and compellingness 
of today's computing platforms, and the perceived power of 
computers to do amazing and interesting things. I don't think the 
platforms people are introduced to in CS education are very good 
at generating excitement about what computers can do. It would be 
interesting to gauge what sorts of things people think they might 
be able to create, what sorts of problems they think they could 
solve, or new interfaces they could implement, after their 
introduction to programming. What horizons do they see? For 
example, there used to be a lot of excitement about what 
computers could do for education. Those visions have not 
materialized, and it's not clear that computing is doing anything 
non-trivial in education for reasoning ability, unlocking math 
aptitude, writing creativity, etc. It might actually be a net 
harm, with its effects on attention spans and language 
development, though this will be very complicated to assess.

Mobile has reinvigorated some idealism and creativity about 
computing. But the platforms people are introduced to or forced 
to use when learning programming are not mobile platforms, since 
you can't build complex applications on the devices themselves. 
Unix and Linux are extremely popular in CS, but are terrible 
examples for blue sky thinking about computing. Forcing people to 
learn Vim or Emacs, grep, and poorly designed command line 
interfaces that dump a bunch of unformatted text at you are 
disastrous decisions from a pedagogical standpoint. (See the 
BlueJ project for an effort to do something about this.) They do 
nothing to illustrate what new and exciting things you could 
build with computers, and they seem to mold students into a 
rigid, conformist nix, git, and markdown monoculture where 
computing is reduced to bizarre manipulations of ASCII text on a 
black 1980s DOS-like screen, and constantly fiddling with and 
repairing one's operating system just to be able to continue to 
work on this DOS-like screen (Unix/Linux requires a lot of 
maintenance and troubleshooting overhead, especially for 
beginners – if they also have to do this while learning 
programming, then programming itself could be associated with a 
life of neverending, maddening hassles and frustrations). The 
debugging experience on Unix/Linux will be painful. From a 
pedagogical standpoint, this situation looks like a doomsday 
scenario, the worst CS education approach we could devise.

The nuisance/hassle overhead of programming is probably worth a 
few studies in conjunction with my studies on syntax, and I'd 
guess the issues are related – the chance of success in 
programming, in getting a simple program to just work, is pretty 
low. It's not clear that it *needs* to be so low, and I want to 
isolate any platform/toolchain factors from any PL syntax 
factors. (The factors may not exist – I could be wrong across the 
board.)

That's all I've got for now. This isn't as well-organized as I'd 
like, but I wanted to get something out now or I'd likely let it 
slip for weeks.
May 09 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:

 One D-specific question I do have: Have any women ever posted 
 here?


Yes, I can think of.... three off the top of my head, and there's 
probably more that I just don't remember. Of course, I can name 
twenty male regular posters here without even thinking about it, 
so a skew is evident. I don't want to name any names though.


 The vast majority people who are introduced to programming do 
 not pursue it (likely true of many fields, but programming may 
 see a smaller grab than most – this point requires a lot more 
 context).


I'd be surprised if that point survives scrutiny, though I guess 
you need to define "introduced" and "pursue" to say more.

I'd also be surprised if you find an empirical gender gap after 
controlling for programming language syntax, too. Even if we 
grant that PL syntax is suboptimal, why would that result in a 
gender bias? But, hey, you never really know until you actually 
collect the data...
May 09 2016
parent reply Joe Duarte <jose.duarte asu.edu> writes:
On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote:


 I'd also be surprised if you find an empirical gender gap after 
 controlling for programming language syntax, too. Even if we 
 grant that PL syntax is suboptimal, why would that result in a 
 gender bias? But, hey, you never really know until you actually 
 collect the data...


I forgot to mention the math. You can run the model in your head. 
If group W has more career options than group M, W will be 
underrepresented in career domain A. The effect will be larger if 
A is less appealing than W's other options, ceteris paribus and 
with some starting assumptions. (But it doesn't need to be, if W 
has more options than M.)

If aspects of career domain A are *equally frustrating* for 
members of groups W and M, W will still be underrepresented (and 
M overrepresented) if people in W have more options. So we don't 
even need it to be the case that bizarre programming language 
design disproportionately annoys women for bizarre programming 
language design to result in the underrepresentation of women.

JD
May 09 2016
parent Joe Duarte <jose.duarte asu.edu> writes:
On Monday, 9 May 2016 at 20:29:12 UTC, Joe Duarte wrote:

 On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote:


 I'd also be surprised if you find an empirical gender gap 
 after controlling for programming language syntax, too. Even 
 if we grant that PL syntax is suboptimal, why would that 
 result in a gender bias? But, hey, you never really know until 
 you actually collect the data...


 I forgot to mention the math. You can run the model in your 
 head. If group W has more career options than group M, W will 
 be underrepresented in career domain A. The effect will be 
 larger if A is less appealing than W's other options, ceteris 
 paribus and with some starting assumptions. (But it doesn't 
 need to be, if W has more options than M.)

 If aspects of career domain A are *equally frustrating* for 
 members of groups W and M, W will still be underrepresented 
 (and M overrepresented) if people in W have more options. So we 
 don't even need it to be the case that bizarre programming 
 language design disproportionately annoys women for bizarre 
 programming language design to result in the 
 underrepresentation of women.

 JD


(Assuming A is included in the set of options for both groups, 
and is equally available to them.)
May 09 2016
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
Am 09.05.2016 um 21:09 schrieb Joe Duarte:

 4. We switch the person or voice from an imperative "do this" as in
 printf, to some sort of narrator third-person voice with "gets".


"gets" is still imperative. It's short for "get string". Not saying that 
this is obvious, or that it's a good name.
May 09 2016
parent Joe Duarte <jose.duarte asu.edu> writes:
On Monday, 9 May 2016 at 20:17:40 UTC, ag0aep6g wrote:

 Am 09.05.2016 um 21:09 schrieb Joe Duarte:

 4. We switch the person or voice from an imperative "do this" 
 as in
 printf, to some sort of narrator third-person voice with 
 "gets".


 "gets" is still imperative. It's short for "get string". Not 
 saying that this is obvious, or that it's a good name.


Ah, I forgot about that! I think puts has the same abbreviation 
structure right? put string... I think knowing/remembering that 
it's an abbreviation would make it less distracting. My calling 
it a shift in voice is incorrect assuming people remember what it 
stands for.

JD
May 09 2016
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:

 One D-specific question I do have: Have any women ever posted 
 here? I scoured a bunch of threads here recently and couldn't 
 find a female poster. By this I mean a poster whose supplied 
 name was female, where a proper name was supplied (some people 
 just have usernames). Of course we don't really know who is 
 posting, and there could be some George Eliot situations, but 
 the presence/absence of self-identified women is useful enough. 
 Women are underrepresented in programming, but the skew in 
 online programming communities is even more extreme – we're 
 seeing near-zero percent in lots of boards. This is not a 
 D-specific problem. Does anyone know of occasions where women 
 posted here? Links?


One of the presenters at the recent DConfs is female:

http://dconf.org/2013/talks/chevalier_boisvert.html

She has posted in the forum occasionally.  There seem to be 
others, though obviously a minority.  Of course, given the 
prevalence of pseudonyms, it is impossible to tell much of the 
time, as you mentioned.


 Getting back to the research, recent studies have argued that 
 one reason women are underrepresented in certain STEM fields is 
 that smart women have more options than smart men. So think of 
 the right tail of the bell curve, the men and women in that 
 region on the relevant aptitudes for STEM fields. There's some 
 evidence that smart women have a broader set of skills -- *on 
 average* -- than equivalently smart men, perhaps including 
 better social skills (or more interest in social interaction). 
 This probably fits with stereotypes and intuitions a lot of 
 people already held (lots of stereotypes are accurate, as 
 probability distributions and so forth).


Or women are underrepresented at the high end of the distribution 
for "reasoning" skills, from which STEM mostly hires, because 
their variance is lower, ie the Summers hypothesis that led to 
his resignation.  This seems to be backed up by the fact that 
high SAT math scores are dominated by young men, just as the same 
is true for high SAT reading scores and young women.  Of course, 
math is not "reasoning" and many programmers are bad at math, but 
they're at least adjacent skills.


 I also think a lot of the diversity efforts that are salient in 
 tech right now are acting far too late in the cycle, sort of 
 just waiting for women and minorities to show up. The skew 
 starts long before people graduate with a CS degree, and I 
 think Google, Microsoft, Apple, Facebook, et al. should think 
 deeply about how programming language design might be 
 contributing to these effects (especially before they roll out 
 any more C-like programming languages).


Most programmers don't have a CS degree.  Programming language 
design may play a small role in the gender/race "monoculture," 
but other issues likely have much greater effect.


 Informally, I think what's happening in many cases is that when 
 smart women are exposed to programming, it looks ridiculous and 
 they think something like "Screw this – I'm going to med 
 school", or any of a thousand permutations of that sentiment.


Except that women only account for one-third of doctors and 
lawyers in the US, so even if they're going there instead, 
there's not enough of them to swing the numbers significantly in 
those fields either.


 Mainstream PL syntax is extremely unintuitive and poorly 
 designed by known pedagogical, epistemological, and 
 communicative science standards. The vast majority people who 
 are introduced to programming do not pursue it (likely true of 
 many fields, but programming may see a smaller grab than most – 
 this point requires a lot more context). I'm open to the 
 possibility that the need to master the bizarre syntax of 
 incumbent programming languages might serve as a useful filter 
 for qualities valuable in a programmer, but I'm not sure how 
 good or precise the filter is.


Syntax is a lesser concern when programming.  PL syntax can be 
forboding to a newcomer, particularly something like Haskell, but 
getting your code to compile and run properly is the real 
difficulty.  If you make the low bar of syntax even lower, that 
does nothing to change the even higher bar behind it, ie changing 
the syntax is unlikely to affect the bigger filter of dealing 
with the structured process of coding.


 1. There's no clear distinction between types and names. It's 
 just plain text run-on phrases like "char string". string is an 
 unfortunate name here, and reminds us that this would be a type 
 in many modern languages, but my point here is that there's 
 nothing to visually distinguish types from names. I would make 
 types parenthetical or use a hashtag, so: MyString (char) or 
 MyString #char (and definitely with types at the end of the 
 declaration, with names and values up front and uninterrupted 
 by type names – I'll be testing my hunches here).


Most programmers use some form of syntax highlighting in their 
editor, where char is shown in a different color of text than 
MyString, exhibiting the visual difference you want while not 
requiring extra typing or syntax.


 5. Punctuation characters that already have strong semantics in 
 English are used in ways that are inconsistent with and 
 unrelated to those semantics. e.g. exclamation marks are 
 jarring next to an equals sign, and it's not clear why such 
 syntax is desirable. Same for percentage signs used to insert 
 variables, rather than expressing a percentage. (I predict that 
 the curly brace style of variable insertion in some HTML 
 templating languages will be more intuitive for learners – they 
 isolate the insertion, and don't have any conflicting semantics 
 in normal English.)

 I realize that some of this sprouted from the need to overload 
 English punctuation in the ASCII-constrained computing world of 
 the 1970s. The historical rationales for PL syntax decisions 
 don't bear much on my research questions on learnability and 
 the cognitive models people form when programming.


I agree that PL use of such symbols can be counter-intuitive- 
rather than ending statements with a "." and joining them with a 
";", PL syntax flipped the two- but history has a lot to do with 
the status quo, for the same reasons that English has not been 
"cleaned up" in a long time either.  You may be right about 
learnability, but that's not what is considered most important.

You have a huge cohort that is used to the old language and you 
cannot just have everyone jump ship to a whole new syntax when 
some new generation of programmers enters the field, as both 
groups have to work together.  So you see slow evolution instead, 
as new languages make moderate changes and old ones try to tweak 
a bit in non-breaking ways with newer releases.

I think there's a lot of potential for automated source 
translation, where you choose one syntax locally and automated 
translators show the same code to another programmer in a 
different syntax.  These could range from very minor issues like 
formatting to swapping the use of "{}" and "()", or even bigger 
changes.  However, nobody has really pursued this fully yet, as 
it's considered a minor issue.


 6. There are a bunch of semicolons and curly braces, and it's 
 not clear why they're needed. Compilation will fail or the 
 program will be broken if any of these characters are missing.


Both were clearly explained in the previous thread.  Perhaps you 
feel whitespace is enough, but some explained why they feel it 
isn't.


 Now, there are some reasonable hypotheses having to do with 
 programming/tech culture and its effects on gender diversity. I 
 think some of those can intertwine with PL design issues. I 
 also think there might be an issue with the quality and 
 compellingness of today's computing platforms, and the 
 perceived power of computers to do amazing and interesting 
 things. I don't think the platforms people are introduced to in 
 CS education are very good at generating excitement about what 
 computers can do. It would be interesting to gauge what sorts 
 of things people think they might be able to create, what sorts 
 of problems they think they could solve, or new interfaces they 
 could implement, after their introduction to programming. What 
 horizons do they see? For example, there used to be a lot of 
 excitement about what computers could do for education. Those 
 visions have not materialized, and it's not clear that 
 computing is doing anything non-trivial in education for 
 reasoning ability, unlocking math aptitude, writing creativity, 
 etc. It might actually be a net harm, with its effects on 
 attention spans and language development, though this will be 
 very complicated to assess.


Education is a very backwards field, it's not surprising that 
they're way behind.  Of course, society itself is behind on what 
computing can do, so it's little different in most fields.


 Mobile has reinvigorated some idealism and creativity about 
 computing. But the platforms people are introduced to or forced 
 to use when learning programming are not mobile platforms, 
 since you can't build complex applications on the devices 
 themselves.


Not true, I have been programming exclusively on a tablet for the 
last six months, after my ultrabook died.  I have built Android 
apps from scratch on Android itself 
(https://github.com/termux/termux-packages/issues/63#issuecomment-184115581),
though I speculate that I may have been the first to do so. ;) The bigger issue
is that programming on a smartphone or tablet without a physical keyboard is a
pain that nobody wants to go through, but as mobile OS's are evolving to better
support physical keyboards and desktop-style UIs, that is changing.

Within a decade, I suspect the vast majority of programming will 
be interfaced through mobile devices, whether locally or 
accessing a remote server, as this guy has already done (though 
most will connect their mobile device to a bigger monitor when at 
their desk, once Android N and its multi-window features are out):

http://bergie.iki.fi/blog/working-on-android/
http://bergie.iki.fi/blog/six-weeks-working-android/


 Unix and Linux are extremely popular in CS, but are terrible 
 examples for blue sky thinking about computing. Forcing people 
 to learn Vim or Emacs, grep, and poorly designed command line 
 interfaces that dump a bunch of unformatted text at you are 
 disastrous decisions from a pedagogical standpoint. (See the 
 BlueJ project for an effort to do something about this.) They 
 do nothing to illustrate what new and exciting things you could 
 build with computers, and they seem to mold students into a 
 rigid, conformist nix, git, and markdown monoculture where 
 computing is reduced to bizarre manipulations of ASCII text on 
 a black 1980s DOS-like screen, and constantly fiddling with and 
 repairing one's operating system just to be able to continue to 
 work on this DOS-like screen (Unix/Linux requires a lot of 
 maintenance and troubleshooting overhead, especially for 
 beginners – if they also have to do this while learning 
 programming, then programming itself could be associated with a 
 life of neverending, maddening hassles and frustrations). The 
 debugging experience on Unix/Linux will be painful. From a 
 pedagogical standpoint, this situation looks like a doomsday 
 scenario, the worst CS education approach we could devise.


I agree that the UNIX interface you describe has been antiquated 
for decades.  However, I disagree with your aside about 
support/maintenance as you don't have to install and support 
linux on your own computer in order to take part.  I attended a 
university where UNIX workstations were made available in central 
locations to all engineers, requiring no maintenance from me.  It 
is one of the main reasons I did not have my own computer the 
whole time, despite more than a third of my engineering work 
being done on one.


 The nuisance/hassle overhead of programming is probably worth a 
 few studies in conjunction with my studies on syntax, and I'd 
 guess the issues are related – the chance of success in 
 programming, in getting a simple program to just work, is 
 pretty low. It's not clear that it *needs* to be so low, and I 
 want to isolate any platform/toolchain factors from any PL 
 syntax factors. (The factors may not exist – I could be wrong 
 across the board.)


Rather than looking at the technology first, I'd start by talking 
to the groups you think are affected by those tools and see what 
they tell you.  It could be the existing monoculture itself that 
puts them off, they don't care about the higher pay that STEM 
often comes with, or they just find technical concepts more 
difficult, regardless of syntax.  I recently asked a young woman 
why she wanted to go into chemical engineering and she told me 
it's because it paid the most, which surprised me.

You won't get the answers you're looking for about what puts them 
off by assuming the reasons, but by asking them and collecting 
that data.
May 09 2016
next sibling parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 10 May 2016 at 06:47:50 UTC, Joakim wrote:

 Or women are underrepresented at the high end of the 
 distribution for "reasoning" skills,


That is not specific to reasoning skill. Take pretty much any 
measure, and male will have a higher standard deviation. It is 
easy to explain: recessive genes on the chromosome X are always 
expressed in men.

But shht, genetic is a social construct of the heteronormative 
patriarchy !
May 10 2016
prev sibling next sibling parent qznc <qznc web.de> writes:
On Tuesday, 10 May 2016 at 06:47:50 UTC, Joakim wrote:

 I agree that PL use of such symbols can be counter-intuitive- 
 rather than ending statements with a "." and joining them with 
 a ";", PL syntax flipped the two- but history has a lot to do 
 with the status quo, for the same reasons that English has not 
 been "cleaned up" in a long time either.  You may be right 
 about learnability, but that's not what is considered most 
 important.


Wrt to distinguishing types and variables, we also do not do this 
in english prose. We could for example distinguish verbs and 
nouns with some punctuation. This would make a sentence like 
"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" 
more clear.

We do distinguish names via upper case. In many programming 
languages this is convention. In some it is even mandatory. 
Usually it is switch around though. Names are lower case, but 
classes are upper case.
May 10 2016
prev sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 10 May 2016 at 06:47:50 UTC, Joakim wrote:

 Or women are underrepresented at the high end of the 
 distribution for "reasoning" skills, from which STEM mostly 
 hires, because their variance is lower, ie the Summers 
 hypothesis that led to his resignation.  This seems to be 
 backed up by the fact that high SAT math scores are dominated 
 by young men, just as the same is true for high SAT reading 
 scores and young women.


Though by Summers hypothesis women should only dominate average 
scores and never high scores :)


 I agree that the UNIX interface you describe has been 
 antiquated for decades.


Interface is not only to consume, but also to build. We did learn 
GTK though (well, we were actually only told to do it ourselves) 
to build a very simple graphic application.
May 10 2016
prev sibling next sibling parent qznc <qznc web.de> writes:
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:

 Now, there are some reasonable hypotheses having to do with 
 programming/tech culture and its effects on gender diversity. I 
 think some of those can intertwine with PL design issues. I 
 also think there might be an issue with the quality and 
 compellingness of today's computing platforms, and the 
 perceived power of computers to do amazing and interesting 
 things. I don't think the platforms people are introduced to in 
 CS education are very good at generating excitement about what 
 computers can do. It would be interesting to gauge what sorts 
 of things people think they might be able to create, what sorts 
 of problems they think they could solve, or new interfaces they 
 could implement, after their introduction to programming. What 
 horizons do they see? For example, there used to be a lot of 
 excitement about what computers could do for education. Those 
 visions have not materialized, and it's not clear that 
 computing is doing anything non-trivial in education for 
 reasoning ability, unlocking math aptitude, writing creativity, 
 etc. It might actually be a net harm, with its effects on 
 attention spans and language development, though this will be 
 very complicated to assess.

 Mobile has reinvigorated some idealism and creativity about 
 computing. But the platforms people are introduced to or forced 
 to use when learning programming are not mobile platforms, 
 since you can't build complex applications on the devices 
 themselves. Unix and Linux are extremely popular in CS, but are 
 terrible examples for blue sky thinking about computing. 
 Forcing people to learn Vim or Emacs, grep, and poorly designed 
 command line interfaces that dump a bunch of unformatted text 
 at you are disastrous decisions from a pedagogical standpoint. 
 (See the BlueJ project for an effort to do something about 
 this.) They do nothing to illustrate what new and exciting 
 things you could build with computers, and they seem to mold 
 students into a rigid, conformist nix, git, and markdown 
 monoculture where computing is reduced to bizarre manipulations 
 of ASCII text on a black 1980s DOS-like screen, and constantly 
 fiddling with and repairing one's operating system just to be 
 able to continue to work on this DOS-like screen (Unix/Linux 
 requires a lot of maintenance and troubleshooting overhead, 
 especially for beginners – if they also have to do this while 
 learning programming, then programming itself could be 
 associated with a life of neverending, maddening hassles and 
 frustrations). The debugging experience on Unix/Linux will be 
 painful. From a pedagogical standpoint, this situation looks 
 like a doomsday scenario, the worst CS education approach we 
 could devise.



I applaud you for staying and explaining, although you clearly 
get some destructive feedback here.

Your criticism of vim, emacs, and Unix is misleading imho. Vim 
and emacs are not optimized for learning. They are power tools 
for professionals. There are easier text editors for beginners. 
The command line on the other hand is great in my opinion. It 
makes you have a conversation with your computer instead of 
pointing at buttons. The basic idea is currently reinvented as 
"chatbots are the new UI breakthrough" [0]. Sure, discoverability 
is a problem with the terminal. GUIs fixed that by showing 
buttons for every possible action. Chatbots use AI tech to make 
sense of anything, but we lose precision with this conversational 
style. A professional tool requires precision.

I agree that syntax is mostly historical baggage. The main reason 
why D mimics C, is because people are familiar with it. Not 
because the syntax is good. It is bad and everybody knows it. 
However, I'm not talking about curly braces or semicolons. I 
think it is weird that we use the "equals" character to express 
"assign".

[0] e.g. http://marketingland.com/microsoft-build-171006
May 10 2016
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/9/2016 12:09 PM, Joe Duarte wrote:

 [gender issues]


Please take that stuff to reddit, or email Joe if you want to debate such. This 
is a technical forum about the D programming language.

This forum is not concerned with anyone's gender, religion, politics, age,
race, 
whatever.

Discussing programming language design is fine.
May 10 2016
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
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
May 10 2016
parent reply Joe Duarte <jose.duarte asu.edu> writes:
On Tuesday, 10 May 2016 at 13:40:30 UTC, Chris wrote:

 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.



You're arguing that the 32-line example on finding characters 
frequency in a string was too complicated? I think it might help 
to clarify my purpose in that post. It was to pick a random 
example of a simple C program to illustrate the sorts of problems 
programming syntax has from a cognitive science and pedagogical 
standpoint. For my purposes, I didn't need to choose a 6-line 
program, and something that short would probably undermine my 
ability to illustrate some things.

Note also that I saw myself as being a bit *charitable* to C by 
choosing that sample. For instance, I didn't use an example 
littered with the word "void". Void in English most commonly 
means invalid, canceled, or not binding, as in a voided check, a 
void contract (such as where one party is a minor), and "null and 
void" is a common usage, so starting a function declaration by 
declaring it void is jarring. There was a discussion that Walter 
linked to from the late 1980s I believe, where people were 
requesting that this issue be fixed in C (Walter linked to it as 
background on the naming of D I think). It's a hole in the type 
system and bad syntax -- I predict that it adds confusion to 
learning a language that uses it.

Something I've wondered is if foreigners actually have an easier 
time with the syntax of English programming languages. The 
jarring usage of terms like void, or things like dollar signs and 
question marks to not mark dollars or questions, might not be 
jarring to non-native English speakers, or non-English speakers. 
For them, all this might just be arbitrary tokens and they'd just 
have to learn what the tokens signify (and it's very interesting 
to think about how they and English speakers learn this). Andreas 
Stefik did some research where he used a randomly generated 
programming syntax, I think it was called Randomo, and some 
mainstream languages were just as hard to learn as the randomly 
generated one (Java or C, I think -- they're both pretty bad 
anyway). To non-English speakers, and especially 
non-Latin-alphabet-users, all of our programming languages might 
be randomly generated for all intents and purposes.

You gave a Hello World example above. Don't get me started on 
Hello World. Well, too late... Here's the deal. It's not just 
Hello World -- a ton of programming examples in online references 
and introductory texts, perhaps most of them, present programs 
that are pointless. By "pointless" I mean they do no useful work. 
Commonly, they repeat something back to us. So here we're typing 
64-ish characters into a console or something in order to have 
the computer repeat back an 11-character string to us. If we have 
to type "Hello World" (and a bunch of other stuff) in order for 
the computer to display it, well we've not had a productive 
interaction.

I think examples should quickly illustrate computers computing or 
otherwise doing productive things for us. Displaying a string in 
a console environment is also too far removed from normal 
computing environments like a smartphone or Windows 10/MacOS 
graphical desktop. If we're going to teach displaying a pop-up 
message, we should cut right to a windowing environment from the 
outset.

I think the Hello World example is also extremely confusing to 
newbies and rational knowers. It's not clear why the main 
function has an integer type, since we're not doing anything with 
integers, why there is an empty set of parentheses after it (what 
are they doing there?), why we're saying "printf" when we don't 
want to use our printer, why there's a newline code *inside the 
quotes*, why we are "returning" 0, and what that even means, and 
of course why there are curly braces just sitting there on 
otherwise blank lines. We just wanted to display "Hello World", 
not deal with all this other stuff.
May 14 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 14 May 2016 at 23:42:33 UTC, Joe Duarte wrote:

 By "pointless" I mean they do no useful work.


I agree, I like programs that are actually somewhat interesting.

For example, for my simpledisplay.d, the two examples I shows are:

http://dpldocs.info/experimental-docs/arsd.simpledisplay.html#event-example

and

http://dpldocs.info/experimental-docs/arsd.simpledisplay.html#pong-example


The first one demonstrates basic functions of the code, but also 
gives a useful program to run and play with. It reacts to you 
interactively so you can get a look at how your user actions are 
handled by the code.

The second one dives right into something a lot of my users are 
actually going to want to do: run some kind of interactive 
animation like a game or a scientific data explorer thing. A lot 
of people have told me they didn't actually read my document, 
they just copy/pasted that pong thing and started playing around 
to learn how to use it.


So that's my preference for examples: something you can actually 
use and modify for yourself. These are longer samples, but that 
doesn't seem to be a problem with anyone I've talked to.


 Displaying a string in a console environment is also too far 
 removed from normal computing environments like a smartphone or 
 Windows 10/MacOS graphical desktop.


seriously, death to scanf and printf.

(I like printf actually, but I REALLY dislike the standard C 
console input paradigm - and I dislike D's readf even more. I 
want to see it killed, so many newbie questions for it, and what 
do they really get out of it? It isn't all that useful in the 
real world.)



That said, the point of hello world more often than not isn't 
actually to do anything except make sure the user's compiler is 
installed correctly.... and for that, it kinda works.
May 14 2016
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 15.05.2016 01:42, Joe Duarte wrote:

 Note also that I saw myself as being a bit *charitable* to C by choosing
 that sample. For instance, I didn't use an example littered with the
 word "void". Void in English most commonly means invalid, canceled, or
 not binding, as in a voided check, a void contract (such as where one
 party is a minor), and "null and void" is a common usage, so starting a
 function declaration by declaring it void is jarring.


(According to Wikipedia, 90% of the world population are not native 
English language speakers.)


 There was a
 discussion that Walter linked to from the late 1980s I believe, where
 people were requesting that this issue be fixed in C (Walter linked to
 it as background on the naming of D I think). It's a hole in the type
 system


There's no hole, it's just awkward.


 and bad syntax -- I predict that it adds confusion to learning a
 language that uses it.


That's mostly due to the amount of semantic special casing, it's not 
just narrow syntax concerns. E.g. 'void' is a "type" that is claimed to 
have no values, but functions returning void can still terminate normally.
May 15 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 15 May 2016 at 11:04:22 UTC, Timon Gehr wrote:

 That's mostly due to the amount of semantic special casing, 
 it's not just narrow syntax concerns. E.g. 'void' is a "type" 
 that is claimed to have no values, but functions returning void 
 can still terminate normally.


It may have values, but you cannot access them. A pointer to void 
is roughly the same as the identity-capability «Tag» in Pony 
(http://tutorial.ponylang.org/capabilities/reference-capabilities.html). So
void is a "view" on an object that only may give access to the identity, but
not the content: «I know of your existence, but not what you are».

In C it is not uncommon to cast variables to void, in order to 
silence "unused variable" warnings... Basically saying "I am 
using this, but not accessing it"...
May 15 2016
prev sibling parent Chris <wendlec tcd.ie> writes:
On Saturday, 14 May 2016 at 23:42:33 UTC, Joe Duarte wrote:

[snip]

As Adam pointed out, the merits of "Hello, world!" are not it's 
usefulness as a program, but it's role in making the newbie 
acquainted with the language, it's syntax and how to compile and 
run it. And it is often rewarding to absolute beginners, as they 
are happy that the computer does what they told it to do, even if 
it's as trivial as printing "Hello, world!" to the screen.

I have the feeling that your basic assumption is that humans are 
quite stupid and that characters confuse them, if they have a 
different meaning in a different context. "OMG '$' does not mean 
"dollar" here! Quick bring in the therapy dog!" Context is the 
keyword. When I write "He sold the car for $2,000." I know it's 
about money. When I write D code such as

myArray[1..$]  // => myArray[1..myArray.length]

I know it's not about money. It's about the length of the array. 
I once helped a young student with Perl, she needed it for 
biology. She understood the concept of hash tables ("like a 
dictionary") and she wasn't confused about the "$" sign. People 
are not that thick, you know. It's the context. When I read a 
text in Spanish I know which sound is represented by the grapheme 
<ñ>. When I read in Portuguese the same sound is represented by 
<nh>, and then again in Galician the grapheme <nh> represents the 
sound /ɳ/. It's the context, and of course humans are capable of 
assigning different meanings or values to the same symbols in 
different contexts and keep them separate.
May 16 2016
prev sibling next sibling parent reply QAston <qaston gmail.com> writes:
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:

 I'm interested in people's *first encounters* with programming, 
 in high school or college, how men and women might 
 differentially assess programming as a career option, and why.


My motivation was that computers were awesome and I wanted to 
work with those machines no matter what. I had no internet when I 
was learning programming, that resulted in one of the least 
optimal path to learn programming - by an introductory course to 
x86 assembly programming from a journal I had. It was anything 
but intuitive. Many people I know started with manuals to their 8 
bit computers, which was probably even less intuitive. So, 
anecdotally speaking, motivation is the key.


 One D-specific question I do have: Have any women ever posted 
 here? I scoured a bunch of threads here recently and couldn't 
 find a female poster. By this I mean a poster whose supplied 
 name was female, where a proper name was supplied (some people 
 just have usernames). Of course we don't really know who is 
 posting, and there could be some George Eliot situations, but 
 the presence/absence of self-identified women is useful enough. 
 Women are underrepresented in programming, but the skew in 
 online programming communities is even more extreme – we're 
 seeing near-zero percent in lots of boards. This is not a 
 D-specific problem. Does anyone know of occasions where women 
 posted here? Links?


There are women on these forums, they just apparently don't feel 
the urge to disclose their sex with every post so that curious 
social scientists can count them.


 I'm interested in monocultures and diversity issues in a number 
 of domains. I've done some recent work on the lack of 
 philosophical and political diversity in social science, 
 particularly in social psychology, and how this has undermined 
 the quality and validity of our research (here's a recent paper 
 by me and my colleagues in Behavioral and Brain Sciences: 
 http://dx.doi.org/10.1017/S0140525X14000430). My interest in 
 the lack of gender diversity in programming is an entirely 
 different research area, but there isn't much rigorous social 
 science and cognitive psychology research on this topic, which 
 surprised me. I think it's an important and interesting issue. 
 I also think a lot of the diversity efforts that are salient in 
 tech right now are acting far too late in the cycle, sort of 
 just waiting for women and minorities to show up. The skew 
 starts long before people graduate with a CS degree, and I 
 think Google, Microsoft, Apple, Facebook, et al. should think 
 deeply about how programming language design might be 
 contributing to these effects (especially before they roll out 
 any more C-like programming languages).


It seems odd that the abstract of your paper is about the 
ideological diversity, but here you focus on gender diversity. 
Diversity of ideas is important, though you don't show the link 
between gender diversity and diversity of ideas.


 Informally, I think what's happening in many cases is that when 
 smart women are exposed to programming, it looks ridiculous and 
 they think something like "Screw this – I'm going to med 
 school", or any of a thousand permutations of that sentiment.

 Mainstream PL syntax is extremely unintuitive and poorly 
 designed by known pedagogical, epistemological, and 
 communicative science standards. The vast majority people who 
 are introduced to programming do not pursue it (likely true of 
 many fields, but programming may see a smaller grab than most – 
 this point requires a lot more context). I'm open to the 
 possibility that the need to master the bizarre syntax of 
 incumbent programming languages might serve as a useful filter 
 for qualities valuable in a programmer, but I'm not sure how 
 good or precise the filter is.


Your research seems to have a very big ommission: textual 
representation is not only representation of programs - therfore 
programming doesn't have to have syntax. The first programming 
enviroment I was introduced to was an executable flowchart 
enviroment.

I've been doing courses for lego robotics programming for 
children(7-14yr olds, both boys and girls, though more boys 
attended the courses) using NXT-G programming environment. Lots 
of fun, mostly teaching by examples, multiple teachers so that we 
could keep up with those kids.

The oldest ones could also attend a course which would teach them 
how to do those things in a C-like programming language (NXC). 
Kids had much more difficulty with that, because writing a 
program in text requires making much more decisions and effort, 
for no return noticable for them. And we couldn't go through 
theory (like, what are expressions, etc) because these were just 
children not used to lectures:P


 1. There's no clear distinction between types and names. It's 
 just plain text run-on phrases like "char string". string is an 
 unfortunate name here, and reminds us that this would be a type 
 in many modern languages, but my point here is that there's 
 nothing to visually distinguish types from names. I would make 
 types parenthetical or use a hashtag, so: MyString (char) or 
 MyString #char (and definitely with types at the end of the 
 declaration, with names and values up front and uninterrupted 
 by type names – I'll be testing my hunches here).


Relevant XKCD:
https://www.explainxkcd.com/wiki/index.php/1306:_Sigil_Cycle
with emphasis on title text there!

There are programming conventions which are arbitrary 
restrictions programmers impose on their codebases to be more 
readable and consistent. Types are written using CamelCase, 
variable names using lowerCamelCase. First capital letter can be 
enforced (golang does this for public/private symbols afaik), but 
it's not practical because sometimes a name has to defy the 
imposed rules. There are tools that apply those conventions if 
language is simple enough, like Java.


 2. There's some stuff about an integer c that equals 0, then 
 something called count – it's not clear if this is a type or a 
 name, since it's all by itself and doesn't follow the pattern 
 we saw with int main and char string. It also seems to equal 
 zero. Things that equal zero are strange in this context, and 
 we often see bizarre x = 0 statements in programming when we 
 don't mean it to actually equal zero, or not for long, but PL 
 syntax usually doesn't include an explicit concept of a 
 *starting value*, even though that's what it often is. We see 
 this further down in the for loop.


All modern languages abstract iteration away. They have abstract 
string types. C has 44 years now, try moving to something more 
recent, new languages don't have these problems.


 3. The word *print* is being used to mean display on the 
 screen. That's odd. Actually, the non-word printf is being 
 used. We'd probably want to just say: display "Enter a string"


Historical artifact, there was time in computing when only output 
was through printers.


 4. We switch the person or voice from an imperative "do this" 
 as in printf, to some sort of narrator third-person voice with 
 "gets". Who are we talking to? Who are we talking about? Who is 
 getting? The alignment is the same as printf, and there's not 
 an apparent actor or procedure that we would be referring to. 
 (Relatedly, the third-person puts command that is so common in 
 Ruby always makes me think of Silence of the Lambs – "It puts 
 the lotion on its skin"... Or more recently, the third-person 
 style of the Faceless Men, "a girl has no name", etc.)


Nonsense, as somebody posted in another reply. Again legacy of C 
shows, saving every precious character. As for ruby - it's 
dynamically typed, so the type is embeded in the function name to 
disambigulate. Puts happened to be a name already known to 
programmers.

Your interpretation of puts is just scary. You should really 
co-author your work with a programmer, otherwise you risk 
reaching riddiculous conclusions, like malicious intent by people 
naming basic io functions.


 5. Punctuation characters that already have strong semantics in 
 English are used in ways that are inconsistent with and 
 unrelated to those semantics. e.g. exclamation marks are 
 jarring next to an equals sign, and it's not clear why such 
 syntax is desirable. Same for percentage signs used to insert 
 variables, rather than expressing a percentage. (I predict that 
 the curly brace style of variable insertion in some HTML 
 templating languages will be more intuitive for learners – they 
 isolate the insertion, and don't have any conflicting semantics 
 in normal English.)



 I realize that some of this sprouted from the need to overload 
 English punctuation in the ASCII-constrained computing world of 
 the 1970s. The historical rationales for PL syntax decisions 
 don't bear much on my research questions on learnability and 
 the cognitive models people form when programming.


About != being unintuitive - do you remember unicode for 
notequals sign? I don't, i prefer something that's actually on my 
keyboard. Some languages used <>. Didn't catch on. != also looks 
like not-equals when you squint your eyes, so it's very easy to 
remember.

Another thing - since you mentioned diversity. Different people 
find different things intuitive, as intuitions are formed by 
experiences. By catering to intuitions of some people you create 
a preference for them and decrease diversity [citation needed:P].

Mathematics as taught in universities is all about breaking your 
intuitions and making you think in abstracts instead, so that you 
won't bring your biases with you into it. Intuitions do not help 
there, they lead to wrong conclusions and apparent paradoxes. 
Programming languages need to specify the program precisely for 
the computer and for other readers, they can't rely on your gut. 
You also can't optimize programming for first experience, 
programming needs to be optimized for mainteance. As for 
leveraging intuitions there are approaches like BDD or creation 
of DSLs which use intuitions in programming in a systematic way.


 6. There are a bunch of semicolons and curly braces, and it's 
 not clear why they're needed. Compilation will fail or the 
 program will be broken if any of these characters are missing.


When you take a programming course it's clear why they're needed. 
They denote statements and blocks, which have an effect on how 
the code works. This is taught in programming courses. That 
information has to be somwhere, so you still need to know 
language constructs, otherwise you don't really know what you're 
doing.


 Mobile has reinvigorated some idealism and creativity about 
 computing. But the platforms people are introduced to or forced 
 to use when learning programming are not mobile platforms, 
 since you can't build complex applications on the devices 
 themselves. Unix and Linux are extremely popular in CS, but are 
 terrible examples for blue sky thinking about computing. 
 Forcing people to learn Vim or Emacs, grep, and poorly designed 
 command line interfaces that dump a bunch of unformatted text 
 at you are disastrous decisions from a pedagogical standpoint. 
 (See the BlueJ project for an effort to do something about 
 this.) They do nothing to illustrate what new and exciting 
 things you could build with computers, and they seem to mold 
 students into a rigid, conformist nix, git, and markdown 
 monoculture where computing is reduced to bizarre manipulations 
 of ASCII text on a black 1980s DOS-like screen, and constantly 
 fiddling with and repairing one's operating system just to be 
 able to continue to work on this DOS-like screen (Unix/Linux 
 requires a lot of maintenance and troubleshooting overhead, 
 especially for beginners – if they also have to do this while 
 learning programming, then programming itself could be 
 associated with a life of neverending, maddening hassles and 
 frustrations). The debugging experience on Unix/Linux will be 
 painful. From a pedagogical standpoint, this situation looks 
 like a doomsday scenario, the worst CS education approach we 
 could devise.


Nobody really teaches unix/linux on introductory courses. Using 
the console is first thing you ever learn for a very simple 
reason: it's just 2 functions operating on simple text. Creating 
GUI is much more complicated and requires many more steps to 
achieve results. Browsers are probably the easiest gui 
environments to get into.


 The nuisance/hassle overhead of programming is probably worth a 
 few studies in conjunction with my studies on syntax, and I'd 
 guess the issues are related – the chance of success in 
 programming, in getting a simple program to just work, is 
 pretty low. It's not clear that it *needs* to be so low, and I 
 want to isolate any platform/toolchain factors from any PL 
 syntax factors. (The factors may not exist – I could be wrong 
 across the board.)


Don't program by chance, take a course instead :)
May 13 2016
next sibling parent reply Joe Duarte <jose.duarte asu.edu> writes:
On Friday, 13 May 2016 at 22:13:50 UTC, QAston wrote:


 Mainstream PL syntax is extremely unintuitive and poorly 
 designed by known pedagogical, epistemological, and 
 communicative science standards. The vast majority people who 
 are introduced to programming do not pursue it (likely true of 
 many fields, but programming may see a smaller grab than most 
 – this point requires a lot more context). I'm open to the 
 possibility that the need to master the bizarre syntax of 
 incumbent programming languages might serve as a useful filter 
 for qualities valuable in a programmer, but I'm not sure how 
 good or precise the filter is.


 Your research seems to have a very big ommission: textual 
 representation is not only representation of programs - 
 therfore programming doesn't have to have syntax. The first 
 programming enviroment I was introduced to was an executable 
 flowchart enviroment.


Quick note: I'm looking at the effects of the syntax and design 
of incumbent programming languages on the appeal of programming 
to people in general, with some specific questions concerning the 
appeal of programming to women (particularly elite women who have 
many career options.)

So that research track is bound to the world as I find it, and 
the world as I find it is a world where graphical programming 
languages and environments are not widely used, and where all the 
programming languages in wide use are plain text.

That said, I'm deeply interested in graphical and visual 
programming methods. I know quite a bit about them, have studied 
lots of historic efforts and even contemporary ones like Snap 
(http://snap.berkeley.edu/) and Scratch. Side note: I'm a bit of 
a Russophile, and I'm fascinated by the history of Soviet 
computing, with innovations like the Elbrus systems with tagged 
memory, and the ways they cloned major American computing 
platforms. Something I dug into last year is the DRAKON graphical 
programming language, which they built as part of the Buran space 
shuttle program. Very interesting: 
https://en.wikipedia.org/wiki/DRAKON

Programmers tend to be conservative in many respects. There's the 
assumption that programming must consist of a programmer typing 
plain text into a flat document that contains many levels of 
abstraction and many different kinds of concepts. By flat I mean 
that it's this continuous blob that takes no account of its 
content, of varying levels of abstraction, of the wildly 
different kinds of work and reasoning that are expressed in this 
run-on text file. Then a compiler takes this text and does its 
thing. There's very little visual representation. Type systems 
are quite arbitrary and primitive -- we could've moved to 
real-world types a long time ago, which would be much safer and a 
hell of a lot more productive. Type theory imports the barbarism 
of legacy type systems and doesn't question the assumption that 
the universe is best carved into ints and floats at the source 
code level, instead of prices, km, or seconds. Compilers still 
don't know that something called lastName is a string (or better 
yet, a *text* type -- strings are for yo-yos), or that salesTax 
is a decimal. That's really simple stuff. It's nuts that with 
semantic names we still have to assign types, and that those 
types are so much coarser than the information already in the 
name. Our vaunted notion of type safety is based on an incredibly 
coarse split between ints, floats, and maybe strings or arrays. I 
think it should confuse every CS student how these distinctions 
came to preoccupy us, and why we don't have anything more to say 
about types at this point in history.

So graphical programming is a huge change for a very conservative 
field, and probably has worse than "script kiddie" connotations 
for many professional programmers. And there's no compelling 
evidence that graphical is better than text for many use cases. 
It might be better for some people, and a one-to-one mapping 
between a powerful textual PL and a graphical form would be very 
interesting.
May 14 2016
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 15.05.2016 05:02, Joe Duarte wrote:

 Type systems are quite arbitrary and primitive


That may apply to the popular ones.


 -- we could've moved to  real-world types


The "real world" is complex and there are bound to be some modeling 
limitations. I don't really see what "real-world" type is supposed to mean.


 a long time ago, which would be much safer and a hell
 of a lot more productive.


How would that work/what's the difference?


 Type theory imports the barbarism of legacy type systems  and doesn't
 question the assumption that the universe is best carved into ints and
 floats


?
Refer to https://en.wikipedia.org/wiki/Type_theory
The C type system isn't something one would use as a basis to make 
statements about what type theory does and doesn't do.

In the end, somebody needs to think about representation. On top of 
that, there should be some abstraction, and existing languages already 
target this to varying extents.

What is the new insight here?


 at the source code level, instead of prices, km, or seconds


'km' and 'second' are actually values. Distance and duration are types.
Also, what is a price, precisely?
May 15 2016
parent reply Joe Duarte <jose.duarte asu.edu> writes:
On Sunday, 15 May 2016 at 10:52:47 UTC, Timon Gehr wrote:

 On 15.05.2016 05:02, Joe Duarte wrote:

 Type systems are quite arbitrary and primitive


 That may apply to the popular ones.


 -- we could've moved to  real-world types


 The "real world" is complex and there are bound to be some 
 modeling limitations. I don't really see what "real-world" type 
 is supposed to mean.


 a long time ago, which would be much safer and a hell
 of a lot more productive.


 How would that work/what's the difference?


Here's what I think is the first big exploration of a real-world 
type system: 
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.397

I would combine it with something like Precimonious: 
http://www.cs.berkeley.edu/~ksen/papers/precimonious.pdf
May 15 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 15 May 2016 at 17:09:56 UTC, Joe Duarte wrote:

 On Sunday, 15 May 2016 at 10:52:47 UTC, Timon Gehr wrote:

 On 15.05.2016 05:02, Joe Duarte wrote:

 Type systems are quite arbitrary and primitive


 That may apply to the popular ones.


 -- we could've moved to  real-world types


 The "real world" is complex and there are bound to be some 
 modeling limitations. I don't really see what "real-world" 
 type is supposed to mean.


 a long time ago, which would be much safer and a hell
 of a lot more productive.


 How would that work/what's the difference?


 Here's what I think is the first big exploration of a 
 real-world type system: 
 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.397


Well, C++14 provides the chrono std-library for the 
time-dimension with proper suffixes for literals for hours, 
minutes, seconds etc so yo can write 1.5h, 90.0min or 5400.0s and 
get the typing and the scaling right.

You can also implement your own literals with a custom suffix for 
various units e.g. 12_km, 44_miles and they will yield the 
correct custom type.

Of course, this is rather simple compared to the goals within 
deductive databases/ontology/AI research.
May 15 2016
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 14.05.2016 00:13, QAston wrote:

 About != being unintuitive - do you remember unicode for notequals sign?
 I don't, i prefer something that's actually on my keyboard.


There's really no reason to.
I simply type \neq in my text editor in order to get ≠.
(And M-x xx gives me the corresponding hex code point 2260.)
May 15 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 15 May 2016 at 10:29:29 UTC, Timon Gehr wrote:

 On 14.05.2016 00:13, QAston wrote:

 About != being unintuitive - do you remember unicode for 
 notequals sign?
 I don't, i prefer something that's actually on my keyboard.


 There's really no reason to.
 I simply type \neq in my text editor in order to get ≠.
 (And M-x xx gives me the corresponding hex code point 2260.)


On my OS-X keyboard it is just Alt + "=", and that is the Apple 
default.
May 15 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 15 May 2016 at 10:31:39 UTC, Ola Fosheim Grøstad wrote:

 On my OS-X keyboard it is just Alt + "=", and that is the Apple 
 default.


Let me add to this that tilde "~" is hidden as Alt+"¨".

Anyway, any professional can get used to this quite easily.

I sometimes find myself having to use "US" keyboard layout on a 
Norwegian keyboard, sometimes an OS-X layout on a Windows 
keyboard. I just have to try 2-4 keystrokes the first time before 
I remember where they are hidden.

These things are stored in the "spine". E.g. I stopped playing 
trumpet over 30 years ago, but I could easily pick it up again at 
roughly the same level.

The retention is amazing whey you train "moves" regularly for a 
couple of years!
May 15 2016
prev sibling parent Ryan Frame <dlang ryanjframe.com> writes:
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:

 I don't think the platforms people are introduced to in CS 
 education are very good at generating excitement about what 
 computers can do. It would be interesting to gauge what sorts 
 of things people think they might be able to create, what sorts 
 of problems they think they could solve, or new interfaces they 
 could implement, after their introduction to programming. What 
 horizons do they see?


I think you're partly right here, but you seem to think somebody 
can read a "Learn [language] in 24 Hours" book and write awesome 
software; that isn't going to happen. Programming is a craft. I 
play classical guitar as a hobby, but I have a friend that 
embodies classical music. I can play, but because of his 
dedication to the music he is (I would argue) one of the great 
composers of our time.

When I first started playing guitar, my teacher barely had me 
playing anything, but we talked a lot about music theory, and 
that made learning easier later on. We need to be careful that 
making things easier for beginners doesn't hurt them in the long 
run.


 For example, there used to be a lot of excitement about what 
 computers could do for education. Those visions have not 
 materialized, and it's not clear that computing is doing 
 anything non-trivial in education for reasoning ability, 
 unlocking math aptitude, writing creativity, etc. It might 
 actually be a net harm, with its effects on attention spans and 
 language development, though this will be very complicated to 
 assess.


I think it is often harmful -- we're teaching people to use the 
tech rather than using the tech to teach people.

My Kiwanis club gives money to our kindergarten teachers every 
year for school supplies, and the teachers generally come and 
talk about what they're doing with the kids. The first year they 
used iPads they weren't that happy -- they should be reading from 
a book, they're too young, etc. The next year they were showing 
off what they could do with the kids now; they still had 
complaints, but they were able to help kids learn in ways they 
could not previously do.

How we use the technology determines whether it's positive or a 
negative. We just need to quit placing tech in schools because 
it's shiny and use when it's beneficial.


 Forcing people to learn Vim or Emacs, grep, and poorly designed 
 command line interfaces that dump a bunch of unformatted text 
 at you are disastrous decisions from a pedagogical standpoint. 
 (See the BlueJ project for an effort to do something about 
 this.) They do nothing to illustrate what new and exciting 
 things you could build with computers, and they seem to mold 
 students into a rigid, conformist nix, git, and markdown 
 monoculture where computing is reduced to bizarre manipulations 
 of ASCII text on a black 1980s DOS-like screen, and constantly 
 fiddling with and repairing one's operating system just to be 
 able to continue to work on this DOS-like screen (Unix/Linux 
 requires a lot of maintenance and troubleshooting overhead, 
 especially for beginners – if they also have to do this while 
 learning programming, then programming itself could be 
 associated with a life of neverending, maddening hassles and 
 frustrations). The debugging experience on Unix/Linux will be 
 painful. From a pedagogical standpoint, this situation looks 
 like a doomsday scenario, the worst CS education approach we 
 could devise.


This reads more like a rant than an analysis of programming 
tools/procedures. You and I seem to have had very different 
introductions to programming.

The idea that we should no longer be stuck with text-based 
odd-looking programming languages and tools is kind of like 
claiming that since we can get running water on the 30th floor of 
a building, plumbers shouldn't have to deal with the mess of a 
septic tank. There must always be somebody at the low-level. The 
projects you mention that are heading the direction you prefer 
are able to do so because somebody else had done a lot of the 
messy work (or they're doing the messy work for their users). 
There will always be a programmer working in the sewers to let 
another work from the penthouse.

After we "fix" programming, are we going to tell the chip 
designers that things should be simple and intuitive enough that 
anyone can build a computer processor?
May 15 2016