[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Wed Aug 2 21:58:17 CDT 2017

On Wed, Aug 2, 2017 at 21:55 Taylor Swift <kelvin13ma at gmail.com> wrote:

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

No, no, I mean, doesn't GitHub itself fit the roles you defined earlier?
And by implication, why would a project on GitHub do any better than GitHub
itself at being a collection of repositories and at facilitating
collaboration?

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/20170803/ced6b46f/attachment.html>