&gt; There are several recent examples where people have suggested such things<p>That&#x27;s great but amount to a couple of functions, the larger issues addressing more serious refactorings never get off the ground (Base contains multiple thousands of symbols (not even counting how in a multiple dispatch language one symbol can contain hundreds of definitions) common lisp, by all accounts a sprawling language with multiple dispatch, has 978).<p>&gt; I don&#x27;t understand what exactly the criticism is. At first I thought it was about, too much dicussion, but then it seemed to be about too little dev time, please do clarify.<p>Both. Neither. It&#x27;s about how there is unending discussion until a core dev just does it. This is not an efficient use of anyone&#x27;s time. Set the scope of an issue, discuss, decide on a course of action, layout issues. This allows a core dev to get their input in place, but then not have to actually wait for them to have the time to do the whole thing themselves.<p>&gt; There&#x27;s somewhat of a tooling problem here, since we can&#x27;t run the coverage tests on travis, so we don&#x27;t get them integrated in the GitHub UI, but people do look at them and add tests as appropriate.<p>The number seems to fluctuate randomly from 83% in January, to 11%, 45%, 65%, 75%, 11%, 81% now. Which is a net loss and wholly sporadic. How does anyone know what to write tests for when coverage bounces all over the place? Also what good are the tests if no one takes the time to use them anyway? You have tests but they seem pretty useless with how you are using them. I understand it&#x27;s a tooling issue, but a metric isn&#x27;t very good if no one is bothering to use it, why waste the time to not use it.<p>&gt; but I wouldn&#x27;t say that they are so on purpose<p>&quot;Look at the code and you&#x27;ll understand.&quot; is the jist of the documentation of a 10000+ SLOC base used at the heart of Julia. Sure I could read all that, but I&#x27;d rather have a bit of documentation. Also the tests for this amount to it&#x27;s examples.<p>&gt; not some sort of unwillingness to fix problems<p>I disagree on at least 1 of them. Typed exception handling was flat out rejected because it&#x27;s too much like Java by key devs; forget the fact everyone does it anyway using reflection. Interfaces and modules don&#x27;t seem to make any progress because of some people complaining about similar issues.<p>&gt; Putting together the road map of what goes into each release and prioritizing are very hard, because there&#x27;s just so much that could be worked on.<p>Then stop wasting dev time and work on the community policies that make it easier to retain devs.