Having worked on corporate Python platform with tens of thousands of developers and thousands of applications running on thousands of instances on millions of lines common core code base, I beg to differ.

It is easy to ship any proof of concept. Is it hard to maintain, it is rigged with performance issues and it is almost impossible to refactor because python has zero refactoring support and no compiler to help you catch any error.

What you save on the initial rollout, you loose ten folds on the long term.

But that is basically the point of the whole article and this thread, that it's great for proof of concept that morphs into production when needed. If you can deploy in one day that means you can test 5 ideas/week until one catches on (hopefully not that long). Once one catches on, you can actually put more effort into it and optimize it as needed and not the other way around.

You can't try 5 products or features a week on real users. They don't keep up.

Facebook deploys thousands a week:

https://swreflections.blogspot.com/2013/09/this-is-how-faceb...

If you're looking to Facebook for your user experience guidelines, you're going to end up angering a lot of actual users.

While making millions to billions dominating a market I own. So, sure. Other circumstances it would just teach you can experiment more than a few things a week.

Facebook have thousands of products and billions of users. You do not ;)

Now that's a better point. Obviously, the amount of changes are tied to company's circumstances.

> We were sometimes able to go from concept to deployed application in a single day.

This just makes me shudder a little bit. I've seen such things before, even recently at my current job. These kinds of applications tend to be a nightmarish mix of unmaintainably overengineered and underdesigned terrible code.

It's not ideal certainly, most such cases would be either a variation of an existing application or something that isn't business facing such as a compliance or operational metrics report.

The key thing is that the testing, release and deployment tooling were not a significant bottleneck. You could develop the code, perform testing in a production like environment and sign it off with a minimum of down time in between waiting for compilation, package building, etc. So a lot of that was down to Python being interpreted.