Follow-up post explaining research rationale

[QAston via Digitalmars-d]

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 :)