Re: Follow-up post explaining research rationale
On Saturday, 14 May 2016 at 23:42:33 UTC, Joe Duarte wrote:
[snip]
As Adam pointed out, the merits of "Hello, world!" are not it's
usefulness as a program, but it's role in making the newbie
acquainted with the language, it's syntax and how to compile and
run it. And it is often rewarding to absolute beginners, as they
are happy that the computer does what they told it to do, even if
it's as trivial as printing "Hello, world!" to the screen.
I have the feeling that your basic assumption is that humans are
quite stupid and that characters confuse them, if they have a
different meaning in a different context. "OMG '$' does not mean
"dollar" here! Quick bring in the therapy dog!" Context is the
keyword. When I write "He sold the car for $2,000." I know it's
about money. When I write D code such as
myArray[1..$] // => myArray[1..myArray.length]
I know it's not about money. It's about the length of the array.
I once helped a young student with Perl, she needed it for
biology. She understood the concept of hash tables ("like a
dictionary") and she wasn't confused about the "$" sign. People
are not that thick, you know. It's the context. When I read a
text in Spanish I know which sound is represented by the grapheme
<ñ>. When I read in Portuguese the same sound is represented by
, and then again in Galician the grapheme represents the
sound /ɳ/. It's the context, and of course humans are capable of
assigning different meanings or values to the same symbols in
different contexts and keep them separate.
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote: 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? I think you're partly right here, but you seem to think somebody can read a "Learn [language] in 24 Hours" book and write awesome software; that isn't going to happen. Programming is a craft. I play classical guitar as a hobby, but I have a friend that embodies classical music. I can play, but because of his dedication to the music he is (I would argue) one of the great composers of our time. When I first started playing guitar, my teacher barely had me playing anything, but we talked a lot about music theory, and that made learning easier later on. We need to be careful that making things easier for beginners doesn't hurt them in the long run. 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. I think it is often harmful -- we're teaching people to use the tech rather than using the tech to teach people. My Kiwanis club gives money to our kindergarten teachers every year for school supplies, and the teachers generally come and talk about what they're doing with the kids. The first year they used iPads they weren't that happy -- they should be reading from a book, they're too young, etc. The next year they were showing off what they could do with the kids now; they still had complaints, but they were able to help kids learn in ways they could not previously do. How we use the technology determines whether it's positive or a negative. We just need to quit placing tech in schools because it's shiny and use when it's beneficial. 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. This reads more like a rant than an analysis of programming tools/procedures. You and I seem to have had very different introductions to programming. The idea that we should no longer be stuck with text-based odd-looking programming languages and tools is kind of like claiming that since we can get running water on the 30th floor of a building, plumbers shouldn't have to deal with the mess of a septic tank. There must always be somebody at the low-level. The projects you mention that are heading the direction you prefer are able to do so because somebody else had done a lot of the messy work (or they're doing the messy work for their users). There will always be a programmer working in the sewers to let another work from the penthouse. After we "fix" programming, are we going to tell the chip designers that things should be simple and intuitive enough that anyone can build a computer processor?
Re: Follow-up post explaining research rationale
On Sunday, 15 May 2016 at 17:09:56 UTC, Joe Duarte wrote: On Sunday, 15 May 2016 at 10:52:47 UTC, Timon Gehr wrote: On 15.05.2016 05:02, Joe Duarte wrote: Type systems are quite arbitrary and primitive That may apply to the popular ones. -- we could've moved to real-world types The "real world" is complex and there are bound to be some modeling limitations. I don't really see what "real-world" type is supposed to mean. a long time ago, which would be much safer and a hell of a lot more productive. How would that work/what's the difference? Here's what I think is the first big exploration of a real-world type system: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.397 Well, C++14 provides the chrono std-library for the time-dimension with proper suffixes for literals for hours, minutes, seconds etc so yo can write 1.5h, 90.0min or 5400.0s and get the typing and the scaling right. You can also implement your own literals with a custom suffix for various units e.g. 12_km, 44_miles and they will yield the correct custom type. Of course, this is rather simple compared to the goals within deductive databases/ontology/AI research.
Re: Follow-up post explaining research rationale
On Sunday, 15 May 2016 at 10:52:47 UTC, Timon Gehr wrote: On 15.05.2016 05:02, Joe Duarte wrote: Type systems are quite arbitrary and primitive That may apply to the popular ones. -- we could've moved to real-world types The "real world" is complex and there are bound to be some modeling limitations. I don't really see what "real-world" type is supposed to mean. a long time ago, which would be much safer and a hell of a lot more productive. How would that work/what's the difference? Here's what I think is the first big exploration of a real-world type system: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.397 I would combine it with something like Precimonious: http://www.cs.berkeley.edu/~ksen/papers/precimonious.pdf
Re: Follow-up post explaining research rationale
On Sunday, 15 May 2016 at 11:04:22 UTC, Timon Gehr wrote: That's mostly due to the amount of semantic special casing, it's not just narrow syntax concerns. E.g. 'void' is a "type" that is claimed to have no values, but functions returning void can still terminate normally. It may have values, but you cannot access them. A pointer to void is roughly the same as the identity-capability «Tag» in Pony (http://tutorial.ponylang.org/capabilities/reference-capabilities.html). So void is a "view" on an object that only may give access to the identity, but not the content: «I know of your existence, but not what you are». In C it is not uncommon to cast variables to void, in order to silence "unused variable" warnings... Basically saying "I am using this, but not accessing it"...
Re: Follow-up post explaining research rationale
On 15.05.2016 01:42, Joe Duarte wrote: Note also that I saw myself as being a bit *charitable* to C by choosing that sample. For instance, I didn't use an example littered with the word "void". Void in English most commonly means invalid, canceled, or not binding, as in a voided check, a void contract (such as where one party is a minor), and "null and void" is a common usage, so starting a function declaration by declaring it void is jarring. (According to Wikipedia, 90% of the world population are not native English language speakers.) There was a discussion that Walter linked to from the late 1980s I believe, where people were requesting that this issue be fixed in C (Walter linked to it as background on the naming of D I think). It's a hole in the type system There's no hole, it's just awkward. and bad syntax -- I predict that it adds confusion to learning a language that uses it. That's mostly due to the amount of semantic special casing, it's not just narrow syntax concerns. E.g. 'void' is a "type" that is claimed to have no values, but functions returning void can still terminate normally.
Re: Follow-up post explaining research rationale
On 15.05.2016 05:02, Joe Duarte wrote: Type systems are quite arbitrary and primitive That may apply to the popular ones. -- we could've moved to real-world types The "real world" is complex and there are bound to be some modeling limitations. I don't really see what "real-world" type is supposed to mean. a long time ago, which would be much safer and a hell of a lot more productive. How would that work/what's the difference? Type theory imports the barbarism of legacy type systems and doesn't question the assumption that the universe is best carved into ints and floats ? Refer to https://en.wikipedia.org/wiki/Type_theory The C type system isn't something one would use as a basis to make statements about what type theory does and doesn't do. In the end, somebody needs to think about representation. On top of that, there should be some abstraction, and existing languages already target this to varying extents. What is the new insight here? at the source code level, instead of prices, km, or seconds 'km' and 'second' are actually values. Distance and duration are types. Also, what is a price, precisely?
Re: Follow-up post explaining research rationale
On Sunday, 15 May 2016 at 10:31:39 UTC, Ola Fosheim Grøstad wrote: On my OS-X keyboard it is just Alt + "=", and that is the Apple default. Let me add to this that tilde "~" is hidden as Alt+"¨". Anyway, any professional can get used to this quite easily. I sometimes find myself having to use "US" keyboard layout on a Norwegian keyboard, sometimes an OS-X layout on a Windows keyboard. I just have to try 2-4 keystrokes the first time before I remember where they are hidden. These things are stored in the "spine". E.g. I stopped playing trumpet over 30 years ago, but I could easily pick it up again at roughly the same level. The retention is amazing whey you train "moves" regularly for a couple of years!
Re: Follow-up post explaining research rationale
On Sunday, 15 May 2016 at 10:29:29 UTC, Timon Gehr wrote: On 14.05.2016 00:13, QAston wrote: About != being unintuitive - do you remember unicode for notequals sign? I don't, i prefer something that's actually on my keyboard. There's really no reason to. I simply type \neq in my text editor in order to get ≠. (And M-x xx gives me the corresponding hex code point 2260.) On my OS-X keyboard it is just Alt + "=", and that is the Apple default.
Re: Follow-up post explaining research rationale
On 14.05.2016 00:13, QAston wrote: About != being unintuitive - do you remember unicode for notequals sign? I don't, i prefer something that's actually on my keyboard. There's really no reason to. I simply type \neq in my text editor in order to get ≠. (And M-x xx gives me the corresponding hex code point 2260.)
Re: Follow-up post explaining research rationale
On Friday, 13 May 2016 at 22:13:50 UTC, QAston wrote: 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. Quick note: I'm looking at the effects of the syntax and design of incumbent programming languages on the appeal of programming to people in general, with some specific questions concerning the appeal of programming to women (particularly elite women who have many career options.) So that research track is bound to the world as I find it, and the world as I find it is a world where graphical programming languages and environments are not widely used, and where all the programming languages in wide use are plain text. That said, I'm deeply interested in graphical and visual programming methods. I know quite a bit about them, have studied lots of historic efforts and even contemporary ones like Snap (http://snap.berkeley.edu/) and Scratch. Side note: I'm a bit of a Russophile, and I'm fascinated by the history of Soviet computing, with innovations like the Elbrus systems with tagged memory, and the ways they cloned major American computing platforms. Something I dug into last year is the DRAKON graphical programming language, which they built as part of the Buran space shuttle program. Very interesting: https://en.wikipedia.org/wiki/DRAKON Programmers tend to be conservative in many respects. There's the assumption that programming must consist of a programmer typing plain text into a flat document that contains many levels of abstraction and many different kinds of concepts. By flat I mean that it's this continuous blob that takes no account of its content, of varying levels of abstraction, of the wildly different kinds of work and reasoning that are expressed in this run-on text file. Then a compiler takes this text and does its thing. There's very little visual representation. Type systems are quite arbitrary and primitive -- we could've moved to real-world types a long time ago, which would be much safer and a hell of a lot more productive. Type theory imports the barbarism of legacy type systems and doesn't question the assumption that the universe is best carved into ints and floats at the source code level, instead of prices, km, or seconds. Compilers still don't know that something called lastName is a string (or better yet, a *text* type -- strings are for yo-yos), or that salesTax is a decimal. That's really simple stuff. It's nuts that with semantic names we still have to assign types, and that those types are so much coarser than the information already in the name. Our vaunted notion of type safety is based on an incredibly coarse split between ints, floats, and maybe strings or arrays. I think it should confuse every CS student how these distinctions came to preoccupy us, and why we don't have anything more to say about types at this point in history. So graphical programming is a huge change for a very conservative field, and probably has worse than "script kiddie" connotations for many professional programmers. And there's no compelling evidence that graphical is better than text for many use cases. It might be better for some people, and a one-to-one mapping between a powerful textual PL and a graphical form would be very interesting.
Re: Follow-up post explaining research rationale
On Saturday, 14 May 2016 at 23:42:33 UTC, Joe Duarte wrote: By "pointless" I mean they do no useful work. I agree, I like programs that are actually somewhat interesting. For example, for my simpledisplay.d, the two examples I shows are: http://dpldocs.info/experimental-docs/arsd.simpledisplay.html#event-example and http://dpldocs.info/experimental-docs/arsd.simpledisplay.html#pong-example The first one demonstrates basic functions of the code, but also gives a useful program to run and play with. It reacts to you interactively so you can get a look at how your user actions are handled by the code. The second one dives right into something a lot of my users are actually going to want to do: run some kind of interactive animation like a game or a scientific data explorer thing. A lot of people have told me they didn't actually read my document, they just copy/pasted that pong thing and started playing around to learn how to use it. So that's my preference for examples: something you can actually use and modify for yourself. These are longer samples, but that doesn't seem to be a problem with anyone I've talked to. Displaying a string in a console environment is also too far removed from normal computing environments like a smartphone or Windows 10/MacOS graphical desktop. seriously, death to scanf and printf. (I like printf actually, but I REALLY dislike the standard C console input paradigm - and I dislike D's readf even more. I want to see it killed, so many newbie questions for it, and what do they really get out of it? It isn't all that useful in the real world.) That said, the point of hello world more often than not isn't actually to do anything except make sure the user's compiler is installed correctly and for that, it kinda works.
Re: Follow-up post explaining research rationale
On Tuesday, 10 May 2016 at 13:40:30 UTC, Chris wrote:
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:
[snip]
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;
}
[snap]
I went to www.programmingsimplified.com/c-program-examples and
found that this was example 48 out of 59. The examples start
with:
- Hello world
- Print Integer
- Addition
- Odd or Even
- Add, subtract, multiply and divide
- Check vowel
- Leap year
- Add digits
- [...]
and so on, with increasing complexity.
Nobody starts with examples like the one above. More likely
with number 1 in their list:
#include
int main()
{
printf("Hello world\n");
return 0;
}
Not so difficult to understand.
You're arguing that the 32-line example on finding characters
frequency in a string was too complicated? I think it might help
to clarify my purpose in that post. It was to pick a random
example of a simple C program to illustrate the sorts of problems
programming syntax has from a cognitive science and pedagogical
standpoint. For my purposes, I didn't need to choose a 6-line
program, and something that short would probably undermine my
ability to illustrate some things.
Note also that I saw myself as being a bit *charitable* to C by
choosing that sample. For instance, I didn't use an example
littered with the word "void". Void in English most commonly
means invalid, canceled, or not binding, as in a voided check, a
void contract (such as where one party is a minor), and "null and
void" is a common usage, so starting a function declaration by
declaring it void is jarring. There was a discussion that Walter
linked to from the late 1980s I believe, where people were
requesting that this issue be fixed in C (Walter linked to it as
background on the naming of D I think). It's a hole in the type
system and bad syntax -- I predict that it adds confusion to
learning a language that uses it.
Something I've wondered is if foreigners actually have an easier
time with the syntax of English programming languages. The
jarring usage of terms like void, or things like dollar signs and
question marks to not mark dollars or questions, might not be
jarring to non-native English speakers, or non-English speakers.
For them, all this might just be arbitrary tokens and they'd just
have to learn what the tokens signify (and it's very interesting
to think about how they and English speakers learn this). Andreas
Stefik did some research where he used a randomly generated
programming syntax, I think it was called Randomo, and some
mainstream languages were just as hard to learn as the randomly
generated one (Java or C, I think -- they're both pretty bad
anyway). To non-English speakers, and especially
non-Latin-alphabet-users, all of our programming languages might
be randomly generated for all intents and purposes.
You gave a Hello World example above. Don't get me started on
Hello World. Well, too late... Here's the deal. It's not just
Hello World -- a ton of programming examples in online references
and introductory texts, perhaps most of them, present programs
that are pointless. By "pointless" I mean they do no useful work.
Commonly, they repeat something back to us. So here we're typing
64-ish characters into a console or something in order to have
the computer repeat back an 11-character string to us. If we have
to type "Hello World" (and a bunch of other stuff) in order for
the computer to display it, well we've not had a productive
interaction.
I think examples should quickly illustrate computers computing or
otherwise doing productive things for us. Displaying a string in
a console environment is also too far removed from normal
computing environments like a smartphone or Windows 10/MacOS
graphical desktop. If we're going to teach displaying a pop-up
message, we should cut right to a windowing environment from the
outset.
I think the Hello World example is also extremely confusing to
newbies and rational knowers. It's not clear why the main
function has an integer type, since we're not doing anything with
integers, why there is an empty set of parentheses after it (what
are they doing there?), why we're saying "printf" when we don't
want to use our printer, why there's a newline code *inside the
Re: Follow-up post explaining research rationale
On Tuesday, 10 May 2016 at 06:47:50 UTC, Joakim wrote: 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. Though by Summers hypothesis women should only dominate average scores and never high scores :) I agree that the UNIX interface you describe has been antiquated for decades. Interface is not only to consume, but also to build. We did learn GTK though (well, we were actually only told to do it ourselves) to build a very simple graphic application.
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:
[snip]
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;
}
[snap]
I went to www.programmingsimplified.com/c-program-examples and
found that this was example 48 out of 59. The examples start with:
- Hello world
- Print Integer
- Addition
- Odd or Even
- Add, subtract, multiply and divide
- Check vowel
- Leap year
- Add digits
- [...]
and so on, with increasing complexity.
Nobody starts with examples like the one above. More likely with
number 1 in their list:
#include
int main()
{
printf("Hello world\n");
return 0;
}
Not so difficult to understand.
A Python version similar to the example you gave above looks like
this [1]:
def char_frequency(str1):
dict = {}
for n in str1:
keys = dict.keys()
if n in keys:
dict[n] += 1
else:
dict[n] = 1
return dict
print(char_frequency('google.com'))
Throw this at the uninitiated newbie and s/he will have similar
difficulties in understanding it at first sight. You're talking
about showing someone who's beginning how to learn guitar charts
from Paco de Lucía's masterpieces.
It's not the syntax, it's being used to thinking in a certain
way, and this takes time and practice (like an instrument). Once
you've reached a certain level you can parse things at sight.
More important than syntax, in my opinion, are language features,
i.e. what can be expressed in and with a language. If you look at
both of the examples above, they tackle the same problem from a
slightly different angle. But it's still the same underlying
logic. That's why it is not hard for programmers to edit/write
code in languages they don't know well. They know _what_ to do,
and just look at _how_ they can best do it in a given language.
And this is where D kicks in. D and other languages explore how
abstract concepts and problems can best be solved, what tools
should be available etc. If anything, you should concentrate on
matching the world to the machine using programming languages,
instead of focusing on trivial syntax features. It's like
discussing whether it's important to write the expression "in
spite" as one word or two, while what counts is its function:
Inspite of the bad weather, we could get to the conference in
time.
It's the same as
In spite of the bad weather, we could get to the conference in
time.
The important thing is that we have the concept of "in spite",
and we can add more concepts and more ways of expressing them.
Syntax is trivial. Syntax is a mere convention that can be
learned and, what is more, is confined to a closed domain that
rarely interferes with other "realities".
[1]
http://www.w3resource.com/python-exercises/python-data-type-exercise-7.php
Re: Follow-up post explaining research rationale
On 5/9/2016 12:09 PM, Joe Duarte wrote: [gender issues] Please take that stuff to reddit, or email Joe if you want to debate such. This is a technical forum about the D programming language. This forum is not concerned with anyone's gender, religion, politics, age, race, whatever. Discussing programming language design is fine.
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote: 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... One (over-)simplified aspect to this, I think, is that men are more prone to the sort of monomania required to become expert programmers. Our life goals are also different such as Andrei and Walter being prepared to spend huge efforts (despite the real risk of failure) making their baby, D, successful. Women have a different emotional / life-goals setup, and are not inclined to such endeavours (massive generalisation I know, but we are necessarily talking in generalisations). Of course all men and women sit on spectra of male/female behaviours, and we observers of those spectra each have our own unique life experiences of such, leading to different opinions. This is just my take on it.
Re: Follow-up post explaining research rationale
On Tuesday, 10 May 2016 at 09:24:12 UTC, Bill Hicks wrote: On Tuesday, 10 May 2016 at 06:47:50 UTC, Joakim wrote: One of the presenters at the recent DConfs is female: http://dconf.org/2013/talks/chevalier_boisvert.html Maxime used to be a guy at one point, is that not the case? She's probably got bigger balls than you have...
Re: Follow-up post explaining research rationale
On Tuesday, 10 May 2016 at 06:47:50 UTC, Joakim wrote: 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. Wrt to distinguishing types and variables, we also do not do this in english prose. We could for example distinguish verbs and nouns with some punctuation. This would make a sentence like "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" more clear. We do distinguish names via upper case. In many programming languages this is convention. In some it is even mandatory. Usually it is switch around though. Names are lower case, but classes are upper case.
Re: Follow-up post explaining research rationale
On Tuesday, 10 May 2016 at 06:47:50 UTC, Joakim wrote: One of the presenters at the recent DConfs is female: http://dconf.org/2013/talks/chevalier_boisvert.html Maxime used to be a guy at one point, is that not the case?
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote: 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. I applaud you for staying and explaining, although you clearly get some destructive feedback here. Your criticism of vim, emacs, and Unix is misleading imho. Vim and emacs are not optimized for learning. They are power tools for professionals. There are easier text editors for beginners. The command line on the other hand is great in my opinion. It makes you have a conversation with your computer instead of pointing at buttons. The basic idea is currently reinvented as "chatbots are the new UI breakthrough" [0]. Sure, discoverability is a problem with the terminal. GUIs fixed that by showing buttons for every possible action. Chatbots use AI tech to make sense of anything, but we lose precision with this conversational style. A professional tool requires precision. I agree that syntax is mostly historical baggage. The main reason why D mimics C, is because people are familiar with it. Not because the syntax is good. It is bad and everybody knows it. However, I'm not talking about curly braces or semicolons. I think it is weird that we use the "equals" character to express "assign". [0] e.g. http://marketingland.com/microsoft-build-171006
Re: Follow-up post explaining research rationale
On Tuesday, 10 May 2016 at 06:47:50 UTC, Joakim wrote: Or women are underrepresented at the high end of the distribution for "reasoning" skills, That is not specific to reasoning skill. Take pretty much any measure, and male will have a higher standard deviation. It is easy to explain: recessive genes on the chromosome X are always expressed in men. But shht, genetic is a social construct of the heteronormative patriarchy !
Re: Follow-up post explaining research rationale
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
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 20:17:40 UTC, ag0aep6g wrote: Am 09.05.2016 um 21:09 schrieb Joe Duarte: 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". "gets" is still imperative. It's short for "get string". Not saying that this is obvious, or that it's a good name. Ah, I forgot about that! I think puts has the same abbreviation structure right? put string... I think knowing/remembering that it's an abbreviation would make it less distracting. My calling it a shift in voice is incorrect assuming people remember what it stands for. JD
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote: ... You're not addressing the root cause. America was founded on genocide, racism, sexism, and classism. That should be the starting point of such research, but nobody goes there because people, specially those who benefit from the current system, are not serious about changing anything. The idea that syntax has anything to do with women and minorities being underrepresented in the industry, or that it's some kind of deterrent, is the stupidest thing any one could come up with. It's like saying that the reason why more blacks do not have university degrees is because notebooks contain white sheets of paper instead of gray sheets of paper, or that #2 pencils lack blings. Idiot! Instead of saying shit like "PL syntax ... disproportionately deters qualified women", did you consider the possibility that maybe, just maybe, the current PL syntax disproportionately encourages white men to behave in sexist and racist manners? You see how retarded that sounds? So, you are completely ignoring the cultural, historical, and societal forces that have created the problems in the first place. Basically, not only is your hypotheses sexist in its own right, but you've completely shifted the blame of this injustice onto something completely artificial that has nothing to do with the problem.
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 20:29:12 UTC, Joe Duarte wrote: On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote: I'd also be surprised if you find an empirical gender gap after controlling for programming language syntax, too. Even if we grant that PL syntax is suboptimal, why would that result in a gender bias? But, hey, you never really know until you actually collect the data... I forgot to mention the math. You can run the model in your head. If group W has more career options than group M, W will be underrepresented in career domain A. The effect will be larger if A is less appealing than W's other options, ceteris paribus and with some starting assumptions. (But it doesn't need to be, if W has more options than M.) If aspects of career domain A are *equally frustrating* for members of groups W and M, W will still be underrepresented (and M overrepresented) if people in W have more options. So we don't even need it to be the case that bizarre programming language design disproportionately annoys women for bizarre programming language design to result in the underrepresentation of women. JD (Assuming A is included in the set of options for both groups, and is equally available to them.)
Re: Follow-up post explaining research rationale
On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote: I'd also be surprised if you find an empirical gender gap after controlling for programming language syntax, too. Even if we grant that PL syntax is suboptimal, why would that result in a gender bias? But, hey, you never really know until you actually collect the data... I forgot to mention the math. You can run the model in your head. If group W has more career options than group M, W will be underrepresented in career domain A. The effect will be larger if A is less appealing than W's other options, ceteris paribus and with some starting assumptions. (But it doesn't need to be, if W has more options than M.) If aspects of career domain A are *equally frustrating* for members of groups W and M, W will still be underrepresented (and M overrepresented) if people in W have more options. So we don't even need it to be the case that bizarre programming language design disproportionately annoys women for bizarre programming language design to result in the underrepresentation of women. JD
Re: Follow-up post explaining research rationale
Am 09.05.2016 um 21:09 schrieb Joe Duarte: 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". "gets" is still imperative. It's short for "get string". Not saying that this is obvious, or that it's a good name.
Re: Follow-up post explaining research rationale
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? Yes, I can think of three off the top of my head, and there's probably more that I just don't remember. Of course, I can name twenty male regular posters here without even thinking about it, so a skew is evident. I don't want to name any names though. 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'd be surprised if that point survives scrutiny, though I guess you need to define "introduced" and "pursue" to say more. I'd also be surprised if you find an empirical gender gap after controlling for programming language syntax, too. Even if we grant that PL syntax is suboptimal, why would that result in a gender bias? But, hey, you never really know until you actually collect the data...
Follow-up post explaining research rationale
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
