On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei
Alexandrescu wrote:
What say you?
Andrei
I think most people like the idea of having new things
categorized, but encounter difficulty agreeing on what categories
to use. Everyone will make broad assumptions that fit their
comfort zone. Word choices like "experimental" or "testing" could
influence people's impressions of stability, and so could the
method of friction that is added to prevent accidental use. The
point is to be a little bit scary - but are we scaring off the
right people when we use these words and techniques?
I don't have much D history but I would approach the issue
ground-up and reconsider the options for introductions. I thought
of these ways that friction could be added(considering here both
library and language features):
1. Rebuild compiler with additional flags.
2. Available only in one or more separate library versions(e.g. a
dub package that replaces "stable" std).
3. Run compiler with additional flags.
4. Import a named package like std.experimental.
There is a very key difference between the first three and the
fourth in that if you have modified the compiler, your build
flags, or your library environment, you are more likely to be
working on a personal machine with personal projects, and can
afford to tinker with a rapidly changing situation. With 4,
people will be able to use it injudiciously in production by
copy-pasting source code from someone's example - no warnings
will appear as a result of this.
Knowing that, we have to ask some questions about workflows to
settle what the role of std.experimental is. Friction appears
_after_ a symbol is moved out of experimental, as noted by
previous replies, when what is desired is for graduation out of
experimental to be apparently seamless. On the other hand, it's
very troublesome to have working code break after toggling a flag
to turn on the experimental things. Flags should feel "precise"
and not disturb the existing code. Environmental changes add
friction around initial use - when code doesn't "just work"
because it requires an environment change it is likely to be
reconsidered by its user.
Perhaps that means a rule like: if it's entirely new, use a build
flag, or expose it in an "unstable" library version. If it
modifies/refines an old, stable symbol, use std.experimental, and
deprecate the old API as confidence grows - thus encouraging
people to move towards experimental often, but to start
manipulating the rest of the environment if they want to be truly
adventurous. (this doesn't exactly solve the "post-hoc friction"
problem, but it scores well on accident prevention)
There's probably much more to consider but I will leave my
thought there.
