> 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.
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.
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:
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.
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.
> 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.
That might be true for complicated stuff — but it took me some time to come up
with examples for this category…
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?
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:
- 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.
- 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.
- Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
