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.

Reply via email to