[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift]

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).


>
>
>> - 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?


>
> - 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170802/9b52a2ea/attachment.html>