A betterC modular standard library?

[Andrey via Digitalmars-d]

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.