[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Wed Aug 2 21:42:48 CDT 2017

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 <xiaodi.wu at gmail.com> 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 <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/20170802/1cd22171/attachment-0001.html>