Researcher question – what's the point of semicolons and curly braces?

[cym13 via Digitalmars-d]

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.