> The degree to which people are skeptical of markets and a market value associated with their actions is so immense
Similarly, the degree to which market advocates, themselves, exhibit skepticism about the market mechanism vis-a-vis their own intellectual products is so immense, in fact, that the idea that ideas achieving widespread adoption within the marketplace of ideas do, indeed, have vastly greater value than those with inferior adoption is simply met with comparably-inarticulate derision.
Ideas aren't a great place to push free market ideals; especially because so many ideas are basically anti-freedom and anti-market. How often does anyone come up with "let people sort it out themselves, bearing the costs and consequences" as a new idea? When it is suggested it is rare to see someone championing it with enthusiasm and to wide acclaim. Compare that to the "Lets order people to [activity]" style ideas that are common and suggested in many forms.
Using market forces to measure the value of an idea is not clever. Ideas that are to be put into practice should be assessed primarily by whether they are grounded in evidence or not, and secondarily by whether people are willing to cope with the consequences of the idea going wrong.
An idea being popular or gaining popularity does not make it a valuable idea (or indeed a good idea). That stands in stark contrast to economic forces which measure resource creation and destruction with a cruel accuracy.
The Aspen Summit a few years ago had a forum where someone pushed for major news outlets to promote more intellectual, nuanced content, and one rep from a major network pushed back. They pointed out that the consumer of that sort of content is going to the ballet, or trying the new restaurant by some named chef, or attending the Aspen Summit, not staying at home watching 24-hour news. That sophisticated audience is out doing interesting things, they might watch occasionally, but aren't a consistent enough news audience to shape content. "We run the market test against PBS every night."
Best thing I can imagine is that policy wonks writing in low subscription specialty journals are a bit like arthouse films. Sure, the indie films lose in the market to blockbusters, and wonky policy journals don't get a tiny fraction of the eyeballs of 24 hour news. But it's more likely for important new ideas to be born in the niche, experimental market than vice versa. They're losing the market test, but contributing a lot of positive externalities by influencing the influencers, they're just not able to capture all those returns.
Curious if you ever benchmarked your approach vs, say, going through `Array`/`ContiguousArray` (I think these are slated to converge eventually, FWIW) and using the [`withUnsafeMutableBufferPointer(_:)`](https://developer.apple.com/documentation/swift/array/299477... calls?
You've gotten into a place with a lot of unidiomatic designs--direct pointer access on COW types, etc.--and it's not clear how much is really necessary:
extension Array where Element:CanDoMath {
// instead of this style:
func sum_outside() -> Element {
var result = 0
let p = self.pointerToStorage // your "get the pointer" method, I think it was just `p`, too?
for i in 0..<count {
result += p[i]
}
return result
}
// how does this compare (in -unchecked mode, at least)?
func sum_inside() -> Element {
return self.withUnsafeBufferPointer() {
var result = 0
for v in $0 {
result += v
}
return result
}
}
}
Going the `sum_inside` route for bulk operations makes it easier to remain idiomatic, keep COW around (assuming you want it), benefit from `var/let`, and so on. The only obvious concerns are (a) relative overhead--did you ever benchmark that?--and (b) alignment.
For (b) if you're planning to call things that need particular alignments then as far as I know you will need to write your own storage at this time.
What I'm doing is essentially the same as `withUnsafeMutableBufferPointer`. However I didn't find a way to get concise abstractions using that approach.
It is essentially the same, sure. We have some specialized in-house structs-of-arrays things for doing bulk geometry operations that (behind the scenes) go through `withUnsafeMutableBufferPointer` (etc.) for everything; we keep the code idiomatic, mutation only happens in methods that are marked as mutating, COW still works, and so on.
Thus we hadn't even considered just exposing the pointer and doing it C-style, whence the question as to whether you'd benchmarked the difference between the two.
The abstractions thing is hard, here, the key seems to be defining the bulk operations in terms of pointers (or Swift's "buffer pointers"), essentially what you have in your methods like `SupportsBasicMath.add` and so on. Abstraction is possible here by moving each "type signature"--destination & 1 source? destination & 2 sources? etc.--into "operation protocols", and then having fewer methods but a ton of "operation protocol implementations". Perhaps "more abstraction", definitely not concise. Very dependent on the compiler and inlining, too.
It's a good writeup nonetheless, was just asking a narrow question.
The pointer approach allows for brevity and idiomatic swift at the place of use. The verbosity behind the scenes need not bother the user.
Because I couldn't find anything that provides that using the approach you are discussing, I didn't investigate its performance characteristics. For me, dev UX comes first, and I wouldn't personally be interested in reading or writing in a language that requires the "with" construct wrapping every calculation.
Similarly, the degree to which market advocates, themselves, exhibit skepticism about the market mechanism vis-a-vis their own intellectual products is so immense, in fact, that the idea that ideas achieving widespread adoption within the marketplace of ideas do, indeed, have vastly greater value than those with inferior adoption is simply met with comparably-inarticulate derision.