[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Wed Aug 2 21:55:35 CDT 2017

Swift Breeze *was* on Github <https://github.com/swift-breeze>,, i don’t
know whose argument that strengthens here :)

Here was the original thread
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008134.html>
it was introduced in. It got a lot of attention and +1’s but never
attracted much involvement, possibly because the Swift FOSS community was
much smaller back then, possibly because people on mailing lists are by
nature all-talk, no-action. I’m also a library author so I understand the
reluctance to give up your children to a collective repo lol.

On Wed, Aug 2, 2017 at 10:47 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

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