I think you might be conflating good general software engineering practices with language choice. Remember that the current dominant social network of our time (Instagram) built and scaled just fine off of Django + Postgres and a relatively small engineering team -- you can write poor code in Python just like you can in Java, and you can write good code in either one.
Ouch, those are the arguments people usually bring forward to defend PHP – strange to hear them applied to Python. While I agree that good software engineering practices makes the real difference, it's not the only thing that matters.
There are better languages and worse languages. While you can apply good practices and successfully build good stuff using a language designed in 10 days (or a language that evolved accidentally from a templating system), those practices will have to work a lot harder than they would if you had used a better language.
Python has a split user base, where roughly half consists of data scientists who use it by necessity and might not always apply software engineering best practices, but many people in the other half use it by choice because it's a nice language.
Well, are you trying to say that PHP is impossible to use properly? It's not exactly the first tool I'd look for, but it's clearly possible to use at scale if we look at what Facebook did with it.
I have to completely disagree with you. There is no such thing as better or worse languages in a vacuum. Languages exist in an ecosystem that you use to build things using them. Most best practices you apply as a software engineer are reasonably language agnostic. On the other hand, tooling, libraries, frameworks -- many of these things cannot easily ported over from one language to another, and moreover have taken many billions of dollars or man hours of effort from many people before us to get to where they are.
For what it's worth, you don't really make any arguments as to what makes a language better or worse, and you don't really make any arguments that "those practices will have to work a lot harder than they would if you had used a better language" -- for whom? I have worked with hundreds of talented engineers in my life building codebases that have lasted the test of time and I have never once ran into one who had difficulty making a quality codebase using whatever language they ran into.
Blaming a language for poor code is a crutch, and drawing a correlation between code quality and language is dubious. Which more likely has an outsize effect on codebase quality, that the organization that wrote the code, or the language itself? I'll go for humans as the weak link every time.
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?
