[swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma]

On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer <felix91gr at gmail.com> wrote:

>
> On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma <kelvin13ma at gmail.com> wrote:
>
>> On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Hmm. I kind of like the idea, but not really. I think it has a
>>> fundamental flaw: centralization.
>>>
>>> You see, the StdLib can be commanded by a central authority (the core
>>> team) and hear the needs of the general community (through swift-evolution
>>> and such) because, among other things, it’s small. The StdLib solves common
>>> and well-understood problems. Most of the solutions it provides are optimal
>>> for all use cases.
>>>
>>> This is fundamentally different from a non-StdLib. If I understood your
>>> idea correctly, it would be the complement of StdLib; it will be big and it
>>> will attend problems that are not well-understood or whose solutions have
>>> many differrying  approaches depending on the users’ neccessities (think
>>> Geometry). Therefore, a correct and complete approach would inevitably have
>>> to:
>>> - Know the needs of all the relevant user groups and balance their
>>> priorities.
>>> - Contain all the important and complementary solutions.
>>>
>>> This is very hard to achieve in a centralized system. Not impossible,
>>> but very resource-intensive.
>>>
>>> You can achieve something similar by letting the community grow and by
>>> encouraging a good environment. People will the build the tools they need,
>>> and the important voices will index the tools people use the most. That
>>> makes them good, as well as easily findable. It’s not perfect either, but
>>> it’s more efficient in my opinion.
>>>
>>> — Félix Fischer
>>>
>>
>> People tend to build the tools they need, but not what other people need.
>>
>
> Fair point. Dog-feeding might be an issue, but not necessarily.
>
> And there are many many examples from other languages of what can go wrong
>> when non-standard libraries compete.
>>
>
> Hmm. Okay, yes. But what about healthy competition? Isn’t that good as
> well? In which context you get bad results? Can you change the system s.t.
> you encourage good competition?
>

i think in open source, competition is mostly beneficial when you have one
old monopoly that’s become lethargic and a new more energetic project
upends it, i.e. gcc vs clang. You get a new improved tool, and the old
project also gets a wakeup call, which is why you’ve seen such a big
improvement in recent versions of gcc. Where there is no such incumbent,
and everyone is starting from scratch, it becomes counterproductive.


>
> As for important voices indexing the tools people use the most, I don’t
>> see that happening.
>>
>
> This is easier than it seems. The Compatibility Suite is already an index
> of important libraries.
>
> Regarding the other problems I see with this proposal: how will you attend
> the necessities of so many diverse groups? You’d need a whole...
> consortium, of sorts. You can’t have just a leader: no one knows the
> context of all the users.
>
>
The Compatibility Suite suffers from licensing issues which prevents a lot
of important libraries from being listed in it. GPL libraries are
effectively excluded from it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171107/de200af2/attachment.html>