www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Researcher question =?UTF-8?B?4oCT?= what's the point of semicolons

reply Joe Duarte <jose.duarte asu.edu> writes:
Hi all,

I'm a social scientist and I'm preparing some studies on the 
effects of programming language syntax on learning, motivation to 
pursue programming, as well as any disproportionate effects that 
PL syntax has on the appeal of programming to women (more on the 
latter in a separate post).

So I want to get a better idea of the rationale for various 
syntactical design decisions, and I'm going to ask you the same 
question I'll ask the Rust community:

Why are curly braces and semicolons necessary? What information 
do they carry that a compiler could not otherwise reliably obtain?

Here's an example from the D Overview page:


class Foo
{
     int foo(Bar c) { return c.bar; }
}

class Bar
{
     int bar() { return 3; }
}


Okay, if we remove the curly braces and semicolons, we have:


class Foo

     int foo(Bar c) return c.bar


class Bar

     int bar() return 3


Would it be difficult to compile the clean version? Would there 
be issues with the design of the lexer/parser? I assume the 
compiler would recognize keywords like return (and a clean syntax 
could drive different rules for what statements and expressions 
could appear on the same line and so forth).

In reality, a compiler would see the above with line ending 
characters terminating every line (e.g. U+000A), so it would be 
as line-aware as a human. I've never built lexers or parsers, 
much less compilers, so maybe I'm missing a major implementation 
hurdle. I'm just thinking that Facebook has built software that 
recognizes my face in other people's pictures, so it seems like 
building software that understands structured text would be a 
solved problem. It puzzles me to see so much apparent punctuation 
noise in a 21st-century language (and, to be fair, Rust puzzles 
me for the same reasons).

JD
May 02 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 03/05/2016 3:48 PM, Joe Duarte wrote:

 Hi all,

 I'm a social scientist and I'm preparing some studies on the effects of
 programming language syntax on learning, motivation to pursue
 programming, as well as any disproportionate effects that PL syntax has
 on the appeal of programming to women (more on the latter in a separate
 post).

 So I want to get a better idea of the rationale for various syntactical
 design decisions, and I'm going to ask you the same question I'll ask
 the Rust community:

 Why are curly braces and semicolons necessary? What information do they
 carry that a compiler could not otherwise reliably obtain?

 Here's an example from the D Overview page:


 class Foo
 {
     int foo(Bar c) { return c.bar; }
 }

 class Bar
 {
     int bar() { return 3; }
 }


 Okay, if we remove the curly braces and semicolons, we have:


 class Foo

     int foo(Bar c) return c.bar


 class Bar

     int bar() return 3


 Would it be difficult to compile the clean version? Would there be
 issues with the design of the lexer/parser? I assume the compiler would
 recognize keywords like return (and a clean syntax could drive different
 rules for what statements and expressions could appear on the same line
 and so forth).

 In reality, a compiler would see the above with line ending characters
 terminating every line (e.g. U+000A), so it would be as line-aware as a
 human. I've never built lexers or parsers, much less compilers, so maybe
 I'm missing a major implementation hurdle. I'm just thinking that
 Facebook has built software that recognizes my face in other people's
 pictures, so it seems like building software that understands structured
 text would be a solved problem. It puzzles me to see so much apparent
 punctuation noise in a 21st-century language (and, to be fair, Rust
 puzzles me for the same reasons).

 JD


One of the benefits of having semicolons and braces is that you can have 
your entire source file on one line!
But ok in all seriousness as shown by Lua its not really required.
Its a stylistic choice at least for me it is.
May 02 2016
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/2/2016 8:48 PM, Joe Duarte wrote:

 Why are curly braces and semicolons necessary? What information do they
 carry that a compiler could not otherwise reliably obtain?


You are correct in that they are (mostly) redundant. Some ambiguities 
can arise because D is not a whitespace delimited language. However, the 
real reasons are:

1. Redundancy in specification means the compiler can catch more 'typo' 
mistakes rather than having them compile successfully and then behave 
mysteriously. If a language has 0 redundancy, then any 
8745b48%%&*&hjdsfh string would be a valid program. Redundancy is a 
critical feature of high reliability languages.

Many languages have removed redundancy only to put it back in after 
bitter experience. The classic is implicit declaration of variables.

2. The redundancy also means the compiler can 'resync' itself to the 
input once a syntactic error is detected.

3. It's instantly familiar to those who program already in "curly brace" 
languages.
May 02 2016
next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 02 May 2016 21:23:48 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On 5/2/2016 8:48 PM, Joe Duarte wrote:

 Why are curly braces and semicolons necessary? What information do
 they carry that a compiler could not otherwise reliably obtain?


 You are correct in that they are (mostly) redundant. Some ambiguities
 can arise because D is not a whitespace delimited language. However,
 the real reasons are:

 1. Redundancy in specification means the compiler can catch more
 'typo' mistakes rather than having them compile successfully and then
 behave mysteriously. If a language has 0 redundancy, then any
 8745b48%%&*&hjdsfh string would be a valid program. Redundancy is a
 critical feature of high reliability languages.


That redundancy also can make it much easier for the programmer to figure
out what's going on. And it better expresses the intent of the code when you
have some of those redundancies. Without them, it can be a lot less obvious
when something was intentional or a mistake (e.g. how far a particular line
was supposed to be indented).

I know that there are plenty of folks who start out programming with a
scripting language of some sort and don't like it when they have to deal
with braces and/or terminating semicolons, but I think that it's a lot like
static typing vs dynamic typing. At first, it might _seem_ more liberating
to have dynamic typing, but the number of errors that creep in with dynamic
typing is much higher than with static typing, because the compiler simply
isn't set up to catch many problems for you with a dynamic language, where
it is with a static one.

I think that it's clear that languages like python have shown that it's
possible to have a successful language with no curly braces or semicolons
and puncuation-like syntax overall, but I don't think that it's been shown
that it's necessarily a _good_ idea - just that it can work. It's not that
hard to find rants online from folks who used to love python's use of
whitespace as a delimiter only to have big enough problems with it in a
serious program that they now hate it with a passion.

- Jonathan M Davis
May 03 2016
prev sibling next sibling parent Henry Gouk <henry.gouk gmail.com> writes:
On Tuesday, 3 May 2016 at 04:23:48 UTC, Walter Bright wrote:

 1. Redundancy in specification means the compiler can catch 
 more 'typo' mistakes rather than having them compile 
 successfully and then behave mysteriously. If a language has 0 
 redundancy, then any 8745b48%%&*&hjdsfh string would be a valid 
 program. Redundancy is a critical feature of high reliability 
 languages.

 Many languages have removed redundancy only to put it back in 
 after bitter experience. The classic is implicit declaration of 
 variables.


An example of this would be that Apple SSL bug that has largely 
been blamed on optional curly braces for if statements with one 
line in the body.
May 03 2016
prev sibling parent reply Joe Duarte <jose.duarte asu.edu> writes:
On Tuesday, 3 May 2016 at 04:23:48 UTC, Walter Bright wrote:

 On 5/2/2016 8:48 PM, Joe Duarte wrote:

 Why are curly braces and semicolons necessary? What 
 information do they
 carry that a compiler could not otherwise reliably obtain?


 You are correct in that they are (mostly) redundant. Some 
 ambiguities can arise because D is not a whitespace delimited 
 language. However, the real reasons are:

 1. Redundancy in specification means the compiler can catch 
 more 'typo' mistakes rather than having them compile 
 successfully and then behave mysteriously. If a language has 0 
 redundancy, then any 8745b48%%&*&hjdsfh string would be a valid 
 program. Redundancy is a critical feature of high reliability 
 languages.

 Many languages have removed redundancy only to put it back in 
 after bitter experience. The classic is implicit declaration of 
 variables.

 2. The redundancy also means the compiler can 'resync' itself 
 to the input once a syntactic error is detected.

 3. It's instantly familiar to those who program already in 
 "curly brace" languages.


Your point about redundancy is interesting. I assume typos aren't 
random, and I wonder if anyone has researched the patterns there, 
which could inform where PL designers would want to insert 
guards/redundancy with syntax. I wonder if I could dig into this 
with GitHub and BitBucket repos. Maybe other researchers already 
have.

I'm also thinking that braces and semicolons might be satisfying 
to some (most?) programmers as an element of real or perceived 
rigor or safety, independent of the redundancy issue. For 
example, I'm a bit surprised by how popular SASS/SCSS is compared 
to Stylus (CSS preprocessors), given that SASS requires a lot of 
braces and semicolons while Stylus requires neither and has what 
I've been calling "clean" syntax. There could be feature 
differences I don't know about, but I wonder if people feel less 
safe with plain, unadorned text.

I remember that Rob Pike explained why Go requires braces by 
recounting how at Google their tools sometimes lost or damaged 
the indentation in Python source files, breaking those programs. 
I would think that you'd just fix your tools in that case. People 
build such amazing software these days that I'm surprised there'd 
be any issue in nailing down software that handles text files 
without messing up their whitespace or other syntactic structure. 
I don't know, maybe this is a recurring challenge. In any case, 
your redundancy point stands on its own.
May 03 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 4 May 2016 at 05:19:35 UTC, Joe Duarte wrote:

 I remember that Rob Pike explained why Go requires braces by 
 recounting how at Google their tools sometimes lost or damaged 
 the indentation in Python source files, breaking those 
 programs. I would think that you'd just fix your tools in that 
 case.


You're not going to even try to fix it until you realize it's 
broken, and you won't succeed until you figure out which line(s) 
got messed up.

Without any redundancy in the syntax, minor corruption of the 
code could easily result in a program that still "works" - that 
is, compiles and runs without producing an error message - but 
whose behaviour has subtly changed. With redundant syntax, on the 
other hand, the compiler is more likely to detect and pinpoint 
the problem immediately.
May 03 2016
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 04.05.2016 07:27, tsbockman wrote:

 Without any redundancy in the syntax, minor corruption of the code could
 easily result in a program that still "works" - that is, compiles and
 runs without producing an error message - but whose behaviour has subtly
 changed. With redundant syntax, on the other hand, the compiler is more
 likely to detect and pinpoint the problem immediately.


D doesn't have that kind of redundancy either here. For the compiler to 
catch errors, it would have to mind both punctuation and whitespace. But 
whitespace is purely cosmetic in D. Programmers might be alarmed when 
they see a mismatch, but the compiler doesn't care.
May 03 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/3/2016 10:45 PM, ag0aep6g wrote:

 D doesn't have that kind of redundancy either here. For the compiler to
 catch errors, it would have to mind both punctuation and whitespace. But
 whitespace is purely cosmetic in D. Programmers might be alarmed when
 they see a mismatch, but the compiler doesn't care.


The grammar is redundant, not the whitespace.
May 03 2016
prev sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 4 May 2016 at 05:45:39 UTC, ag0aep6g wrote:

 On 04.05.2016 07:27, tsbockman wrote:

 Without any redundancy in the syntax, minor corruption of the 
 code could
 easily result in a program that still "works" - that is, 
 compiles and
 runs without producing an error message - but whose behaviour 
 has subtly
 changed. With redundant syntax, on the other hand, the 
 compiler is more
 likely to detect and pinpoint the problem immediately.


 D doesn't have that kind of redundancy either here.


Yes it does.


 For the compiler to catch errors, it would have to mind both 
 punctuation and whitespace.


No it doesn't.


 But whitespace is purely cosmetic in D. Programmers might be 
 alarmed when they see a mismatch, but the compiler doesn't care.


This is true, but D's grammar still has some redundancy in it, 
even when whitespace is collapsed.

In D, if a single curly brace goes missing, the braces will no 
longer balance and the lexer will complain. In Python, if a 
single tab goes missing, the result may well be a lexically and 
syntactically valid - but buggy - program.
May 04 2016
parent ag0aep6g <anonymous example.com> writes:
On 04.05.2016 20:11, tsbockman wrote:

 In D, if a single curly brace goes missing, the braces will no longer
 balance and the lexer will complain. In Python, if a single tab goes
 missing, the result may well be a lexically and syntactically valid -
 but buggy - program.


That makes a ton of sense, and didn't occur to me at all.
May 04 2016
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 4 May 2016 at 05:27:43 UTC, tsbockman wrote:

 On Wednesday, 4 May 2016 at 05:19:35 UTC, Joe Duarte wrote:

 I remember that Rob Pike explained why Go requires braces by 
 recounting how at Google their tools sometimes lost or damaged 
 the indentation in Python source files, breaking those 
 programs. I would think that you'd just fix your tools in that 
 case.


 You're not going to even try to fix it until you realize it's 
 broken, and you won't succeed until you figure out which 
 line(s) got messed up.

 Without any redundancy in the syntax, minor corruption of the 
 code could easily result in a program that still "works" - that 
 is, compiles and runs without producing an error message - but 
 whose behaviour has subtly changed. With redundant syntax, on 
 the other hand, the compiler is more likely to detect and 
 pinpoint the problem immediately.


I agree. A very common annoyance in Python is the rule that you 
have to use either tabs or spaces. This is a major annoyance when 
you open a Python file in a text editor that inserts tabs or 
spaces automatically. This has happened on countless occasions 
and it's a trivial issue that detracts your attention from 
writing code. In Python you spend a lot of time just formatting 
code instead of writing it. Thus, you're not really more 
efficient in Python. Now, you might say that a good tool should 
fix this, but a) fixing things with a tool takes time as well, b) 
tools might not always be able to tell what your intention was 
[1], and c) if you need a lot of tools to write even simple code, 
there's something wrong with the language's design.

As has been said before, Python is not meant to do what D does. 
Python's rigid syntax rules are purely pedagogical, to avoid that 
non-programmers make a mess of the source code (as would happen 
with Perl). Someone who uses D is usually enough into programming 
(or willing enough to learn it) to be able to deal with curly 
braces and semicolons. Although not obvious from looking at 
Python one or two liners, braces and semicolons are valuable 
features (or tools) whose usefulness only comes apparent once you 
dig deeper and get into more complicated stuff. Python is a 
different beast and for Python it's fine to have no curly braces 
and semicolons. However, the problem is that Python became bigger 
and bigger and left it's cosy realm of scripting in labs, was 
used for bigger projects and actually became quite popular. 
People inferred from this that PLs don't need curly braces and 
semicolons. Yet Rob Pike's decision to use curly braces in Go is 
a good example of the hidden dangers of an overly simplistic 
syntax. It didn't scale.

[1] Consider the following code, which will work correctly:

x = 5

if x < 6:
   print "Checking value"
   print "%d is less than 6" % x

Now look at this:

x = 10

if x < 6:
   print "Checking value"


This will incorrectly print "10 is less than 6". Which gives 
causes two problems

1. no compiler or editing tool can see what your intention was
2. the program works, albeit, incorrectly. In bigger programs, it 
can take a while to find out why the program is behaving 
incorrectly, because up to 5 it always works fine, and if 6-10 is 
less common, it can take a while until you even notice the bug.

In D (or C) it doesn't matter:

if (x < 6)
{
   writeln("Checking value");
writefln("%d is less than 6", x);
}
May 04 2016
parent reply cym13 <cpicard openmailbox.org> writes:
On Wednesday, 4 May 2016 at 09:28:41 UTC, Chris wrote:

 On Wednesday, 4 May 2016 at 05:27:43 UTC, tsbockman wrote:

 On Wednesday, 4 May 2016 at 05:19:35 UTC, Joe Duarte wrote:

 I remember that Rob Pike explained why Go requires braces by 
 recounting how at Google their tools sometimes lost or 
 damaged the indentation in Python source files, breaking 
 those programs. I would think that you'd just fix your tools 
 in that case.






Meh. A programmer's inaptitude to control its text editor 
shouldn't be "fixed" at the language level. Mixing tabs and 
spaces is never a good idea no matter the language for what looks 
"ok" to you will not be so readable for another one using tabs of 
a different length. "Hey, easy, just put a project convention to 
use tabs of, say, 8 chars so that everybody uses the same!" Sure, 
but if you have to fix a length why not just use a fixed length 
character from the start. No, really this is a non-issue.


 You're not going to even try to fix it until you realize it's 
 broken, and you won't succeed until you figure out which 
 line(s) got messed up.

 Without any redundancy in the syntax, minor corruption of the 
 code could easily result in a program that still "works" - 
 that is, compiles and runs without producing an error message 
 - but whose behaviour has subtly changed. With redundant 
 syntax, on the other hand, the compiler is more likely to 
 detect and pinpoint the problem immediately.


 I agree. A very common annoyance in Python is the rule that you 
 have to use either tabs or spaces. This is a major annoyance 
 when you open a Python file in a text editor that inserts tabs 
 or spaces automatically. This has happened on countless 
 occasions and it's a trivial issue that detracts your attention 
 from writing code. In Python you spend a lot of time just 
 formatting code instead of writing it. Thus, you're not really 
 more efficient in Python. Now, you might say that a good tool 
 should fix this, but a) fixing things with a tool takes time as 
 well, b) tools might not always be able to tell what your 
 intention was [1], and c) if you need a lot of tools to write 
 even simple code, there's something wrong with the language's 
 design.

 As has been said before, Python is not meant to do what D does. 
 Python's rigid syntax rules are purely pedagogical, to avoid 
 that non-programmers make a mess of the source code (as would 
 happen with Perl). Someone who uses D is usually enough into 
 programming (or willing enough to learn it) to be able to deal 
 with curly braces and semicolons. Although not obvious from 
 looking at Python one or two liners, braces and semicolons are 
 valuable features (or tools) whose usefulness only comes 
 apparent once you dig deeper and get into more complicated 
 stuff. Python is a different beast and for Python it's fine to 
 have no curly braces and semicolons. However, the problem is 
 that Python became bigger and bigger and left it's cosy realm 
 of scripting in labs, was used for bigger projects and actually 
 became quite popular. People inferred from this that PLs don't 
 need curly braces and semicolons. Yet Rob Pike's decision to 
 use curly braces in Go is a good example of the hidden dangers 
 of an overly simplistic syntax. It didn't scale.

 [1] Consider the following code, which will work correctly:

 x = 5

 if x < 6:
   print "Checking value"
   print "%d is less than 6" % x

 Now look at this:

 x = 10

 if x < 6:
   print "Checking value"


 This will incorrectly print "10 is less than 6". Which gives 
 causes two problems

 1. no compiler or editing tool can see what your intention was
 2. the program works, albeit, incorrectly. In bigger programs, 
 it can take a while to find out why the program is behaving 
 incorrectly, because up to 5 it always works fine, and if 6-10 
 is less common, it can take a while until you even notice the 
 bug.

 In D (or C) it doesn't matter:

 if (x < 6)
 {
   writeln("Checking value");
 writefln("%d is less than 6", x);
 }


There again I completely disagree with you. The intent in the 
first braceless sniplet is clearly to have both statements ruled 
by the condition. Eyes look at indentation before anything else 
as prove bugs like goto-fail. Ignoring that intent by allowing 
code to lie with their indentation level like C or D does is more 
of a mistake IMHO.

if (x < 6)
     writeln("Checking value");
     writeln("%d is less than 6", x);

should be at the very least a warning, at best an error.
May 04 2016
parent Chris <wendlec tcd.ie> writes:
On Wednesday, 4 May 2016 at 11:03:46 UTC, cym13 wrote:

 On Wednesday, 4 May 2016 at 09:28:41 UTC, Chris wrote:

 [1] Consider the following code, which will work correctly:

 x = 5

 if x < 6:
   print "Checking value"
   print "%d is less than 6" % x

 Now look at this:

 x = 10

 if x < 6:
   print "Checking value"


 This will incorrectly print "10 is less than 6". Which gives 
 causes two problems

 1. no compiler or editing tool can see what your intention was
 2. the program works, albeit, incorrectly. In bigger programs, 
 it can take a while to find out why the program is behaving 
 incorrectly, because up to 5 it always works fine, and if 6-10 
 is less common, it can take a while until you even notice the 
 bug.

 In D (or C) it doesn't matter:

 if (x < 6)
 {
   writeln("Checking value");
 writefln("%d is less than 6", x);
 }


 There again I completely disagree with you. The intent in the 
 first braceless sniplet is clearly to have both statements 
 ruled by the condition. Eyes look at indentation before 
 anything else as prove bugs like goto-fail. Ignoring that 
 intent by allowing code to lie with their indentation level 
 like C or D does is more of a mistake IMHO.

 if (x < 6)
     writeln("Checking value");
     writeln("%d is less than 6", x);

 should be at the very least a warning, at best an error.


The intention is clear in _this_ simple example, but only to a 
human reader, not to a tool. My point was that it's easy to have 
an indentation level mistake like this somewhere in your code 
(and please don't tell me it never ever happens to you), and if 
this happens in a huge program somewhere in a file that contains 
a few hundred lines, it's not easy to track it down (or even to 
notice for quite a while).

Although your example compiles in D (it should give at least a 
warning, I agree), this sort of code is not common in D. Anything 
with more than one line is usually put into curly braces, the 
point being that D does neither demand nor encourage the use of 
indentation level to indicate where a block of code starts and 
ends. If a language (like Python) does demand it, it invites you 
to make subtle mistakes. In other words, in D errors like the one 
described in my previous post do not occur (or at least very 
rarely). In Python they are a common source of bugs. And again, I 
strongly believe that formatting code should not be a language 
feature.
May 04 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Would it be difficult to compile the clean version?


You realize your bias is showing very strongly in the wording of 
this question, right? I don't agree the naked version is clean at 
all.

ohimsorryletswritemorecleanlywithoutanyofthatobnoxiouspunctuationnoiseitisalluselessanywaysurelyyoucanstillmakesenseofthisafterallthereareonlysomanywordsintheenglishlanguageandknowinghwatdoesanddoesntmakesenseincontextmeansyoucansurelyparsethisrightout

oh i know you will say thats not a fair comparison it is the 
punctuation you dislike not the spacing though really the same 
principle applies actually while the punctuation does have 
meaning ill concede you can nevertheless parse it without 
although you might then want other rules

see in a lot of those languages they redefine things like lines 
to serve the same role as the punctuation

so like instead of ending expressions in punctuation

they end them with a new line instead

meaning you must hit enter at the point that d would allow you to 
use the semicolon

ditto for indentation

like sure this is readable

but it just bothers me to use as a matter of course

it can even become

~hideous~

crap i cant even use ~ wtf this style of writing sucks it just 
isnt very expressive nor artistic

* * *

Personally, I sometimes do like writing in all lower case without 
punctuation, but I do so as a style choice; it tends to be my way 
of expressing in text that I'm not being entirely serious, in 
contrast to ordinarily formatted text.

Code is the same thing - I will use different styles for 
different situations.

It isn't a terribly difficult technical problem to define a 
programming language to have a different syntax. You can parse 
them without that much trouble.

But the syntax isn't really there for the compiler's benefit 
(though there are benefits there, just like asking the user to 
confirm their email address, getting a bit of redundant 
information out of the human user can help catch mistakes), it is 
there for the reader.

I often get lost when there's several levels of whitespace change 
at once.

def pain:
   if whatever:
     do this
     if this_too:
       also do this
       if one_more:
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
         oh snap this is kinda long
         it takes several lines
     quick where we at?



Curly braces in there would show we intended to go a couple 
levels and give a convenient place to click to ask our editor 
program to show us where it started too. I really like having 
that.


Semicolons similarly are a nice way to say "I'm done with this 
thought", which I'm just used to hitting. When I use languages 
that don't allow them, I waste quite a bit of time hitting 
backspace after automatically hitting ;!

Moreover, with a longer line, (or in some cases like debug lines 
where I want to easily remove two statements with one keypress - 
yes, my editor can delete a line instantly, but two lines are a 
bit harder to do) the semicolon gives you the freedom to format 
it as you will.


a = 5 +
     4 -
     1;

That'd work without the semicolon (usually), but this is 
different:

a =   5
     + 4
     - 1;


In that case, the line break after the 5 would probably end the 
statement, leaving the other numbers dangling.

I prefer this formatting in many cases though since then the 
operators nicely line up. In the first one, the 4 is visually 
tied to the -, but really, the - is more strongly related to the 
1, so I want them grouped together.


Well, I'm late, but to sum up:

* familiarity brings comfort, to look and in using existing 
workflows like my editor's delete-line feature.

* breaking habits, regardless of whether those habits are perfect 
in a perfect world, is a source of mental friction that has 
higher cost than benefit

* punctuation separate from styling leaves both as independent 
decisions that brings more beauty

It isn't so much that they are necessary, it is that they bring 
various other benefits.



 I'm a social scientist and I'm preparing some studies on
 the effects of programming language syntax on learning,
 motivation to pursue programming, as well as any 
 disproportionate effects that PL syntax has on the appeal
 of programming to women (more on the latter in a separate
 post).


fascinating, I might tell you some stories from my youth later, 
but right now, I'm too old to be up this late!

But I'm really curious what the gendered aspect turns out as. I 
suspect the effect, if it indeed exists, would be strongly tied 
to the oft-repeated lie that "girls aren't good at math" - math 
famously uses a lot of symbols, so that association could recall 
discouraging memories.
May 02 2016
next sibling parent Bauss <streetzproductionz hotmail.com> writes:
On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:

 On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 [...]


 You realize your bias is showing very strongly in the wording 
 of this question, right? I don't agree the naked version is 
 clean at all.

 [...]



Praise this
May 02 2016
prev sibling next sibling parent Ivan Kazmenko <gassa mail.ru> writes:
On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:

 But I'm really curious what the gendered aspect turns out as. I 
 suspect the effect, if it indeed exists, would be strongly tied 
 to the oft-repeated lie that "girls aren't good at math" - math 
 famously uses a lot of symbols, so that association could 
 recall discouraging memories.


"Obligatory" xkcd link: https://xkcd.com/385/
May 03 2016
prev sibling next sibling parent CRAIG DILLABAUGH <craig.dillabaugh gmail.com> writes:
On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:

 On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Would it be difficult to compile the clean version?


 You realize your bias is showing very strongly in the wording 
 of this question, right? I don't agree the naked version is 
 clean at all.

 ohimsorryletswritemorecleanlywithoutanyofthatobnoxiouspunctuationnoiseitisalluselessanywaysurelyyoucanstillmakesenseofthisafterallthereareonlysomanywordsintheenglishlanguageandknowinghwatdoesanddoesntmakesenseincontextmeansyoucansurelyparsethisrightout


Hey, you spelled 'what' wrong :o)
May 03 2016
prev sibling parent Joe Duarte <jose.duarte asu.edu> writes:
On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:

 On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Would it be difficult to compile the clean version?


 You realize your bias is showing very strongly in the wording 
 of this question, right? I don't agree the naked version is 
 clean at all.


Fair point. I probably am biased, though I don't think an 
objective definition of clean as having less text or punctuation 
would be too controversial. Maybe compact vs verbose would be 
more objective, though those terms are usually used to refer to 
differences in amount of text/keywords, repetition, etc. (e.g 
Python vs Java)
May 03 2016
prev sibling next sibling parent reply qznc <qznc web.de> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Hi all,

 I'm a social scientist and I'm preparing some studies on the 
 effects of programming language syntax on learning, motivation 
 to pursue programming, as well as any disproportionate effects 
 that PL syntax has on the appeal of programming to women (more 
 on the latter in a separate post).

 So I want to get a better idea of the rationale for various 
 syntactical design decisions, and I'm going to ask you the same 
 question I'll ask the Rust community:

 Why are curly braces and semicolons necessary? What information 
 do they carry that a compiler could not otherwise reliably 
 obtain?

 Would it be difficult to compile the clean version? Would there 
 be issues with the design of the lexer/parser? I assume the 
 compiler would recognize keywords like return (and a clean 
 syntax could drive different rules for what statements and 
 expressions could appear on the same line and so forth).

 In reality, a compiler would see the above with line ending 
 characters terminating every line (e.g. U+000A), so it would be 
 as line-aware as a human. I've never built lexers or parsers, 
 much less compilers, so maybe I'm missing a major 
 implementation hurdle. I'm just thinking that Facebook has 
 built software that recognizes my face in other people's 
 pictures, so it seems like building software that understands 
 structured text would be a solved problem. It puzzles me to see 
 so much apparent punctuation noise in a 21st-century language 
 (and, to be fair, Rust puzzles me for the same reasons).


The parser needs information about "blocks". Here is an example:

   if (x)
     foo();
     bar();

Is bar() always executed or only if (x) is true? In other words, 
is bar() part of the block, which is only entered conditionally?

There are three methods to communicate blocks to the compiler: 
curly braces, significant whitespace (Python, Haskell), or an 
"end" keyword (Ruby, Pascal). Which one you prefer is subjective.

You mention Facebook and face recognition. I have not seen anyone 
try machine learning for parsing. It would probably be a fun 
project, but not a practical one.

You wonder that understanding structured text should be a solved 
problem. It is. You need to use a formal language, which 
programming languages are. English for example is much less 
structured. There easily are ambiguities. For example:

   I saw a man on a hill with a telescope.

Who has the telescope? You or the man you saw? Who is on the hill?

As a programmer, I do not want to write ambiguous programs. We 
produce more than enough bugs without ambiguity.
May 03 2016
next sibling parent Observer <here nowhere.com> writes:
On Tuesday, 3 May 2016 at 12:47:42 UTC, qznc wrote:

 There are three methods to communicate blocks to the compiler: 
 curly braces, significant whitespace (Python, Haskell), or an 
 "end" keyword (Ruby, Pascal). Which one you prefer is 
 subjective.


Four methods.  Let's not forget statement labels and "goto",
which were effectively all that early Fortran had available for
marking block boundaries.
May 03 2016
prev sibling parent reply Joe Duarte <jose.duarte asu.edu> writes:
On Tuesday, 3 May 2016 at 12:47:42 UTC, qznc wrote:


 The parser needs information about "blocks". Here is an example:

   if (x)
     foo();
     bar();

 Is bar() always executed or only if (x) is true? In other 
 words, is bar() part of the block, which is only entered 
 conditionally?

 There are three methods to communicate blocks to the compiler: 
 curly braces, significant whitespace (Python, Haskell), or an 
 "end" keyword (Ruby, Pascal). Which one you prefer is 
 subjective.

 You mention Facebook and face recognition. I have not seen 
 anyone try machine learning for parsing. It would probably be a 
 fun project, but not a practical one.

 You wonder that understanding structured text should be a 
 solved problem. It is. You need to use a formal language, which 
 programming languages are. English for example is much less 
 structured. There easily are ambiguities. For example:

   I saw a man on a hill with a telescope.

 Who has the telescope? You or the man you saw? Who is on the 
 hill?

 As a programmer, I do not want to write ambiguous programs. We 
 produce more than enough bugs without ambiguity.


Thanks for the example! So you laid out the three options for 
signifying blocks. Then you said which one you prefer is 
subjective, but that you don't want to write ambiguous programs. 
Do you think that the curly braces and semicolons help with that?

So in your example, I figure bar's status is language-defined, 
and programmers will be trained in the language in the same way 
they are now. I've been sketching out a new language, and there 
are a couple of ways I could see implementing this.

First, blocks of code are separated by one or more blank lines. 
No blank lines are allowed in a block. An if block would have to 
terminate in an else statement, so I think this example just 
wouldn't compile. Now if we wanted two things to happen on an if 
hit, we could leave it the way you gave where the two things are 
at the same level of indentation. That's probably what I'd settle 
on, contingent on a lot of research, including my own studies and 
other researchers', though this probably isn't one of the big 
issues. If we wanted to make the second thing conditional on 
success on the first task, then I would require another indent. 
Either way the block wouldn't compile without an else.

I've been going through a lot of Unicode, icon fonts, and the 
Noun Project, looking for clean and concise representations for 
program logic. One of the ideas I've been working with is to 
leverage Unicode arrows. In most cases it's trivial aesthetic 
clean-up, like → instead of ->, and a lot of it could be simple 
autoreplace/autocomplete in tools. For if logic, you can an 
example of bent arrows, and how I'd express the alternatives for 
your example here: 
http://i1376.photobucket.com/albums/ah13/DuartePhotos/if%20block%20with%20Unicode%20arrows_zpsnuigkkxz.png
May 13 2016
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Saturday, 14 May 2016 at 03:19:51 UTC, Joe Duarte wrote:


 I've been going through a lot of Unicode, icon fonts, and the 
 Noun Project, looking for clean and concise representations for 
 program logic. One of the ideas I've been working with is to 
 leverage Unicode arrows. In most cases it's trivial aesthetic 
 clean-up, like → instead of ->, and a lot of it could be simple 
 autoreplace/autocomplete in tools. For if logic, you can an 
 example of bent arrows, and how I'd express the alternatives 
 for your example here: 
 http://i1376.photobucket.com/albums/ah13/DuartePhotos/if%20block%20with%20Unicode%20arrows_zpsnuigkkxz.png


there's a keyboard for those types of programs ;-)

http://www.dyalog.com/uploads/images/Business/products/us_rc.jpg

(APL keyboard)
May 14 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 14 May 2016 at 12:49:19 UTC, Abdulhaq wrote:

 there's a keyboard for those types of programs ;-)

 http://www.dyalog.com/uploads/images/Business/products/us_rc.jpg


One of the things I do with my custom terminal emulator and text 
scripts is make those common unicode characters easier to type 
but I actually often forget where they are... generally, I prefer 
typing out "theta" or "->" to θ or → (aside from some of my fonts 
not even supporting such characters!) is just that they are 
really easy on the keyboard and I know what the word means anyway.
May 14 2016
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Why are curly braces and semicolons necessary? What information 
 do they carry that a compiler could not otherwise reliably 
 obtain?


Something that hasn't been mentioned so far:

Generating source code is easier with braces. String mixins would 
be more complicated with significant indentation.
May 03 2016
parent matovitch <camille.brugel laposte.net> writes:
Another thing is that some people (like me) likes to shape the 
code as they wish, some classic examples being :

f(arg1,
   arg2,
   arg3);

return predicate() ? a
                    : b;
May 03 2016
prev sibling next sibling parent HaraldZealot <harald_zealot tut.by> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Hi all,

 I'm a social scientist and I'm preparing some studies on the 
 effects of programming language syntax on learning, motivation 
 to pursue programming, as well as any disproportionate effects 
 that PL syntax has on the appeal of programming to women (more 
 on the latter in a separate post).

 [...]


And D-specific syntax for range-based algorithms often also 
clearer in multi-line form:

```d
stdin
         .byLineCopy
         .array
         .sort!((a, b) => a > b) // descending order
         .each!writeln;
```

(current snapshot from main page ;) )
May 03 2016
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Hi all,

 I'm a social scientist and I'm preparing some studies on the 
 effects of programming language syntax on learning, motivation 
 to pursue programming, as well as any disproportionate effects 
 that PL syntax has on the appeal of programming to women (more 
 on the latter in a separate post).


Yes, please elaborate on this. I have to say I don't like the 
sound of this paragraph. Why would women be repelled by curly 
braces and semicolons? I know from my own experience that Python 
doesn't do the trick either. If a woman doesn't want to program, 
she just doesn't want to, even if it's in Python. It's the term 
"programming" that makes them (i.e. those who are not interested) 
run away. "Write a script" sounds nicer, but even then ... if 
they don't have to they won't even touch it with thongs.

Men who are not really interested in techie stuff also run away 
when they hear the word "programming". The syntax is not really 
the issue. It's programming itself.


 Would it be difficult to compile the clean version? Would there 
 be issues with the design of the lexer/parser? I assume the 
 compiler would recognize keywords like return (and a clean 
 syntax could drive different rules for what statements and 
 expressions could appear on the same line and so forth).


[snip]

D has quite a clean syntax, imo. It looks "agreeable" on the 
page. Python, although it prescribes line breaks and indentation, 
can be very hard to read, even short scripts can get messy when 
you lose track of the indentation level. Mind you, Python's 
prescriptive formatting was designed to force non-programmers 
(e.g. scientists and researchers who want to write scripts) to 
write clean code. It is a pedagogical thing more than anything 
else. I believe that formatting (i.e. how it looks on the page) 
should not be part of the language itself. Any programmer in his 
or _her_ right mind will come up with some sort of structured 
formatting of their source code anyway. But it should not be a 
language feature.

I've often been annoyed by Python's error messages regarding the 
wrong indentation level, only because I cut/copied and pasted a 
block of code. With braces that cannot happen. The thing is that 
in Python you have to do all the correct formatting for trivial 
bits of code you just need for testing/debugging. Now, if you 
find out that you don't want/need the bit of code anymore (say 
after a few minutes), you've wasted your time formatting it. Very 
annoying.

Walter's point about redundancy are interesting. Much like in 
natural languages, the more redundancy, the less ambiguity.

I think in a few years, vintage C-style will be _the_ big thing 
again.
May 03 2016
next sibling parent reply Observer <here nowhere.com> writes:
On Tuesday, 3 May 2016 at 18:37:54 UTC, Chris wrote:

 On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Hi all,

 I'm a social scientist and I'm preparing some studies on the 
 effects of programming language syntax on learning, motivation 
 to pursue programming, as well as any disproportionate effects 
 that PL syntax has on the appeal of programming to women (more 
 on the latter in a separate post).


 Yes, please elaborate on this. I have to say I don't like the 
 sound of this paragraph. Why would women be repelled by curly 
 braces and semicolons? I know from my own experience that 
 Python doesn't do the trick either. If a woman doesn't want to 
 program, she just doesn't want to, even if it's in Python. It's 
 the term "programming" that makes them (i.e. those who are not 
 interested) run away. "Write a script" sounds nicer, but even 
 then ... if they don't have to they won't even touch it with 
 thongs.


I have to say, not to be too negative, but this researcher's 
proposed
investigations sound to me like the efforts of an anthropologist
trying to reconstruct a whole culture from ancient Sumerian 
pottery
shards.  What they'll come up with is nothing like living inside
the culture to begin with.  There's a rich history of technical
papers on language critiques; if you really want to understand how
and why languages evolved to their present forms, and why present
constructions were seen to be significant advances over their
predecessors, that's the place to start.  Without such an effort,
the words "apophenia" and "pareidolia" come to mind.  m-w.com has
some really nice, concise definitions for you.  Wikipedia has more
extensive discussions.
May 03 2016
parent Observer <here nowhere.com> writes:
On Tuesday, 3 May 2016 at 20:54:05 UTC, Observer wrote:

 I have to say, not to be too negative, ...


Let me turn that around and suggest something in a positive light.
If the researcher wants to investigate social phenomena around
programming and gender, then I suspect that a more fruitful
approach would be to find out what types of problems are being
taught, and whether or not those issues are terribly interesting
(or not) to specific genders.  For instance, if I were female,
I suspect I might be interested in how variations of knit1-purl2
patterns turn into fantastic patterns on knitted sweaters.  And on
whether I might be able to program a knitting machine to carry
out a complex design.  I might also be interested in programming
sewing patterns for various garments of my own design, and on
learning how to scale the patterns for various sizes, particularly
if the class had access to a large-format plotter for output.
Even better would be if students could send off designs to get
them laser-cut, so they could then sew them up and make some fun
clothes or costumes to wear.  But do present instructors think to
come up with such approaches?

The point is, be more expansive about what attracts people or
discourages people from particular disciplines.  You could, in
effect, be mirroring the plaint of one of my high-school's biology
teachers.  He wanted to know why most of the best-and-brightest
students gravitated more toward physics than biology.  Myself,
it was because I didn't care to work around smelly pathogens.
But everyone will have their own reasons for making such choices.
May 03 2016
prev sibling parent reply poliklosio <poliklosio happypizza.com> writes:
On Tuesday, 3 May 2016 at 18:37:54 UTC, Chris wrote:

 If a woman doesn't want to program, she just doesn't want to, 
 even if it's in Python. It's the term "programming" that makes 
 them (i.e. those who are not interested) run away. "Write a 
 script" sounds nicer, but even then ... if they don't have to 
 they won't even touch it with thongs.


I'm bewildered by the use of the word "thongs" here. I'm just 
really surprised to see it here. Is it some kind of a spelling 
mistake? I'm starting to thing that my imperfect non-native 
English is the issue.
May 03 2016
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 3 May 2016 at 21:03:36 UTC, poliklosio wrote:

 Is it some kind of a spelling mistake?


tongs.
May 03 2016
prev sibling next sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Hi all,

 I'm a social scientist and I'm preparing some studies on the 
 effects of programming language syntax on learning, motivation 
 to pursue programming, as well as any disproportionate effects 
 that PL syntax has on the appeal of programming to women (more 
 on the latter in a separate post).


Ok, a lot has been said against the braceless version, I think 
it's time to defend it for a bit. For my background my 4 first 
languages had very different syntaxes, none of which comprised 
curly braces or commas so while I enjoy D and C very much I grew 
up without ever thinking of them as representative of "real 
programming".

In my opinion putting commas at the end of a line is useless: if 
it happens at the end of each line (not counting closing-braces 
ones) then the effective quantity of information brought is null, 
and in more than one case chaining instructions on the same line 
(the only utility of commas) ends up being a bad idea. But it's 
part of those things that have such an inertia that you just 
wouldn't ever had heard of D if it hadn't had it I think. Having 
commas was not decided by their intrinsic usefulness but by the 
choice to target the C/C++ market.

Curly braces are another thing... I hear valid point (cc Adam) 
saying that it can be hard to deal with huge functions when using 
only indentation. However one must remember that Python and 
Haskell aren't D or C. Those languages are meant to be more 
functionnal and all tools are given so that you can use concise 
code made of small functions instead of pushing you toward big 
structural oddities. An example of that is the difference in the 
definition of iterators: Python's generator syntax may have its 
flaws but it makes for short and easy to write code. D's ranges 
are in some ways more powerful but having to define a whole 
struct/class to do it makes it way more verbose. It could be done 
that way in Python too but it would never ever be the default 
because that's just not what the language is thought for.

That has direct consequences on our problem. The fact that 
Python's function become harder to work with when they become 
bigger is a tool, and a useful one. When your Python code becomes 
hard to work with it raises a flag : “Stop where you are there 
should be a better, simpler way to do it.” Python's only goal is 
to produce readable code so it has a lot of tools to help you 
reduce its size. Keyword arguments are a good example. There are 
a lot of functions in phobos that share a common prefix just 
because it was too hard to make them share the same name in a 
generic way where they would just be separated by a keyword 
argument in Python.

But Python sacrifices a *lot* of performances to do that. D has 
its own way and different goals. Being performance-friendly is 
one of them and that sometimes gets you with long functions and 
ugly hacks. When it comes to that having curly braces (well any 
kind of delitmiter really) is a great thing.

tl;dr: syntactic oddities are tools and you can't judge different 
tools without understanding the context in which they are used 
and what problem they are meant to solve. D isn't really meant 
for the kind of code that benefits most of having no curly braces.
May 03 2016
next sibling parent qznc <qznc web.de> writes:
On Tuesday, 3 May 2016 at 22:17:18 UTC, cym13 wrote:

 That has direct consequences on our problem. The fact that 
 Python's function become harder to work with when they become 
 bigger is a tool, and a useful one. When your Python code 
 becomes hard to work with it raises a flag : “Stop where you 
 are there should be a better, simpler way to do it.” Python's 
 only goal is to produce readable code so it has a lot of tools 
 to help you reduce its size. Keyword arguments are a good 
 example. There are a lot of functions in phobos that share a 
 common prefix just because it was too hard to make them share 
 the same name in a generic way where they would just be 
 separated by a keyword argument in Python.

 But Python sacrifices a *lot* of performances to do that. D has 
 its own way and different goals. Being performance-friendly is 
 one of them and that sometimes gets you with long functions and 
 ugly hacks. When it comes to that having curly braces (well any 
 kind of delitmiter really) is a great thing.

 tl;dr: syntactic oddities are tools and you can't judge 
 different tools without understanding the context in which they 
 are used and what problem they are meant to solve. D isn't 
 really meant for the kind of code that benefits most of having 
 no curly braces.


I don't understand your reasoning how curly braces makes D faster 
than Python.

There is no causation between syntax and performance.
Design two programming languages which only differ about curly 
braces and semi colons. Once they are parsed into an AST all 
differences are gone. The compiler will output the same code, so 
performance must be the same.

Is Python more readable than D? I believe this is subjective. 
Overall, I believe there is no significant objective difference 
between different syntax. It makes a difference once you are used 
to some style and many people these days are used to curly braces 
and semicolons.
May 04 2016
prev sibling parent reply Joe Duarte <jose.duarte asu.edu> writes:
On Tuesday, 3 May 2016 at 22:17:18 UTC, cym13 wrote:


 In my opinion putting commas at the end of a line is useless: 
 if it happens at the end of each line (not counting 
 closing-braces ones) then the effective quantity of information 
 brought is null, and in more than one case chaining 
 instructions on the same line (the only utility of commas) ends 
 up being a bad idea. But it's part of those things that have 
 such an inertia that you just wouldn't ever had heard of D if 
 it hadn't had it I think. Having commas was not decided by 
 their intrinsic usefulness but by the choice to target the 
 C/C++ market.


Good point that line-ending semicolons carry no information if 
they're on every line (I assume you meant semicolons instead of 
commas).

An important point that I think is undocumented: text editors 
don't let you inhabit a new line unless you press Enter on the 
line above. In other words, you can't have a new line by using 
the down arrow or some other means. When I first learned 
programming, I was stumped by how a compiler was line-aware, how 
it knew when a line was truly ended, and what counted as line qua 
line (I wrongly assumed you could down-arrow to a new line). It's 
an invisible character by default, and they don't tell you how 
text editors behave. This comes up a bit in Markdown and in how 
people are inconsistently defining a "hard" vs "soft" line break.



 But Python sacrifices a *lot* of performances to do that. D has 
 its own way and different goals. Being performance-friendly is 
 one of them and that sometimes gets you with long functions and 
 ugly hacks. When it comes to that having curly braces (well any 
 kind of delitmiter really) is a great thing.


It's not clear how curly braces deliver better performance. 
Anything expressed with curly braces can be expressed without 
them -- i.e. you could design a language in which that were true. 
Walter mentioned the issue of redundancy, which seems reasonable, 
but that doesn't bear on the performance issue. A good example of 
a non-curly brace compiled language is Crystal, at least last 
time I checked. Python loses a lot for being a text-executing 
interpreted language. What an interpreter does -- in comparison 
to a JIT compiler -- is wildly underdocumented. The standard 
answer to a lot of people on the web asking for an explanation is 
that a JIT compiles down to native code or machine code, while an 
interpret just interprets the code, or sometimes you'll see 
"executes it directly". Big gaping hole on how it gets down to 
machine code. But starting with text is crippling. I love 
Walter's decision to have pre-compiled modules instead of text 
headers -- I didn't realize that C compilers were literally 
parsing all this text every time.

Python could get some big wins from a well-designed IR and 
follow-on back-end code generator, or a JIT, or some combo. This 
is obviously not a new idea, but no one seems willing to do it in 
a professional, focused, and expensive way. Unladen Swallow was 
weird in that you had a couple of kids, undergrad students who 
had no experience trying to build it all. It's weird how casual 
and half-assed a lot of software projects are. If I were trying 
to do this, I'd want to assemble the Avengers -- I'd want a large 
team of elite software developers, architects, and testers, 
enough to do it in a year. That's a rare setup, but it's how I 
would do it if I were Microsoft, Google, FB, et al -- if I were 
willing to spend $20 million on it, say. Pyjion might become 
something interesting, but right now it looks pretty casual and 
might be the kind of thing where they'll a lot of outside 
open-source developer help (https://github.com/Microsoft/Pyjion). 
Pyston is only focused on Python 2, which is rearview mirror 
thing.

By the way, anyone should be able to create a version of C, D, or 
Go that doesn't use curly braces or semicolons, just by enforcing 
some rules about indentation and maybe line length that are 
already adhered to by virtue of common coding standards (e.g. 
blocks are typically indented; and I realize Go doesn't require 
semicolons). If we looked at typical code examples in almost any 

encoded their meaning, reducing them down to a concise and 
non-redundant form, we'd find lots of redundancy and a lot of 
textual dead code, so to speak. This would be true even without 
semicolons and braces. There's still a lot for a compiler or any 
interpretive agent to go on.
May 14 2016
parent ag0aep6g <anonymous example.com> writes:
On 05/15/2016 01:01 AM, Joe Duarte wrote:

 Good point that line-ending semicolons carry no information if they're
 on every line (I assume you meant semicolons instead of commas).


[...]

 By the way, anyone should be able to create a version of C, D, or Go
 that doesn't use curly braces or semicolons, just by enforcing some
 rules about indentation and maybe line length that are already adhered
 to by virtue of common coding standards (e.g. blocks are typically
 indented; and I realize Go doesn't require semicolons). If we looked at

 and we systematically encoded their meaning, reducing them down to a
 concise and non-redundant form, we'd find lots of redundancy and a lot
 of textual dead code, so to speak. This would be true even without
 semicolons and braces. There's still a lot for a compiler or any
 interpretive agent to go on.


On semicolons:

There is a promoted style in D that does not use semicolons on every 
line. This example is on the dlang.org home page:

----
// Sort lines
import std.stdio, std.array, std.algorithm;

void main()
{
     stdin
         .byLineCopy
         .array
         .sort!((a, b) => a > b) // descending order
         .each!writeln;
}
----

A leading dot is valid, too. (It means module scope rather than local 
scope.) So without semicolons, there would ambiguities:

----
foo()
.writeln()
----

`foo(); .writeln();` or `foo().writeln();`?
May 14 2016
prev sibling next sibling parent Poyeyo <poyeyo arcadechaser.com> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Hi all,

 I'm a social scientist and I'm preparing some studies on the 
 effects of programming language syntax on learning, motivation 
 to pursue programming, as well as any disproportionate effects 
 that PL syntax has on the appeal of programming to women (more 
 on the latter in a separate post).

 So I want to get a better idea of the rationale for various 
 syntactical design decisions, and I'm going to ask you the same 
 question I'll ask the Rust community:

 Why are curly braces and semicolons necessary? What information 
 do they carry that a compiler could not otherwise reliably 
 obtain?

 Here's an example from the D Overview page:


 class Foo
 {
     int foo(Bar c) { return c.bar; }
 }

 class Bar
 {
     int bar() { return 3; }
 }


 Okay, if we remove the curly braces and semicolons, we have:


 class Foo

     int foo(Bar c) return c.bar


 class Bar

     int bar() return 3


 Would it be difficult to compile the clean version? Would there 
 be issues with the design of the lexer/parser? I assume the 
 compiler would recognize keywords like return (and a clean 
 syntax could drive different rules for what statements and 
 expressions could appear on the same line and so forth).

 In reality, a compiler would see the above with line ending 
 characters terminating every line (e.g. U+000A), so it would be 
 as line-aware as a human. I've never built lexers or parsers, 
 much less compilers, so maybe I'm missing a major 
 implementation hurdle. I'm just thinking that Facebook has 
 built software that recognizes my face in other people's 
 pictures, so it seems like building software that understands 
 structured text would be a solved problem. It puzzles me to see 
 so much apparent punctuation noise in a 21st-century language 
 (and, to be fair, Rust puzzles me for the same reasons).

 JD


Compilers, with or without curly braces and semicolons, will 
handle their intended syntax for their corresponding language 
just fine, in a matter of milliseconds. Also, compilers are a 
mature science now and they are well understood in general.

The important thing to consider is the human programmer. We don't 
read code in milliseconds, we take dozens of seconds, even 
minutes, to read and understand a page of code.

Therefore, any help the language syntax can provide in order to 
help us read and understand code faster, is extremely welcome.

Many times, that help comes from our text editor. We use text 
editors with many different colours for many different parts of 
code.

Now, the curly braces and semicolons are coloured too. And these 
coloured symbols help us read and understand code faster than 
simple indentation. In fact, I avoid to read code without colours.

They can be a burden to type, which is a reason some developers 
dislike them, but code is written fewer times than it is read.

Anyway, this is my opinion. They are used because they help us to 
read and understand code faster. Compilers don't need them, we do.
May 03 2016
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/2/2016 8:48 PM, Joe Duarte wrote:

 I'm a social scientist and I'm preparing some studies on the effects of
 programming language syntax on learning, motivation to pursue
 programming, as well as any disproportionate effects that PL syntax has
 on the appeal of programming to women (more on the latter in a separate
 post).


therearealsoaestheticswedonotactuallyneedspacesorpunctuationorcasetoreadenglish
butitsuremakesiteasier
May 03 2016
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/2/2016 8:48 PM, Joe Duarte wrote:

 I'm a social scientist and I'm preparing some studies on the effects of
 programming language syntax on learning, motivation to pursue
 programming, as well as any disproportionate effects that PL syntax has
 on the appeal of programming to women (more on the latter in a separate
 post).


One of the things that comes with Haskell has nothing to do with 
functional programming. It's the minimalist syntax. However, I find that 
they've gone too far with this, and it's difficult for me to read. 
Haskell people, however, consider this 'clean'.
May 03 2016
parent Max Samukha <maxsamukha gmail.com> writes:
On Wednesday, 4 May 2016 at 04:39:46 UTC, Walter Bright wrote:

 One of the things that comes with Haskell has nothing to do 
 with functional programming. It's the minimalist syntax. 
 However, I find that they've gone too far with this, and it's 
 difficult for me to read. Haskell people, however, consider 
 this 'clean'.


It is actually no harder to read after some practice than a 
language with C-like syntax. In general, the more languages you 
practice, the less important (and more annoying) syntax 
redundancies become.
May 05 2016
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 Hi all,

 I'm a social scientist and I'm preparing some studies on the 
 effects of programming language syntax on learning, motivation 
 to pursue programming, as well as any disproportionate effects 
 that PL syntax has on the appeal of programming to women (more 
 on the latter in a separate post).


It should be obvious that curly braces are a symbol of 
femininity, and it is why it is often unfairly neglected by 
community of programmers that perpetuate societal schema of 
patriarchal oppression.
May 04 2016
parent reply Tobias Pankrath <tobias pankrath.net> writes:
On Wednesday, 4 May 2016 at 08:48:58 UTC, deadalnix wrote:


 It should be obvious that curly braces are a symbol of 
 femininity, and it is why it is often unfairly neglected by 
 community of programmers that perpetuate societal schema of 
 patriarchal oppression.


Attributing a redundant element of the grammar to femininity just
demonstrates your inherent sexism and the sexism ingrained into
you due to your upbringing in the patriarch. Please check your
privileges and refrain from playing the "ally" while 
simultaneously
occupying space and attention that rightfully should belong to
true feminists.
May 04 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 4 May 2016 at 09:04:34 UTC, Tobias Pankrath wrote:

 On Wednesday, 4 May 2016 at 08:48:58 UTC, deadalnix wrote:


 It should be obvious that curly braces are a symbol of 
 femininity, and it is why it is often unfairly neglected by 
 community of programmers that perpetuate societal schema of 
 patriarchal oppression.


 Attributing a redundant element of the grammar to femininity 
 just
 demonstrates your inherent sexism and the sexism ingrained into
 you due to your upbringing in the patriarch. Please check your
 privileges and refrain from playing the "ally" while 
 simultaneously
 occupying space and attention that rightfully should belong to
 true feminists.


Are you seriously saying that element of femininity in the 
grammar are redundant ? I'm so triggered right now ! Stop 
mainsplaining, shitlord !

We need to acknowledge that there are system of oppression that 
keep women and people of color out of programming, and that your 
hetero-patriarchal remarks are the kind of micro aggression that 
discourage their participation in STEM fields. I mean come on, 
it's 2016 !

WE HAVE NOTHING TO LOSE BUT OUR CHAINS !
May 04 2016
next sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 4 May 2016 at 14:23:20 UTC, deadalnix wrote:

 Are you seriously saying that element of femininity in the 
 grammar are redundant ? I'm so triggered right now ! Stop 
 mainsplaining, shitlord !

 We need to acknowledge that there are system of oppression that 
 keep women and people of color out of programming, and that 
 your hetero-patriarchal remarks are the kind of micro 
 aggression that discourage their participation in STEM fields. 
 I mean come on, it's 2016 !

 WE HAVE NOTHING TO LOSE BUT OUR CHAINS !


I find the whole research question weird. Does it suggest that 
women are too stupid to read code that has curly braces and 
semicolons, or that it hurts the female sense of  aesthetics 
(what ever that might be), or are curly braces a symbol of a 
patriarchal society and are only used by a male dominated 
programming community to show women where their place is? Are 
they secret sexual (and sexist) symbols "{}" and ";".

It seems to me that it's actually the research question that is 
sexist.
May 04 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 05/04/2016 10:23 AM, deadalnix wrote:

 We need to acknowledge that there are system of oppression that keep
 women and people of color out of programming,


Hard to tell for certain, but you ARE being sarcastic/joking about this, 
right?

It's touchy, because I've come across people who actually do genuinely 
believe the field has things in place deliberately to exclude 
women/ethnicities...even though...those VERY SAME people have never once 
been able to provide a SINGLE CONCRETE EXAMPLE of any of these alleged 
mechanisms they believe so strongly to exist. Not only that, but I've 
yet to come across an anti-minority or anti-female programmer, and even 
if such creatures exist, they're undeniably var too much in the minority 
to have any real large-scale effect on "keeping people out". The vast 
majority that I've seen are far more likely to *dislike* the field's 
current gender imbalance.

In much the same way programming is predominantly male (or "a goddamn 
sausage-fest" as I see it), nursing is predominantly female. So why did 
none of US pursue careers in nursing? Was it because we hit roadblocks 
with systems in place within the nursing field designed to exclude 
males? Or was it because we just plain weren't interested and had the 
freedom to choose a field we DID have interest in instead?

Systems DO undeniably exist, for this very field, that are very plainly 
and deliberately sexist or racist though...but just not in the way some 
people believe. Unlike the others, I CAN provide a real concrete 
verifiable example: There are a lot of Computer Science grants and 
scholarships for students that list "female" or "non-caucasian" (or some 
specific non-caucasian race) as a mandatory requirement. I came across a 
bunch of those when I was trying to get financial aid for college. But 
there are NONE that require "male" or "caucasian" - it would never be 
permitted anyway, they'd get completely torn to shreds (and for good 
reason). The only ONE I did hear of was only a publicity stunt to point 
out the hypocrisy of all the sexist anti-male grants/scholarships.

Verifiable fact: My sister paid considerably less than I did for each 
year of college even though we came from EXACTLY the same economic 
background, exactly the same city/town, exactly the same ethnicity, 
nearly the same age (and yet she's slightly younger, so if anything, 
increasing tuition rates would have worked AGAINST her), and one of our 
respective colleges was even the exact same school. And her pay now is 
(considerably) higher than mine, and she works in a field that's known 
to pay LESS than my field.

Anti-female systems in place? Bull fucking shit. Anyone who claims there 
are: put up REAL fucking examples instead of parroting vacuous rhetoric 
or shut the fuck up forever.

I've had far more than enough of the mother fucking baby-goddamn-boomers 
and GI-generation dragging THEIR bullshit war-of-the-sexes out the the 
goddamn 1950's where it belongs and forcing it onto MY 1980's+ 
generation. I literally grew up subjected to a constant barrage of 
"*GIRLS* can do/be ANYTHING they want", never a goddamn word about guys 
except to constantly villanize us and demand that we're always the 
enemy, even though *3* motherfucking decades separated me from all YOUR 
historic sexist crap, so, boomers, goddamn GI's, and the younger idiots 
they've infected with their "this is still 1950, and we must war against 
the oppressive males" propaganda, hurry up and die so we can finally be 
rid of YOUR legacy and the sexism you create and maintain. Fuck the 
pendulum, just stop the goddamn thing right in the middle already. 
People are morons.
May 04 2016
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

 On 05/04/2016 10:23 AM, deadalnix wrote:

 We need to acknowledge that there are system of oppression 
 that keep
 women and people of color out of programming,


 Hard to tell for certain, but you ARE being sarcastic/joking 
 about this, right?


The concept of sarcasm plays a central role in understanding 
society's inevitable development from bourgeois oppression, 
which, in turn, amplify existing structures of exclusion. Please 
educate yourself.
May 04 2016
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 05/04/2016 12:16 PM, deadalnix wrote:

 On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

 On 05/04/2016 10:23 AM, deadalnix wrote:

 We need to acknowledge that there are system of oppression that keep
 women and people of color out of programming,


 Hard to tell for certain, but you ARE being sarcastic/joking about
 this, right?


 The concept of sarcasm plays a central role in understanding society's
 inevitable development from bourgeois oppression, which, in turn,
 amplify existing structures of exclusion. Please educate yourself.


That really doesn't answer the question, but that's ok, wasn't really 
that important of a question to me.
May 04 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 4 May 2016 at 17:42:01 UTC, Nick Sabalausky wrote:

 On 05/04/2016 12:16 PM, deadalnix wrote:

 On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky 
 wrote:

 Hard to tell for certain, but you ARE being sarcastic/joking 
 about
 this, right?


 The concept of sarcasm plays a central role in understanding 
 society's
 inevitable development from bourgeois oppression, which, in 
 turn,
 amplify existing structures of exclusion. Please educate 
 yourself.


 That really doesn't answer the question, but that's ok, wasn't 
 really that important of a question to me.


Poe's law strikes again!

Really though, deadalnix is being ultra-sarcastic. Check out his 
more serious comments from the last thread touching on this 
subject, if you want to know what he really thinks:
     
http://forum.dlang.org/post/wongmdtjgsgsmxmyuqhi forum.dlang.org
May 04 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 4 May 2016 at 18:17:57 UTC, tsbockman wrote:

 On Wednesday, 4 May 2016 at 17:42:01 UTC, Nick Sabalausky wrote:

 On 05/04/2016 12:16 PM, deadalnix wrote:

 On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky 
 wrote:

 Hard to tell for certain, but you ARE being sarcastic/joking 
 about
 this, right?


 The concept of sarcasm plays a central role in understanding 
 society's
 inevitable development from bourgeois oppression, which, in 
 turn,
 amplify existing structures of exclusion. Please educate 
 yourself.


 That really doesn't answer the question, but that's ok, wasn't 
 really that important of a question to me.


 Poe's law strikes again!

 Really though, deadalnix is being ultra-sarcastic. Check out 
 his more serious comments from the last thread touching on this 
 subject, if you want to know what he really thinks:
     
 http://forum.dlang.org/post/wongmdtjgsgsmxmyuqhi forum.dlang.org


Yup. How sad it is that gibberish nonsense can actually looks 
like it is being written seriously.
May 05 2016
next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 5 May 2016 at 09:28:27 UTC, deadalnix wrote:


 Yup. How sad it is that gibberish nonsense can actually looks 
 like it is being written seriously.


You would take any gibberish seriously these days:

http://www.dailymail.co.uk/news/article-3515202/Man-reported-police-Sweden-doing-revenge-fart-woman-denied-sex.html
May 05 2016
prev sibling parent reply QAston <qaston gmail.com> writes:
On Thursday, 5 May 2016 at 09:28:27 UTC, deadalnix wrote:

 On Wednesday, 4 May 2016 at 18:17:57 UTC, tsbockman wrote:

 Poe's law strikes again!

 Really though, deadalnix is being ultra-sarcastic. Check out 
 his more serious comments from the last thread touching on 
 this subject, if you want to know what he really thinks:
     
 http://forum.dlang.org/post/wongmdtjgsgsmxmyuqhi forum.dlang.org


 Yup. How sad it is that gibberish nonsense can actually looks 
 like it is being written seriously.


https://en.wikipedia.org/wiki/Sokal_affair

I think IT is going to be more resistant to this nonsense than 
social sciences. It is more competitive and verified by 
customers, so at least in theory the worst ideas will die. On the 
other hand, having a boogeyman to blame everything on (I didn't 
succeed as a programmer because the evil patriarch put braces in 
there) is so appealing to more and more people.

C+=[2](someone remade the repo after ban from github/bitbucket) 
is just one more parody that's going to become reality. I could 
even see marketing such a programming language right now, with 
getting politicians and educational institutions to support it. 
Who knows, maybe "research" done in this thread is laying grounds 
just for that. Hopefully, whoever uses that card first does a 
decent job in creating their "inclusive" language and we won't 
end up with js/php hybrid with rough and fuzzy sets as primitives 
(you know, to get rid of rigid maleness).

https://github.com/ErisBlastar/cplusequality
May 05 2016
parent reply Kagamin <spam here.lot> writes:
On Thursday, 5 May 2016 at 21:20:36 UTC, QAston wrote:

 https://en.wikipedia.org/wiki/Sokal_affair

 I think IT is going to be more resistant to this nonsense than 
 social sciences. It is more competitive and verified by 
 customers, so at least in theory the worst ideas will die.


Huh? Sokal affair can be prevented by censorship. Do you want it 
in IT? You make it live by making commotion around it.


 C+=[2](someone remade the repo after ban from github/bitbucket) 
 is just one more parody that's going to become reality.


And why C+= should be censored? If people believe there is some 
sort of oppression in programming languages there should be a 
comprehensive answer to that in the form of C+=.
May 06 2016
parent reply QAston <qaston gmail.com> writes:
On Friday, 6 May 2016 at 10:10:22 UTC, Kagamin wrote:

 On Thursday, 5 May 2016 at 21:20:36 UTC, QAston wrote:

 https://en.wikipedia.org/wiki/Sokal_affair

 I think IT is going to be more resistant to this nonsense than 
 social sciences. It is more competitive and verified by 
 customers, so at least in theory the worst ideas will die.


 Huh? Sokal affair can be prevented by censorship. Do you want 
 it in IT? You make it live by making commotion around it.


 C+=[2](someone remade the repo after ban from 
 github/bitbucket) is just one more parody that's going to 
 become reality.


 And why C+= should be censored? If people believe there is some 
 sort of oppression in programming languages there should be a 
 comprehensive answer to that in the form of C+=.


Sokal affair is just a demonstration of how far detached from 
reality are postmodernists, refering to cited post. I'm all for 
parodies like this, no idea why you think otherwise.
May 06 2016
parent Kagamin <spam here.lot> writes:
On Friday, 6 May 2016 at 12:33:10 UTC, QAston wrote:

 Sokal affair is just a demonstration of how far detached from 
 reality are postmodernists, refering to cited post.


Those attached to objective reality are usually detached from 
subjective reality. That's the mistake postmodernism fixes (or 
tries). Not much can be added to knowledge of objective reality 
found by classic and modernism, but that's what they are limited 
to.
May 06 2016
prev sibling next sibling parent reply Anon <anon anon.anon> writes:
On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

 It's touchy, because I've come across people who actually do 
 genuinely believe the field has things in place deliberately to 
 exclude women/ethnicities...even though...those VERY SAME 
 people have never once been able to provide a SINGLE CONCRETE 
 EXAMPLE of any of these alleged mechanisms they believe so 
 strongly to exist.


Cognitive biases are a thing. People assume women are bad at 
math. People assume black people are violent thugs. People assume 
Asians are savant-level geniuses. People assume Native Americans 
are alcoholics. People assume Arabs are Muslims. People assume 
Muslims are terrorists. Those assumptions and biases dictate how 
we interact with the world. Sociology can describe systems and 
mechanisms that aren't controlled by people or even intentional. 
People do not even need to be aware of their biases. That doesn't 
make them not exist.


 Not only that, but I've yet to come across an anti-minority or 
 anti-female programmer, and even if such creatures exist, 
 they're undeniably var too much in the minority to have any 
 real large-scale effect on "keeping people out".


Anti-<blank> is irrelevant, as it is fairly easy to deal with. 
Perceptions and biases are what matter. As I said above, people 
(in general) assume women are bad at math. That makes them less 
likely to trust any math a female coworker does than they would 
be to trust the same math done by a male coworker. Women get 
tired of dealing with others disregarding them based on these 
assumptions, and feel unwelcome in the field. Nobody needs to be 
intentionally excluding them for them to be excluded. I know I 
wouldn't keep working somewhere if nobody took me seriously.


 The vast majority that I've seen are far more likely to 
 *dislike* the field's current gender imbalance.

 In much the same way programming is predominantly male (or "a 
 goddamn sausage-fest" as I see it), nursing is predominantly 
 female. So why did none of US pursue careers in nursing? Was it 
 because we hit roadblocks with systems in place within the 
 nursing field designed to exclude males? Or was it because we 
 just plain weren't interested and had the freedom to choose a 
 field we DID have interest in instead?


Actual answer: boys are raised to view nursing as a girl's job, 
and taught that they should not pursue "feminine" jobs. The same 
is true of girls being taught not to pursue "masculine" jobs. 
This is changing, thankfully, but the outdated views are still 
pervasive.


 Systems DO undeniably exist, for this very field, that are very 
 plainly and deliberately sexist or racist though...but just not 
 in the way some people believe. Unlike the others, I CAN 
 provide a real concrete verifiable example: There are a lot of 
 Computer Science grants and scholarships for students that list 
 "female" or "non-caucasian" (or some specific non-caucasian 
 race) as a mandatory requirement. I came across a bunch of 
 those when I was trying to get financial aid for college. But 
 there are NONE that require "male" or "caucasian" - it would 
 never be permitted anyway, they'd get completely torn to shreds 
 (and for good reason). The only ONE I did hear of was only a 
 publicity stunt to point out the hypocrisy of all the sexist 
 anti-male grants/scholarships.


And yet plenty of male-targeted outreach programs and 
scholarships do exist. In fields like nursing, for example. The 
point of such programs/scholarships is to create downward 
pressure on K-12 schooling to raise kids to not view *themselves* 
through these bias filters.


 Verifiable fact: My sister paid considerably less than I did 
 for each year of college even though we came from EXACTLY the 
 same economic background, exactly the same city/town, exactly 
 the same ethnicity, nearly the same age (and yet she's slightly 
 younger, so if anything, increasing tuition rates would have 
 worked AGAINST her), and one of our respective colleges was 
 even the exact same school. And her pay now is (considerably) 
 higher than mine, and she works in a field that's known to pay 
 LESS than my field.


Not enough information in this anecdote. Your sister could have 
had higher grades than you, granting her more scholarship money. 
Need-based grants/scholarships take in to account the number of 
kids parents are supporting and how many are in university, and 
the kids' incomes (if any). She may have also applied herself 
more and gotten promoted more which could reverse the expected 
pay gap.


 Anti-female systems in place? Bull fucking shit. Anyone who 
 claims there are: put up REAL fucking examples instead of 
 parroting vacuous rhetoric or shut the fuck up forever.


You are really starting to sound like the type of person who 
denies climate change because it was chilly in your city 
yesterday. Please don't be that person. Nobody likes that person. 
Nobody takes that person seriously.


 I've had far more than enough of the mother fucking 
 baby-goddamn-boomers and GI-generation dragging THEIR bullshit 
 war-of-the-sexes out the the goddamn 1950's where it belongs 
 and forcing it onto MY 1980's+ generation. I literally grew up 
 subjected to a constant barrage of "*GIRLS* can do/be ANYTHING 
 they want", never a goddamn word about guys except to 
 constantly villanize us and demand that we're always the enemy, 
 even though *3* motherfucking decades separated me from all 
 YOUR historic sexist crap, so, boomers, goddamn GI's, and the 
 younger idiots they've infected with their "this is still 1950, 
 and we must war against the oppressive males" propaganda, hurry 
 up and die so we can finally be rid of YOUR legacy and the 
 sexism you create and maintain. Fuck the pendulum, just stop 
 the goddamn thing right in the middle already.


Since we are comparing anecdotes, I grew up constantly being told 
I was smart, as the girls I went to for help with math were told 
they were dumb. The baby boomers around me were constantly 
propagated the "girls must be stay at home mothers and are too 
dumb to have a STEM job" bullshit (despite my mom being the one 
to handle finances). Even through college, people took me more 
seriously than my smarter (sometimes female) peers, because their 
cognitive biases made me seem smarter than I am (mostly due to my 
physical appearance).


 People are morons.


On that, we agree. But disregarding others' life experiences (and 
sociological research) because they differ from your own benefits 
nobody.
May 04 2016
next sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 4 May 2016 at 18:29:25 UTC, Anon wrote:

 Anti-<blank> is irrelevant, as it is fairly easy to deal with. 
 Perceptions and biases are what matter. As I said above, people 
 (in general) assume women are bad at math. That makes them less 
 likely to trust any math a female coworker does than they would 
 be to trust the same math done by a male coworker.


That's a strange idea to organize STEM based on trust. Would you 
like to fly on an airplane built without any quality control and 
where people blindly trusted everybody knowing what they do and 
hoping for the better?


 I know I wouldn't keep working somewhere if nobody took me 
 seriously.


Do tell, where all people are invariably taken seriously.
May 05 2016
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 05/04/2016 02:29 PM, Anon wrote:

 On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

 It's touchy, because I've come across people who actually do genuinely
 believe the field has things in place deliberately to exclude
 women/ethnicities...even though...those VERY SAME people have never
 once been able to provide a SINGLE CONCRETE EXAMPLE of any of these
 alleged mechanisms they believe so strongly to exist.


 Cognitive biases are a thing. People assume women are bad at math.
 People assume black people are violent thugs. People assume Asians are
 savant-level geniuses. People assume Native Americans are alcoholics.
 People assume Arabs are Muslims. People assume Muslims are terrorists.
 Those assumptions and biases dictate how we interact with the world.
 Sociology can describe systems and mechanisms that aren't controlled by
 people or even intentional. People do not even need to be aware of their
 biases. That doesn't make them not exist.


I'm well aware people with those biases do exist. The word for that is 
"bigot". And they often DO attempt to project their hateful biases onto 
others, believing that everyone feels the same way they do and simply 
doesn't admit it. I guess that delusion just helps them feel better 
about themselves, or help justify their twisted perceptions to 
themselves? In any case, they do very strongly and consistently reject 
the fact the rest of us really honestly don't share the same twisted 
biases they do, and will never allow themselves to be convinced otherwise.
May 05 2016
prev sibling parent QAston <qaston gmail.com> writes:
On Wednesday, 4 May 2016 at 18:29:25 UTC, Anon wrote:

 On that, we agree. But disregarding others' life experiences 
 (and sociological research) because they differ from your own 
 benefits nobody.


Research is not conclusive, at least according to this 
documentary [1]. Some food for thought and gasoline for a 
flamewar.

https://vimeo.com/19707588
May 05 2016
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

[snip]


 Verifiable fact: My sister paid considerably less than I did 
 for each year of college even though we came from EXACTLY the 
 same economic background, exactly the same city/town, exactly 
 the same ethnicity, nearly the same age (and yet she's slightly 
 younger, so if anything, increasing tuition rates would have 
 worked AGAINST her), and one of our respective colleges was 
 even the exact same school. And her pay now is (considerably) 
 higher than mine, and she works in a field that's known to pay 
 LESS than my field.


There are groups in Europe and the US (and elsewhere I'm sure) 
who try to draw attention to this issue, like these guys for 
example http://www.avoiceformen.com/.


 Anti-female systems in place? Bull fucking shit. Anyone who 
 claims there are: put up REAL fucking examples instead of 
 parroting vacuous rhetoric or shut the fuck up forever.


My experience with computer science and related fields is that a 
lot of young women are into computers, just not into programming. 
They are drawn to computers because of multi-media stuff, digital 
design, creating videos, creating games (often educational games 
for kids) with easy to use frameworks. The closer you get to the 
machine, the less women you will find (mind you, this does not 
mean "no women at all"), to give you a _rough_ scale of 
increasing complexity: multi-media and social networks (e.g. 
blogs) > app development > Python > Java > C/C++ > compiler 
programming / assembly ...

I know from my own experience that no matter how much you 
encourage and support women (who have a degree in CS or related) 
to code their own stuff, they often don't want to and prefer to 
use drag-and-drop frameworks and let the lads (for Americans: 
this means "the guys / men") do the nitty-gritty stuff.

Now, one can argue whether all this is down to biological (i.e. 
evolutionary) programming, which has in turn been perpetuated by 
social structures, or whether this is a purely social artifact. 
Either way,  we should provide everybody with equal 
opportunities. While women should not be discouraged from doing 
anything they want to do, they should not be pampered either, 
because this would be unfair to men and indeed sexist, 
perpetuating the view that women are delicate flowers that have 
to be protected and cannot stand up for themselves.
May 04 2016
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 05/04/2016 03:15 PM, Chris wrote:

 On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

 [snip]


 Verifiable fact: My sister paid considerably less than I did for each
 year of college even though we came from EXACTLY the same economic
 background, exactly the same city/town, exactly the same ethnicity,
 nearly the same age (and yet she's slightly younger, so if anything,
 increasing tuition rates would have worked AGAINST her), and one of
 our respective colleges was even the exact same school. And her pay
 now is (considerably) higher than mine, and she works in a field
 that's known to pay LESS than my field.


 There are groups in Europe and the US (and elsewhere I'm sure) who try
 to draw attention to this issue, like these guys for example
 http://www.avoiceformen.com/.


Unfortunately does no good: Any association with anything like that 
means automatic social black-listing as "women hater". And it's never 
going to convince anyone of anything for the same reason persuasive 
arguing in general never really works: Anyone who doesn't already agree 
will never willingly go anywhere near it, except occasionally with a 
purely "burn the witch" agenda.

Perfect example of why all people worldwide should simply be destroyed:

https://www.youtube.com/watch?v=7M0MW6ON484

Sickening, and not the least bit surprising.

There was another similar thing on a hidden camera show, showing actors 
eating right out of a grocery store produce aisle. When the actor was a 
guy, both men and women bystanders were livid, but when it was a woman, 
both men and women bystanders found it cute and acceptable.

And then there's all the studies out there demonstrating how many times 
more likely a woman with a broken-down car by the side of a road will 
receive assistance than a guy will.

But of course, all of that evidence is merely a plot by us evil men 
trying to wage war on women.


 Anti-female systems in place? Bull fucking shit. Anyone who claims
 there are: put up REAL fucking examples instead of parroting vacuous
 rhetoric or shut the fuck up forever.


 My experience with computer science and related fields is that a lot of
 young women are into computers, just not into programming. They are
 drawn to computers because of multi-media stuff, digital design,
 creating videos, creating games (often educational games for kids) with
 easy to use frameworks. The closer you get to the machine, the less
 women you will find (mind you, this does not mean "no women at all"), to
 give you a _rough_ scale of increasing complexity: multi-media and
 social networks (e.g. blogs) > app development > Python > Java > C/C++ >
 compiler programming / assembly ...


Right. And then all the males in the field get blamed for it when the 
women simply chose of their own volition not to pursue it. It must've 
been our ingrained biases ::rolleyes::. Right, because we have to 
pretend EVERYONE has those moronic biases just because it helps the 
fucking bigots pretend they're really just "normal".

Interesting side note: Notice that, due to another recent thread here, I 
had to use the word "women" rather than "females" in that last sentence, 
but nobody raises an eyebrow at usage of "males" being used to refer to 
people, not even in my earlier post in this thread.
May 05 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

 Anti-female systems in place? Bull fucking shit. Anyone who 
 claims there are: put up REAL fucking examples instead of 
 parroting vacuous rhetoric or shut the fuck up forever.


Well, there's the Obama White House:

https://www.washingtonpost.com/politics/male-female-pay-gap-remains-entrenched-at-white-house/2014/07/01/dbc6c088-0155-11e4-8fd0-3a663dfa68ac_story.html

Don't forget Hillary's Senate staff:

http://www.ijreview.com/2015/02/257200-hillary-clinton-paid-female-staff-28-percent-less-men/

If those paragons of virtue are underpaying their female 
staffers, imagine how much worse it is elsewhere? ;) Of course 
I'm joking, since you missed deadalnix's sarcasm.

If we want to close all gaps, we should also close the gender gap 
for occupational fatalities:

http://mjperry.blogspot.com/2009/09/occupational-male-female-death-gap-is.html

That means 4,000 more women will die on the job this year, make 
sure you mention that to any feminist pushing those bogus pay gap 
figures.
May 04 2016
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 04.05.2016 21:38, Joakim wrote:

 If we want to close all gaps, we should also close the gender gap for
 occupational fatalities:

 http://mjperry.blogspot.com/2009/09/occupational-male-female-death-gap-is.html


 That means 4,000 more women will die on the job this year, make sure you
 mention that to any feminist pushing those bogus pay gap figures.


Or, you know, 4000 men less.
May 04 2016
parent Joakim <dlang joakim.fea.st> writes:
On Wednesday, 4 May 2016 at 19:47:41 UTC, ag0aep6g wrote:

 On 04.05.2016 21:38, Joakim wrote:

 If we want to close all gaps, we should also close the gender 
 gap for
 occupational fatalities:

 http://mjperry.blogspot.com/2009/09/occupational-male-female-death-gap-is.html


 That means 4,000 more women will die on the job this year, 
 make sure you
 mention that to any feminist pushing those bogus pay gap 
 figures.


 Or, you know, 4000 men less.


Unrealistic, those jobs have real risks that cannot just be 
hand-waved away, which is why they often come with compensating 
high pay, as that blog post notes.  If we populate all job fields 
with 50% women, that means female deaths on the job would 
inevitably rise a lot.  Yet, you will never see that mentioned...
May 04 2016
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 4 May 2016 at 19:38:45 UTC, Joakim wrote:

 If we want to close all gaps, we should also close the gender 
 gap for occupational fatalities:

 http://mjperry.blogspot.com/2009/09/occupational-male-female-death-gap-is.html

 That means 4,000 more women will die on the job this year, make 
 sure you mention that to any feminist pushing those bogus pay 
 gap figures.


Why close the gaps in the first place? Why diversity is not good?
May 05 2016
parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 5 May 2016 at 13:44:47 UTC, Kagamin wrote:

 On Wednesday, 4 May 2016 at 19:38:45 UTC, Joakim wrote:

 If we want to close all gaps, we should also close the gender 
 gap for occupational fatalities:

 http://mjperry.blogspot.com/2009/09/occupational-male-female-death-gap-is.html

 That means 4,000 more women will die on the job this year, 
 make sure you mention that to any feminist pushing those bogus 
 pay gap figures.


 Why close the gaps in the first place? Why diversity is not 
 good?


Maybe you're asking rhetorically, but I'll be clear and note that 
I did say "If."  I'm not interested in closing any gaps, as I 
noted that the pay gap is bogus, just pointing out the fatality 
gap that no feminist will talk about.  Prisons are also 90+% full 
of men (http://www.prisonpolicy.org/graphs/genderinc.html) and 
men had much higher unemployment in the recent US recession, as 
noted in the fatality link above.

I agree that men and women are different, on average, and a gap 
doesn't necessarily mean discrimination.  The NBA and NFL 
basketball and football leagues in the US are 95+% full of black 
African-americans in a country that is only 15-20% black: is 
there widespread discrimination going on against whites?

This recent notion that there must be perfect gender balance or 
proportional racial representation across every field of endeavor 
is what is ridiculous, and the link above is meant to demonstrate 
that, by pointing out an example of where they don't really want 
to "close the gap."

On Thursday, 5 May 2016 at 14:32:23 UTC, Nick Sabalausky wrote:

 On 05/04/2016 03:38 PM, Joakim wrote:

 Well, there's the Obama White House:

 https://www.washingtonpost.com/politics/male-female-pay-gap-remains-entrenched-at-white-house/2014/07/01/dbc6c088-0155-11e4-8fd0-3a663dfa68ac_story.html


 Don't forget Hillary's Senate staff:

 http://www.ijreview.com/2015/02/257200-hillary-clinton-paid-female-staff-28-percent-less-men/


 If those paragons of virtue are underpaying their female 
 staffers,
 imagine how much worse it is elsewhere? ;) Of course I'm 
 joking, since
 you missed deadalnix's sarcasm.


 I meant specifically in tech fields, esp. programming. 
 Naturally, I'm not surprised that sort of thing happens in DC.


Wow, you're literal, I said I was joking. :) Specifically, 
perhaps you don't really follow this debate, but those "gap 
stats" are calculated in the same way the overall stats that 
Obama and Hillary always trumpet are calculated, in a completely 
bogus way.

They take all positions across the economy, regardless of age, 
experience, skills, etc., lump them all together and come to the 
ludicrous conclusion that women are being paid 15-25% less "for 
the same work."  Those links point out that if you use the same 
bogus approach for their own staffs, _they_ are also paying women 
less.  Of course, that's likely because men tend to have more 
experience and higher-ranking positions on their staff, not 
because they're discriminating against women.  Once you control 
for experience, skills, etc., the "gap" shrinks to almost nothing.

On Thursday, 5 May 2016 at 14:59:05 UTC, Nick Sabalausky wrote:

 Perfect example of why all people worldwide should simply be 
 destroyed:

 https://www.youtube.com/watch?v=7M0MW6ON484

 Sickening, and not the least bit surprising.


C'mon, that's because they know she couldn't really hurt him and 
he's holding back, whereas the same wasn't true in the first 
case.  I don't find that one surprising.
May 05 2016
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 05/04/2016 03:38 PM, Joakim wrote:

 On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:

 Anti-female systems in place? Bull fucking shit. Anyone who claims
 there are: put up REAL fucking examples instead of parroting vacuous
 rhetoric or shut the fuck up forever.


 Well, there's the Obama White House:

 https://www.washingtonpost.com/politics/male-female-pay-gap-remains-entrenched-at-white-house/2014/07/01/dbc6c088-0155-11e4-8fd0-3a663dfa68ac_story.html


 Don't forget Hillary's Senate staff:

 http://www.ijreview.com/2015/02/257200-hillary-clinton-paid-female-staff-28-percent-less-men/


 If those paragons of virtue are underpaying their female staffers,
 imagine how much worse it is elsewhere? ;) Of course I'm joking, since
 you missed deadalnix's sarcasm.


I meant specifically in tech fields, esp. programming. Naturally, I'm 
not surprised that sort of thing happens in DC.
May 05 2016
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:

 I'm a social scientist and I'm preparing some studies on the 
 effects of programming language syntax on learning, motivation 
 to pursue programming, as well as any disproportionate effects 
 that PL syntax has on the appeal of programming to women (more 
 on the latter in a separate post).


Do you study, how sumo wrestling and coal mining appeal to women?


 Would it be difficult to compile the clean version? Would there 
 be issues with the design of the lexer/parser? I assume the 
 compiler would recognize keywords like return (and a clean 
 syntax could drive different rules for what statements and 
 expressions could appear on the same line and so forth).


You can write Python code with semicolons: 
http://ideone.com/3Qo5bD python has the cost of having them, but 
not the benefit.

Also: dynamic vs static typing.


 I'm just thinking that Facebook has built software that 
 recognizes my face in other people's pictures, so it seems like 
 building software that understands structured text would be a 
 solved problem.


The unsolved problem is who will donate computation power to my 
brain.
May 04 2016
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2016-05-03 at 03:48 +0000, Joe Duarte via Digitalmars-d wrote:

 [=E2=80=A6]


Joe,

Are you in touch with the PPIG and/or EACE people? There is almost
certainly some prior literature on all this. I know this for a fact as
I was involved with an experiment looking at this sort of thing back in
the early 1990s.

http://www.ppig.org/
http://www.eace.net/

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 04 2016