Follow-up post explaining research rationale

[Joakim via Digitalmars-d]

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.