That's not what I'm saying at all. I'm responding to your contention that no library without "backing" will see wide adoption: if, as you say, you would like to have a math library with sufficient "backing," then realize that you're arguing for someone to devote financial resources to the problem. Your proposed solution of getting together a bunch of unpaid people does not address your identified problem. On Wed, Aug 2, 2017 at 21:07 Taylor Swift <[email protected]> wrote:
> > > On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu <[email protected]> wrote: > >> On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift <[email protected]> >> wrote: >> >>> >>> >>> 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). >>> >> >> I believe there has been mention on this list that the core team would >> like to revisit this idea at some point. >> >> >>> >>>> >>>>> - 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? >>> >> >> https://gist.github.com/xwu/d68baefaae9e9291d2e65bd12ad51be2 >> >> >>>> - 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.) >>> >> >> Well, hang on now. There are plenty of products put out by even major >> organizations that are unceremoniously and abruptly cut. There are plenty >> of projects worked on by one or a few major people that are long-lived. >> Projects that have longevity have some sort of financially sensible model >> for their continued existence. Three, thirty, or even 300 unpaid people >> working on an open-source project won't make it much more reliable (in the >> eyes of others) than one unpaid person, and again I disagree that the >> veneer of an organization is superior to presenting the status of the >> project honestly. (Example--what is commonly thought to be a bigger threat >> to Firefox's continued health: the possibility that there will be a >> shortfall in unpaid contributors, or the possibility that there will be a >> shortfall in funding?) >> >> Rounding up all the goodwill on this list will not do you any good if >> your goal is to convince users that a certain project will be maintained >> into the future--because it won't rustle up a single dime. Whether or not >> you explicitly equate these in your mind, "backing" == money, and if you >> want this point addressed, you're claiming that someone somewhere should be >> spending money on a Swift math library. I'm personally committed to making >> sure that my code will work for the foreseeable future, but I fully accept >> that there's simply no way for me to convince a sufficient number of people >> of this fact without a credible showing of funding. In that sense, a >> community initiative with "momentum" is decidedly not going to be a >> just-as-good alternative to a core library. >> >> > Well that there is a rather defeatist attitude. If you are correct that > Apple-funded development is the only way to get core libraries built (and > maintained), and Apple has expressed they have no intention of doing so, > then we are all pretty much f****d. >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
