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;

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

On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:
> On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:
>> Would it be difficult to compile the clean version?
>
> You realize your bias is showing very strongly in the wording of this question, right? I don't agree the naked version is clean at all.
>
> ohimsorryletswritemorecleanlywithoutanyofthatobnoxiouspunctuationnoiseitisalluselessanywaysurelyyoucanstillmakesenseofthisafterallthereareonlysomanywordsintheenglishlanguageandknowinghwatdoesanddoesntmakesenseincontextmeansyoucansurelyparsethisrightout
>

Hey, you spelled 'what' wrong :o)

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.

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.

On Tuesday, 3 May 2016 at 18:37:54 UTC, Chris wrote:
> On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:
>> Hi all,
>>
>> I'm a social scientist and I'm preparing some studies on the effects of programming language syntax on learning, motivation to pursue programming, as well as any disproportionate effects that PL syntax has on the appeal of programming to women (more on the latter in a separate post).
>>
>
> Yes, please elaborate on this. I have to say I don't like the sound of this paragraph. Why would women be repelled by curly braces and semicolons? I know from my own experience that Python doesn't do the trick either. If a woman doesn't want to program, she just doesn't want to, even if it's in Python. It's the term "programming" that makes them (i.e. those who are not interested) run away. "Write a script" sounds nicer, but even then ... if they don't have to they won't even touch it with thongs.

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

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.

On Tuesday, 3 May 2016 at 21:03:36 UTC, poliklosio wrote:
>
> Is it some kind of a spelling mistake?

tongs.

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.

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.