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.
