Swift Breeze *was* on Github <https://github.com/swift-breeze>,, i don’t know whose argument that strengthens here :)
Here was the original thread <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008134.html> it was introduced in. It got a lot of attention and +1’s but never attracted much involvement, possibly because the Swift FOSS community was much smaller back then, possibly because people on mailing lists are by nature all-talk, no-action. I’m also a library author so I understand the reluctance to give up your children to a collective repo lol. On Wed, Aug 2, 2017 at 10:47 PM, Xiaodi Wu <[email protected]> wrote: > Hmm, I'd never heard of Swift Breeze. Doesn't seem like it'd be a > successful model to follow. Is there a reason why GitHub itself doesn't > meet these criteria? > > > > On Wed, Aug 2, 2017 at 21:42 Taylor Swift <[email protected]> wrote: > >> 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
