<div dir="ltr">On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>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 <i>vectors</i>.<br><br></div>I agree that a core math library, for example, <i>could</i> in theory be supported as a third-party library.</div></div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>But this will never happen on its own, for reasons that I will reiterate here:<br><br></div>- no one influential enough has bothered to jump start any such project <br></div></div></div></div></blockquote><div><br></div><div>Karoly Lorentey has a wonderful, and quite mature, BigInt project: <<a href="https://github.com/lorentey/BigInt">https://github.com/lorentey/BigInt</a>>. Also, as I mentioned, I just started a project for protocol-based additions to Swift's basic numeric types. These are just two examples.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div></div><div>- there are no avenues to encourage members of the community to come together and organize a project (look how this thread got derailed!)<br></div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div></div>- there is no “soft” infrastructure in place to support such collaboration (look at the fuss over discourse and mailing list spam!)<br></div></div></div></blockquote><div><br></div><div>The GitHub environment has excellent tools to support such collaboration, IMO. For example:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div>- there are no positive feedback loops whereby a promising project can gain market share and mature<br></div><div>- 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.<br></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div>- everyone works on their own in-house “half-assed” implementation, and people are not encouraged to come together and pool resources so instead there is a lot of duplicated work</div></blockquote><div><br></div><div>The beauty of open source is that you're also welcome to fork my project instead of duplicating it from scratch; keep it licensed the same way and I can pick and choose what to upstream. That's pooling resources right there.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-"><div><div><div><div><div><div><div><div><div><div><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 2, 2017 at 6:42 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><br><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div><span style="font-size:12.800000190734863px"></span></div></div></blockquote></span><div class="gmail_quote"><span><div dir="auto">I agree that if this would require compiler support, then it needs to be part of the standard library. However, I don't see anything about what you describe that cannot be supported as a third-party library.</div></span><div><div class="gmail-m_-6131733793155462042h5"><br></div></div></div></div>
</blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></span></div>
</blockquote></div><br></div></div>