On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu
wrote:
On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote:
On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright
wrote:
On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
We already have better `cpuid` and better `random` packages.
Great! Please PR them for Phobos.
cpuid is used in Mir GLAS and it should be a betterC library.
It's this kind of imaginary dialog that I don't quite grok:
Ilya Yaroshenko: "I can't use druntime's cpuid so I defined my
own."
Andrei Alexandrescu: "OK, so what's different?"
IY: "Mine has a few engineering improvements."
AA: "Cool, why don't you merge them into core.cpuid?"
IY: "Well mine doesn't have a shared static constructor, so it
doesn't need a runtime to automatically call that library
initialization function. User need to explicitly call an init
function before using it."
AA: "I understand. Great, so how about this - we add your code
to core.cpuid_v2 to druntime. Then we make all in core.cpuid to
forward to it so there's no duplication. It all works out!"
IY: "No, I don't want to do that. It's still in druntime and I
don't want druntime. I want betterC."
AA: "But it will be compilable with betterC and we can add
unittests to make that happen. YOU HAVE MY SUPPORT. Let's do
it."
IY: "No, I want to change it often. The deployment schedule of
druntime is too slow."
AA: "How often do you need to change it? Is it that unstable?"
IY: "Um, not too often."
AA: "Then what is the matter? Are you worried about the IP of
the engineering improvements you are making? Are you licensing
this differently?"
IY: "No, it's for the most part similar to core.cpuid and the
license will be also Boost."
AA: "Then what is the matter? Do you want me to wait until you
release a stable mir.cpuid and copy it over with credit, per
the Boost license, to core.cpuid_v2?"
IY: "..."
It's this kind of stuff I need to have a better understanding
of. Some technical arguments are meaningful, some others point
to problems with obvious solutions that are somehow shunned,
and yet others are like a hidden Markov model - I see the
effects, but I don't see the causes.
Andrei
I think, the reason of misunderstanding is different skills in a
subject. And even different subjects. Some experts are compilers
developers, some are library developers. They all in different
subject. In c++ community there is a group of compiler developers
experts who desides, how to implement this or that feature, and
the ability of implementation. They know how to develop
compilers. It doesn't mean they are more clever than library
developers, just different skills. And when Andrei asking to
explain the reason of some proposal, he waits arguments in
_terminology_ of comliler developer. _terminology_ understanding
(in wide) means _experience_ (compiler developing in this case).
If no experience in the subject, there is a way to get it, and
the other way to ask a recommendation of experienced colleague.
