14 September 2013

"I will never use Python in production ever again"

This quote is from an engineer I respect very much. The reasoning behind it was they hit a few SyntaxError and AttributeError exceptions in their production jobs and had to do a whole new release to fix it, which took a lot of time. The same engineer followed that story by saying that Python is also slow, so to them, overall, Python totally isn't worth using ever again.

The same criticism could be applied to Ruby, JavaScript, etc. There are many things wrong with this outlook. Here's my belated reply:

1. Why didn't you have tests that caught the syntax errors? Static typing doesn't ensure correctness for languages like C++ and Java. You should always test your code! Say you implement the same functionality in Python and C++, respectively, and the same tests. All other things being equal, I expect the total time spent in Python will be lower than C++. The whole point of using a dynamic language is to boost your productivity as a programmer for equivalent work. But you must always write the tests!

2. Why did your release take so much time? Everyone has hit an exception or crashing bug in production. Fast deployment is crucial for fixing these, continuous deployment is even better. With frequent, smaller releases to production the risk introduced by each release is lower, the cost of fixing bugs in each release is lower, and this lower risk compensates for pushing "fresh" code all the time. So who cares if you have a SyntaxError? Pushing should take minutes, not days.

3. If Python is slow for your problem why are you using it? By using dynamic languages you are trading program execution time for project execution time. The code will take less time to write but will also be slower (or take more resources) when it runs. That's okay, because the vast majority of the time I find it's fast enough. When Python will be too slow, I find another tool that fits the use-case (C++, Java, R). No tool is a panacea. You should choose Python when it makes sense to use it.


Conclusion

Like any tool, Python is great for what it's good at, which is many things. The APIs Python enables are wonderful. For what Python can't do well it works great for a prototype, but long-term you may find the need to switch to something else. That's fine! The constant lesson is always use the right tool for the job you're facing. In my experience, all things being equal, I find that Python* lets me focus on making my project successful by delivering functionality to users sooner. That's what's important to me.

Finally: What's really interesting in this whole consideration is Go. Go is the closest I've felt to Python with a static language in terms of productivity, and I don't even know Go very well. I look forward to using Go more and seeing when it can replace Python for my needs.


* This applies to any dynamic language, really. Advocating for Python specifically isn't my goal.

Follow-up

Comment with Open ID

Comment with Google+

© 2009-2014 Brett Slatkin