[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Wed Aug 2 21:47:29 CDT 2017

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 <kelvin13ma at gmail.com> 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 <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/20170803/f6764aca/attachment.html>