I see! Seems like neither formatter is completely rigid, and both respect some style decisions made by the programmer, so this level of automated reformatting isn't possible.
ThePhD is project editor for WG14, the C language standards committee. The other poster is probably referring to them as "the sheep dev" because ThePhD is prolific on GitHub and have an anthropomorphic sheep as their profile image.
I like it a lot even though almost all of my functions have no dispatch (only one implementation) or single dispatch (implementation differs based on the type of just one of the arguments).
Firstly I like the aesthetic and implications of f(x, y, z) over x.f(y, z). I like that f is its own thing and not a property of x.
Secondly, it's really nice to be able to reach however far down the callstack you need to go to patch some function "owned" by someone else to act correctly or more efficiently with whatever your type is. You can get correct code most of the time with single dispatch and well-thought-out interfaces, but getting interfaces right in advance is really tricky and requires coordination with other users of the interface whereas multiple dispatch can often work well without much coordination and can also handle cases where you want the implementation to vary dramatically based on the type (the OneHotVector in Karpinski's "Unreasonable effectiveness of multiple dispatch" talk is an example of this).
Fundraising and publishing are specialised skills that artists don't necessarily have. Also, lots of people, including many artists, like the stability of a steady pay check and employment rights, which means companies or co-ops.
The sci-fi author Charlie Stross has a series of blog posts on their site about all the work that goes into publishing a book and how much of it is done by employees of the publisher (and how that is not work that Stross can do / would like to do).
So? You don't think crowdfunding campaigns can be managed by third parties? You think how the artists gets the funds is intrinsically tied to what parts of the work they can or cannot outsource?
> Also, lots of people, including many artists, like the stability of a steady pay check
I'm sure many plumbers would like recurring royalties from their work too. That doesn't mean that that is a good way for society to function. Any discussion of copyright that just looks at the needs of the creators without considering the effects on everyone else is fundamentally flawed.
It's correct if you want to do something `length(A)` times and want an iteration counter, but it's never better than `for idx in eachindex(A)` if what you actually want are indexes into A (which is of course the much more common case).
Julia did not initially support arrays that aren't indexed from 1 (experimental support added in Julia 0.5, I don't know when it was finalised), and at that time I'm not even sure we had something like eachindex, certainly there would be no reason why someone would use it for an array.
Julia released experimental support for arrays whose indexes don't start at 1 in Julia 0.5, October 2016.
The boundschecking feature was added in 2015, so at the time they wrote their code and examples, they were correct.
The documentation and review happened in December and January 2016/2017 when the non 1-based indexing was still experimental and very new, so I don't think this is as big a fail as you've made out either.
Yes, the documentation should have been updated when non-standard indexing was made non-experimental, and the reviewers should maybe have noted the new and experimental array indexing stuff, but it's only natural to miss some things.
That's fair enough! I was unaware of that history. But my point wasn't that the issue was "a big fail", it's that the GP was unfair in assigning the responsibility of that failure to "some newcomers [who] write code (and documentation) with this" while "the people who really know to handle these cases" are fine. The responsibility should have been on the people pushing for the experimental array indexing code to make it work safely with the existing usage of boundschecks that existed in the ecosystem and the existing documentation. It's a fundamental disagreement between whether the onus of code safety is on the user (who is responsible for understanding the totality of the libraries they're using and all of the ways they can fail) or on the programming language (for ensuring the stability and correctness of its code, documentation and ecosystem when making changes).
I don't think there's any clean way to stop that at a language level (some languages prevent this by disallowing random access to arrays, but that's a non-starter for a performance-oriented language), and also it would be a massively breaking change.
