Trying to gather together a bunch of unpaid people won’t automatically solve the problem. (We *can* agree that there *is* a problem, yes?) I think Swift Breeze demonstrated that. (Incidentally, throwing a bunch of money at the problem won’t automatically solve it either — look at the US government.) But then again, it can still *help*, and while it sounds cheesy, *how much* it can help depends entirely on the attitude of the contributors; whether they see themselves as solo authors listed on a package index, or as part of a bigger effort. I’m not really a fan of waiting for Apple to save the day. One of the things I’ve argued for that *can* be done without Apple’s help is setting up another Swift library incubator like Breeze. Obviously it won’t magically lead to a Swift math library but it does remove some of the obstacles I mentioned earlier:
- it links together disparate solo projects and provides discoverability to users - it provides a package index and serves as a dashboard to check up on the “state of Swift library support” - it gives a venue for interested people to discuss the general topic of library support - it helps network people who are working on similar things (a “soft factor” but important!) tldr; self-organization isn’t a panacea, but it helps. On Wed, Aug 2, 2017 at 10:14 PM, Xiaodi Wu <[email protected]> wrote: > 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
