On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu <[email protected]> wrote:
> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <[email protected]> wrote: > >> See, my problem with statements like this one, is that the answer “should >> be supported as a third-party library” can also be interpreted as “not my >> problem, go figure it out yourselves”. The idea that central entity can >> only pay attention to what they want to, and the Community™ will magically >> take care of the rest is one of the most pervasive, and untrue, myths about >> open source. What’s worse, is that Swift has the benefit of hindsight, in >> the form of many, many examples of languages that came before and fell >> victim to this fallacy, and now have 15 competing “private” classes for >> basic mathematical objects like *vectors*. >> >> I agree that a core math library, for example, *could* in theory be >> supported as a third-party library. >> > > The core team has said that they're open to a core math library being part > of the Swift open source project; they just outlined that the _process_ for > doing so is best initiated with a third-party library as a starting point. > > >> But this will never happen on its own, for reasons that I will reiterate >> here: >> >> - no one influential enough has bothered to jump start any such project >> > > Karoly Lorentey has a wonderful, and quite mature, BigInt project: < > https://github.com/lorentey/BigInt>. Also, as I mentioned, I just started > a project for protocol-based additions to Swift's basic numeric > types. These are just two examples. > > >> - there are no avenues to encourage members of the community to come >> together and organize a project (look how this thread got derailed!) >> > > You're welcome to join me in my endeavor to create a math library. I'd bet > Karoly feels the same way about his project. > You don’t know how happy reading that sentence just made me, i’d assumed no one was willing to team up to build such a thing. In which case, it’s a good idea to start an incubator organization on Github. I think David Turnbull tried doing that 2 years ago, I’ll reach out to him if he wants to be a part of something like this. We should also maintain an index of promising pure swift libraries so they are discoverable (like docs.rs does for Rust). > > >> - there is no “soft” infrastructure in place to support such >> collaboration (look at the fuss over discourse and mailing list spam!) >> > > The GitHub environment has excellent tools to support such collaboration, > IMO. For example: > > Based on my experience implementing a library, I wrote a Gist to outline > some lessons learned and suggestions for improvement. Not only did the > document find an audience, these suggestions were in turn used to inform > core team-driven revisions to the integer protocols. As a result of these > revisions, it became possible to implement some initializers that could be > useful for people writing generic numeric algorithms. Recently, I submitted > a PR to the Swift project on GitHub to implement these initializers. Now, > everyone will be able to use them. Collaboration, positive feedback loop, > win-win for all involved. > > Likewise, Karoly used his experience updating BigInt for Swift 4 to inform > certain improvements to the integer protocols. He implemented these > improvements in a series of PRs. Now, as a result of these developments, > Karoly's library will be better designed *and* everyone else will benefit > from a better implementation of the integer protocols. Again, > collaboration, positive feedback loop, win-win for all involved. > Great!! can you link me to the gist? > > - there are no positive feedback loops whereby a promising project can >> gain market share and mature >> - because there is no organization backing these projects, potential >> users are reluctant to depend on these libraries, since they will logically >> bet that the library is more likely to fall out of maintenance than reach >> maturity. >> > > Addressing this point is clearly impossible. When Apple wishes to commit > its own resources to the maintenance of a Swift math library, > swift-corelibs-math will appear on GitHub. Suggestions such as opening an > empty repo and letting people contribute to it would either give the > illusion of organizational backing that doesn't exist or would in fact > commit Apple to support a repo that it doesn't wish to support. I fail to > see why the former is good for anybody; in fact, it's strictly inferior to > the same repo honestly representing itself as a third-party effort. And > asking for the latter is essentially asking Apple to create a Swift math > library--which, again, is not in the cards. > My point wasn’t really to exhort Apple to create a Swift math library, just that people are more willing to depend on a library if the library’s bus factor is greater than 1. A lot of great Swift packages in one one guy or girl’s github repository who later disappeared. Turnbull’s SGLOpenGL library is a good example of this; his library no longer compiles which motivated me to write swift-opengl <https://github.com/kelvin13/swift-opengl>. Then again, I’m sure people feel the same way about depending on swift-opengl today as I felt about depending on SGLOpenGL. There just has so be some semblance of organization. That organization doesn’t have to come from Apple or the swift core team. A community initiative with sufficient momentum would be just as good. (The problem of course is that it is rare for a community initiative to arise.)
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
