Not impossible. Just that how well a language works for building things depends on at least three things: 1. The quality of your software engineering practices

Not impossible. Just that how well a language works for building things depends on at least three things: 1. The quality of your software engineering practices. 2. The quality of the programming language itself, i.e. how well it fulfils its purpose as a tool for allowing the programmer to express their intention through language. 3. The context – interoperability with particular libraries or existing code, availability of programmers and support resources, etc. affects which tools are good choices. In a particular situation, COBOL or VBA might be the best choice (3) even though they're not particularly great languages (2) and you will have to compensate by increased effort spent on good practices (1) to work around problems with the language. So what I was trying to say is simply that there is such as thing as better or worse when considering a tool in isolation. A hammer that failed QA and was later fished out of a lake with rotten handle could be used to great effect by a skilled craftsman, but it's still a bad hammer. For example, if Brendan Eich had six months instead of ten days to design JavaScript (ignoring the business realities of the time), with a few rounds of feedback, would it not potentially have been a better language? What if he only had one day – would the quality of the language be exactly the same?