> Sorry, but that makes zero sense. Well, I hate to break it to you, but I've been using Python in large production environments for nearly a quarter of a cent

> Sorry, but that makes zero sense. Well, I hate to break it to you, but I've been using Python in large production environments for nearly a quarter of a century now and either I'm just extraordinarily lucky, or it does in fact make quite a bit of sense and really does work quite well. :) Here's one example: we once had an enterprise Java system of roughly 1 million lines of code. For a number of reasons the whole thing got replaced by a port of it to Python, and the Python version weighed in at just over 100kLOC. Disregarding all of the other benefits (which were many), there were meaningful advantages to maintaining a codebase 1/10th the size. > Dynamic typing is a language design choice where one is trading off automated error detection for faster development. No, not at all. First of all, if you are dealing with any sort of production code, you have to be investing in good testing. The idea of dynamic languages hiding bugs that don't show up into production is mostly a bogeyman to cover inadequate testing. We've also found that languages like Python tend to encourage a style of iterative development that lends itself to each section of code being very well tested as it gets written, so in the end it's easy to wind up with code that is both tested more during the dev process but then also well-tested due to the automated tests that all software should end up having anyway. I mean, all software gets tested, it's just a question of whether you do it or your customers do it. (anecdotally we've seen evidence that people come to over-rely on compile time error checking in lieu of good iterative testing, and that's an interesting topic in and of itself, but beyond the scope of this discussion and IMO falls under the 'sloppy developer' umbrella anyway) > The larger and more complex a project becomes, the more moving parts and interfaces (APIs) it has The implicit argument here is based mainly on the assumption of lots of (even exponential) growth in coupling as a project grows, and the reality is that, the level of coupling tends to go in the opposite direction as projects grow large, unless it's simply poorly architected. For example, instead of intercommunication between modules, you're dealing with intercommunication between entire systems - the points of contact between systems tends to be over very well-defined interfaces and are small in number relative to the amount of communication internally between modules. > initial coding effort is only a small part of the lifetime project costs, and optimizing this at the expense of ease of maintenance is a poor decision Speed of initial implementation is certainly one benefit, but it actually pays dividends over the lifetime of the project. Code is read more than it is written, so having fewer lines of code, in a language that is easy to read, in a language that removes so much of the noise associated with more verbose languages, is always helpful. It helps you implement stuff to begin with, it helps you add new features later, and it helps you fix bugs. There are also lots of second-order advantages too, such as making it easier to bring new hires up to speed and needing fewer people both initially and long term. It's about a lot more than just dynamic typing though; a higher level language just provides a ton of benefits that are often worth the tradeoffs. There are so many parallels to e.g. when we moved from assembly to C. > If you anticipate sloppy undisciplined programmers working on a project That point was just that so many knocks against certain things are actually covering the problem of sloppy developers. Rather than just take them for a given, a better approach is to set them on a path to improvement if they are willing, or let them go if they are not.