digitalmars.D - Researcher question =?UTF-8?B?4oCT?= what's the point of semicolons
- Joe Duarte (41/41) May 02 2016 Hi all,
- rikki cattermole (5/45) May 02 2016 One of the benefits of having semicolons and braces is that you can have...
- Walter Bright (15/17) May 02 2016 You are correct in that they are (mostly) redundant. Some ambiguities
- Jonathan M Davis via Digitalmars-d (23/34) May 03 2016 That redundancy also can make it much easier for the programmer to figur...
- Henry Gouk (4/13) May 03 2016 An example of this would be that Apple SSL bug that has largely
- Joe Duarte (25/45) May 03 2016 Your point about redundancy is interesting. I assume typos aren't
- tsbockman (10/15) May 03 2016 You're not going to even try to fix it until you realize it's
- ag0aep6g (5/10) May 03 2016 D doesn't have that kind of redundancy either here. For the compiler to
- Walter Bright (2/6) May 03 2016 The grammar is redundant, not the whitespace.
- tsbockman (9/24) May 04 2016 No it doesn't.
- ag0aep6g (2/6) May 04 2016 That makes a ton of sense, and didn't occur to me at all.
- Chris (53/68) May 04 2016 I agree. A very common annoyance in Python is the rule that you
- Adam D. Ruppe (115/122) May 02 2016 You realize your bias is showing very strongly in the wording of
- Bauss (2/8) May 02 2016 Praise this
- Ivan Kazmenko (2/7) May 03 2016 "Obligatory" xkcd link: https://xkcd.com/385/
- CRAIG DILLABAUGH (2/8) May 03 2016 Hey, you spelled 'what' wrong :o)
- Joe Duarte (7/12) May 03 2016 Fair point. I probably am biased, though I don't think an
- qznc (21/48) May 03 2016 The parser needs information about "blocks". Here is an example:
- Observer (4/8) May 03 2016 Four methods. Let's not forget statement labels and "goto",
- Joe Duarte (29/52) May 13 2016 Thanks for the example! So you laid out the three options for
- Abdulhaq (4/13) May 14 2016 there's a keyboard for those types of programs ;-)
- Adam D. Ruppe (7/9) May 14 2016 One of the things I do with my custom terminal emulator and text
- ag0aep6g (4/7) May 03 2016 Something that hasn't been mentioned so far:
- matovitch (7/7) May 03 2016 Another thing is that some people (like me) likes to shape the
- HaraldZealot (11/18) May 03 2016 And D-specific syntax for range-based algorithms often also
- Chris (37/48) May 03 2016 Yes, please elaborate on this. I have to say I don't like the
- Observer (15/33) May 03 2016 I have to say, not to be too negative, but this researcher's
- Observer (25/26) May 03 2016 Let me turn that around and suggest something in a positive light.
- poliklosio (5/10) May 03 2016 I'm bewildered by the use of the word "thongs" here. I'm just
- jmh530 (2/3) May 03 2016 tongs.
- cym13 (49/55) May 03 2016 Ok, a lot has been said against the braceless version, I think
- qznc (13/34) May 04 2016 I don't understand your reasoning how curly braces makes D faster
- Joe Duarte (60/75) May 14 2016 Good point that line-ending semicolons carry no information if
- ag0aep6g (24/37) May 14 2016 On semicolons:
- Poyeyo (20/62) May 03 2016 Compilers, with or without curly braces and semicolons, will
- Walter Bright (3/8) May 03 2016 therearealsoaestheticswedonotactuallyneedspacesorpunctuationorcasetoread...
- Walter Bright (5/10) May 03 2016 One of the things that comes with Haskell has nothing to do with
- Max Samukha (5/10) May 05 2016 It is actually no harder to read after some practice than a
- deadalnix (5/11) May 04 2016 It should be obvious that curly braces are a symbol of
- Tobias Pankrath (8/12) May 04 2016 Attributing a redundant element of the grammar to femininity just
- deadalnix (10/23) May 04 2016 Are you seriously saying that element of femininity in the
- Chris (10/19) May 04 2016 I find the whole research question weird. Does it suggest that
- Nick Sabalausky (54/56) May 04 2016 Hard to tell for certain, but you ARE being sarcastic/joking about this,...
- deadalnix (5/12) May 04 2016 The concept of sarcasm plays a central role in understanding
- Nick Sabalausky (3/15) May 04 2016 That really doesn't answer the question, but that's ok, wasn't really
- Anon (52/111) May 04 2016 Cognitive biases are a thing. People assume women are bad at
- Kagamin (6/13) May 05 2016 That's a strange idea to organize STEM based on trust. Would you
- Nick Sabalausky (9/23) May 05 2016 I'm well aware people with those biases do exist. The word for that is
- QAston (5/8) May 05 2016 Research is not conclusive, at least according to this
- Chris (29/41) May 04 2016 There are groups in Europe and the US (and elsewhere I'm sure)
- Nick Sabalausky (28/54) May 05 2016 Unfortunately does no good: Any association with anything like that
- Joakim (14/17) May 04 2016 Well, there's the Obama White House:
- ag0aep6g (2/7) May 04 2016 Or, you know, 4000 men less.
- Joakim (6/19) May 04 2016 Unrealistic, those jobs have real risks that cannot just be
- Kagamin (2/8) May 05 2016 Why close the gaps in the first place? Why diversity is not good?
- Joakim (37/72) May 05 2016 Maybe you're asking rhetorically, but I'll be clear and note that
- Nick Sabalausky (3/14) May 05 2016 I meant specifically in tech fields, esp. programming. Naturally, I'm
- Kagamin (8/22) May 04 2016 You can write Python code with semicolons:
- Russel Winder via Digitalmars-d (18/19) May 04 2016 Joe,
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
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). JDOne 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
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
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: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 DavisWhy 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.
May 03 2016
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
On Tuesday, 3 May 2016 at 04:23:48 UTC, Walter Bright wrote:On 5/2/2016 8:48 PM, Joe Duarte wrote: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.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 03 2016
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
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
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
On Wednesday, 4 May 2016 at 05:45:39 UTC, ag0aep6g wrote:On 04.05.2016 07:27, tsbockman wrote:Yes it does.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.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
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
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 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); }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 04 2016
On Wednesday, 4 May 2016 at 09:28:41 UTC, Chris wrote:On Wednesday, 4 May 2016 at 05:27:43 UTC, tsbockman wrote: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.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.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.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
On Wednesday, 4 May 2016 at 11:03:46 UTC, cym13 wrote:On Wednesday, 4 May 2016 at 09:28:41 UTC, Chris wrote: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.[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
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
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:Praise this[...]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. [...]
May 02 2016
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
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:Hey, you spelled 'what' wrong :o)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
May 03 2016
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: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)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.
May 03 2016
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
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
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
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.pngthere's a keyboard for those types of programs ;-) http://www.dyalog.com/uploads/images/Business/products/us_rc.jpg (APL keyboard)
May 14 2016
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.jpgOne 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
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
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
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
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
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: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.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.
May 03 2016
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
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
On Tuesday, 3 May 2016 at 21:03:36 UTC, poliklosio wrote:Is it some kind of a spelling mistake?tongs.
May 03 2016
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
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
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
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
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). JDCompilers, 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
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
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
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
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
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
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: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 !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
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
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
On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:On 05/04/2016 10:23 AM, deadalnix wrote: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.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?
May 04 2016
On 05/04/2016 12:16 PM, deadalnix wrote:On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:That really doesn't answer the question, but that's ok, wasn't really that important of a question to me.On 05/04/2016 10:23 AM, deadalnix wrote: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.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?
May 04 2016
On Wednesday, 4 May 2016 at 17:42:01 UTC, Nick Sabalausky wrote:On 05/04/2016 12:16 PM, deadalnix 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.orgOn Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:That really doesn't answer the question, but that's ok, wasn't really that important of a question to me.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
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:Yup. How sad it is that gibberish nonsense can actually looks like it is being written seriously.On 05/04/2016 12:16 PM, deadalnix 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.orgOn Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:That really doesn't answer the question, but that's ok, wasn't really that important of a question to me.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 05 2016
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
On Thursday, 5 May 2016 at 09:28:27 UTC, deadalnix wrote:On Wednesday, 4 May 2016 at 18:17:57 UTC, tsbockman 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. 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/cplusequalityPoe'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.orgYup. How sad it is that gibberish nonsense can actually looks like it is being written seriously.
May 05 2016
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
On Friday, 6 May 2016 at 10:10:22 UTC, Kagamin wrote:On Thursday, 5 May 2016 at 21:20:36 UTC, QAston wrote: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.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
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
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
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
On 05/04/2016 02:29 PM, Anon wrote:On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote: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.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.
May 05 2016
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
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
On 05/04/2016 03:15 PM, Chris wrote:On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote: [snip]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.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/.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.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 ...
May 05 2016
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
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
On Wednesday, 4 May 2016 at 19:47:41 UTC, ag0aep6g wrote:On 04.05.2016 21:38, Joakim wrote: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...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
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
On Thursday, 5 May 2016 at 13:44:47 UTC, Kagamin wrote:On Wednesday, 4 May 2016 at 19:38:45 UTC, Joakim wrote: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: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?On 05/04/2016 03:38 PM, Joakim wrote: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: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.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
On 05/04/2016 03:38 PM, Joakim wrote:On Wednesday, 4 May 2016 at 15:46:13 UTC, Nick Sabalausky wrote:I meant specifically in tech fields, esp. programming. Naturally, I'm not surprised that sort of thing happens in DC.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.
May 05 2016
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
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