Well, cars are engineered to protect the occupants from trauma if they hit a brick wall at moderate speeds, but that isn't the same thing as optimizing them for

Well, cars are engineered to protect the occupants from trauma if they hit a brick wall at moderate speeds, but that isn't the same thing as optimizing them for hitting walls, so the analogy doesn't do anything for me. And likewise some software is big, period, regardless of the language used. The easiest way to measure the size of a piece of software in advance is to imagine the size of the test suite. I have a poorly thought-out idea about the minimal complexity of a software program being the complexity of the automated test suite that validates the program... Anyways, some software is bigger than other software, but again that doesn't necessarily mean that given a large test suite to be satisfied and anticipating a larger program or collection of programs you necessarily need to discard certain tools that work well for smaller programs. Steve Yegge made this point with a much more entertaining analogy: He talked about pushing dirt, which illustrated the fallacy with some tools that are espoused as being appropriate for large projects: namely that they are really good at solving the problems introduced by the tools themselves. http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht... My takeway from Steve's article was that if you avoided tools that introduce certain problems, you don't need other tools to solve those problems.