[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift]

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/20170802/c29db610/attachment.html>