Again, were it up to me, I would have closed this, as it is a debate not a discussion. But given the debate continues, I must continue making my case.
Elixir lacks order in that there is no objective criterion for what does or doesn’t go in the core.
The Elixir team focuses on language features that:
- are necessary for developing the language itself
- bring important concepts/features to the community in a way its effect can only be maximized or leveraged by making it part of the language
These are heuristics. The core team determines what belongs and what doesn’t. Extensibility can be cited to avoid going in one direction while reason #2 can be cited to do so.
The problem, from an open-source standpoint, is that there is no system to consider new ideas (in my experience, just hostility). As a result, might is “right”.
I mean, so be it–Valim has done a generally great job.
It’s just frustrating…
I’ve already made the distinctions in my article from an organizational standpoint.
In terms of documentation, currently functions are arbitrarily put in alphabetical order. Again, I’ve already written this before, but just for visibility–the benefit is ordering is predictable; the downside is it is cluttered. Were an additional level of granularity to be added (like how modules themselves aren’t ordered completely alphabetically, but rather alphabetically within logically arranged groups–or like in Kernel where there is a second dropdown for guards), that would provide users the best of both worlds.
Last, in my experience, the codebase itself in certain places could be refactored for concision and clarity. Part of this is the scope of my article, and the other part is an experience I had trying to contribute to :ex_doc which isn’t part of the core.
