On 2016-09-29 11:31, pineapple wrote:

This is not an argument to justify adding just any feature, it's an
argument that it is idiocy to give a programmer a powerful tool, and
then impose arbitrary limitations upon how they are allowed to use it.

One of the most popular topics of discussion in this forum is "Why is D
not more widely adopted?" and "What can we do to get broader adoption
for D?"

Perhaps one of the more obvious answers is: Do not prevent programmers
from doing something solely on the basis that _you_ would not want to do
it.

I think camelCase is hideous, but does that mean I should forbid another
programmer defining symbols in that style? Of course not. That they are
able to write their code that way doesn't mean I have to, and doesn't
mean I have to use or interface with their code. I agree that '+' should
always mean addition and '~' should always mean concatenation, but does
that mean I should forbid another programmer from defining them
differently? Of course not. Just because they are able to do it that way
doesn't mean I have to, or that I have to use their code.

If I thought '>' and '<' should always mean arithmetic comparison, does
that mean I should forbid another programmer from defining them
differently?

You need to understand that _you are not the only one writing code in
this language_. Your use cases do not summarize all possible use cases.
That you do not need to use a tool in a specific way is not a valid
argument against allowing others to use the tool that way.

Give us a rational argument. We are unconcerned with your personal
dogma. What you refer to as a weakness I view as a strength. Programmers
require more flexibility and expressiveness, not less.

Well said.

--
/Jacob Carlborg

Reply via email to