[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Xiaodi Wu]

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 <kelvin13ma at gmail.com> wrote:

>
>
> On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift <kelvin13ma at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>>> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift <kelvin13ma at gmail.com>
>>>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/5773a0cb/attachment.html>