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