On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer <felix9...@gmail.com> wrote:
> > On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma <kelvin1...@gmail.com> wrote: > >> On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution < >> swift-evolution@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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution