
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The other point I'd make here is that I definitely think the core team is right about encouraging any "entire API spec" for a math library to be based on implementation experience from actually writing a math library that has seen good adoption. Essentially, what they're saying is that any proposed design here should have already proved itself in the field.</span></div></blockquote><div>The things that are imho the most important to have don't need to be designed anymore — we only need to agree on a specific implementation.</div><div>A quick search for "Result Swift" on github yields 80 projects. I haven't looked at all of those, but I would be very surprised if the majority isn't more or less identical:</div><div>Names might be not all exactly the same, and some features won't exist everywhere… but I don't think it is a good idea to wait another two years to see if one of the implementations won the competition.</div><div>And even if one solution emerges to be the most popular: I bet it won't be because its quality, but some sort of marketing instead.</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I assume that you are well aware of Conway's law, which afaict has good evidence to back it up; with that in mind, the end product that emerges from a draft spec and an empty open-source repo is unlikely to be satisfactory, let alone optimal.</span><br class="Apple-interchange-newline"></div></blockquote></div><div class="">That might be true for complicated stuff — but it took me some time to come up with examples for this category…</div><div class=""><br class=""></div><div class="">But there are at least three(!) implementations of quaternions in Apple libraries, and for this stupid reason, you can't directly take the data from the iPhones sensors and animate an object in scene kit with it. Is this satisfactory?</div><div class=""><br class=""></div><div class="">Imho it's not important for those missing "standard" libraries to have state of the art implementations for all established algorithms; it's much more valuable to agree on basics that are adopted by other libraries:</div><div class="">- I don't expect that Swift's dictionaries are optimal, but that isn't nearly as important as the fact that they are compatible with NSDictionary — or just imagine each library had it's own implementation of Array; it would be terrible, and a giant blocker for the adoption of Swift.</div><div class="">- A standard library for directed graphs doesn't need to have a version of A* or Dijkstras algorithm — it would already be a big step forward to declare the basic data structure, so that my variant of A* is compatible with someone else's graph visualisation toolkit.</div><div class=""><br class=""></div><div class="">- Tino</div></body></html>