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.
