First off: Interesting thoughts! I couldn't agree more about the importance to make things easy to build. I'm not sure i agree about C++ and C applications being particularly easy to build though. Personally i have not seen any particular correlation with any language, but have too small of a sample size to say anything definitive. Would make for an interesting deep dive though.

>To each is own: I care about well tested, usability, and depending on the intended use, performance. I also care a lot about proper exhaustive documentation, which is missing from your list and from most programming languages projects.

~But I don't give a damn about its design and architecture, what matters to me is the external features, not the internals. Language designers care way too much about the internals and neglect the outside, which is what matters to the end user. I don't care if it make your parser more complicated, it if makes your grammar irregular, if you need more passes, if you need to dirty your hands with context; I want that source code using your language flows, for writing and for reading.

I think there's a disconnect here between good design and architecture and the result of it. You can't by definition have a good design and architecture that makes your program difficult to use and illogical externally. You can't have good tests without a good design and architecture. Good design and architecture goes hand in hand with usability too.

To go into a deep dive is beyond the scope here. But concisely said, good designs and architectures makes the software easy to understand and easy to change to external changes of requirements. Since its easy to reason about it's also easy to understand and reason about bugs when they inevitably shows up. If the software does not have these features, it does not have a good designs and architecture. You might think a certain architect cares more about the internals then the external, but then the architect is bad, and should study and should step back a step and think about the end user and heading of the software project. Or perhaps there's a communication issue going on, human <-> human style.

Good designs and architectures also is the equivalent, actually superior to, having good documentation. Documentation that defines the external goals are not required if you have good tests that shows them. Hell documentation about the code is not needed if the design and architecture is good. And the self documenting code can never lie. Is it difficult to achieve? Yes. But not trying will put you into a corner you can't get out of and inevitably lead to the rewrite-from-scratch. Unless of course you have a very strictly defined end goal and complete definition of done, but you could still paint yourself into a very difficult corner to get out of.

>Community? I don't really care, and I have seen it being detrimental to many projects, which lose their compass by wanting to incorporate every feature request and following the mood of the year; I'd rather they were developed between closed doors and only published when they reach beta status, to maintain consistency, instead of jumping from an unpolished feature to the next. I am aware that's totally against the current trend, where people publish repositories with a README.md before writing the first line of code or documentation :-)

Not sure i see the correlation between pushing readmes with intent and publishing unfinished feature upon unfinished feature. Isn't readme:s infact documentation? Well well :p i believe you can work in the open without jumping to unfinished feature to unfinished feature. Polish can come in the middle of a development cycle, not just the end. A vibrant community around a software also is equivalent with many contributors etc, which makes the software resilient to people moving to other things etc.

I might have sounded critical, but enjoyed reading your response. Thank you for your response :) I also believe you gave me clues to why the "written in" header is so popular.

The way you interpret certain values i gave was also insightful. I certainly don't have the same opinions, but non the less i can see where you come from. So i just had to respond to it :) Thank you!