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"
print "%d is less than 6" % x  # <--- wrong indentation level

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);
}

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"
> print "%d is less than 6" % x  # <--- wrong indentation level
>
> 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.

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"
>> print "%d is less than 6" % x  # <--- wrong indentation level
>>
>> 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.

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 !

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.

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.

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.

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.

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.

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.