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.
