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

[Wallacy]

The Compatibility Suite is a good start, but I agree that something a bit
more centralized has its benefits.

To be perfect, Compatibility Suite and Swift Package Manager need to work
"together" to offer something simple like nodejs npm and a friendly (and
central) interface to not only find these projects. Something more similar
to nuget too.

The only thing I miss using npm and nuget is some kind of "compromise" with
maintenance. And also some commitment to (avoid) rework. Several projects
remake something that another does also without explaining well the
differences between them.

Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
project like Compatibility Suite with steroids. Not only to track those
projects, but in some level help defining some standards, documentations,
versioning etc. This can be done entirely within the community.

Not so similar, however the gstreamer keeps a list of "base", "good",
"ugly" and "bad" plugins for similar reasons.

We can do something in this line of reasoning:
- A central repository for projects (like Compatibility Suite)
- A tool to find and add each project (like SwiftPM)
- Rules for joining (like Compatibility Suite)
- A classification for each repository (like gstreamer)
- A good way to make each project as small and direct as possible (to take
advantage of cross-module inlining / specialization)
- A list of discussion (or a forum?) for people that maintain (or have an
interest in maintain) projects in this "official" list.

I vote for empowering SwiftPM and Compatibility Suite instead a
"Non-Standard Libraries".



Em ter, 7 de nov de 2017 às 17:19, Kelvin Ma via swift-evolution <
swift-evolution at swift.org> escreveu:

>
>
> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171107/2ca2b119/attachment.html>