watcher:
I hope i did not sound mean. I just think that a language
should not be that terse. It must be human readable with little
room to make typing or other mistakes. I rather type more if
necessary.
I agree that too much terseness is bad, making code less easy to
read. On the other hand too much long to type syntax is bad, for
different reasons.
So you need a compromises, between lot of tiny operators as in J,
K, Ursala or Perl6 languages, that are hard to remember,
understand and look in the documentation, and very long names as
std.functional.binaryReverseArgs of Phobos that are too much long.
Such intermediate point between too much long and too much short
syntax is not a constant, it must be adapted according to how
much common an operation is, in the language, across languages,
or even more generally, in mathematics, and natural languages.
The more common something is, the shorter it's better for it to
be:
http://en.wikipedia.org/wiki/Zipf%27s_law
Tuples are used very often, they are not meant to be uncommon
parts of the language. In range-heavy code you are probably going
to use a tuple every 1-5 lines of code. And even more normal D
code may use a tuple every 10-30 lines of code. So using a
succinct syntax is good.
Python uses just commas (with a bit of help of ( ) in some cases,
like for the empty tuple), but to not break a certain
compatibility with C the D language can't do the same. So we are
trying to look for something that works, doesn't clash with
currently used syntaxes, including library solutions like
Tuple!() and tuple(), and is short enough.
Tuple syntax can be short because it's going to be used often
enough, and it has to be short because where you use tuples you
don't want too much boilerplate, because functional-style code
becomes rather worse if your syntax is not terse. That's why most
functional languages, or languages with some support for
functional programming (F#, Haskell, Python, Scala, and so on)
have a nice short syntax for tuples.
Bye,
bearophile
