Myths of Enterprise Python(paypal-engineering.com)
paypal-engineering.com
Myths of Enterprise Python
https://www.paypal-engineering.com/2014/12/10/10-myths-of-enterprise-python/
17 comments
I've been a python programmer for 10 years now and am a believer in #6.
numpy is not always the answer, and cython is its own hell.
numpy is not always the answer, and cython is its own hell.
> Our most common success story starts with a Java or C++ project slated to take a team of 3-5 developers somewhere between 2-6 months, and ends with a single motivated developer completing the project in 2-6 weeks (or hours, for that matter).
A story so common they did not feel the need to share it? Even taking the least ludicrous numbers I'm going to say this is entirely made up.
- 3 C++ devs, 40 hours a week for 2 months (8wks) = 960 hours
- 1 Python dev, 40 hours a week for 6 weeks = 240 hours
4x difference in productivity is not a language difference, it's a programmer skill difference.
And just for the sake of seeing the numbers:
- 5 C++ devs, 40 hours a week for 6 months (24 wks) = 4800 hours
- 1 Python dev, 40 hours a week for 2 weeks = 80 hours
= 60x productivity
No.
A story so common they did not feel the need to share it? Even taking the least ludicrous numbers I'm going to say this is entirely made up.
- 3 C++ devs, 40 hours a week for 2 months (8wks) = 960 hours
- 1 Python dev, 40 hours a week for 6 weeks = 240 hours
4x difference in productivity is not a language difference, it's a programmer skill difference.
And just for the sake of seeing the numbers:
- 5 C++ devs, 40 hours a week for 6 months (24 wks) = 4800 hours
- 1 Python dev, 40 hours a week for 2 weeks = 80 hours
= 60x productivity
No.
You're underestimating the amount of effort put into simplifying and clarifying implementations, APIs, and documentation.
This doesn't imply that preceding implementers are unskilled. Part of this improvement is hindsight, but a not-insignificant part is Python's flexibility.
I can vouch for the apparently unbelievable productivity gains but I'm just not sure how to prove them!
Edit: As for not sharing these gains -- that's part of the point of this post to the official PayPal engineering blog :)
This doesn't imply that preceding implementers are unskilled. Part of this improvement is hindsight, but a not-insignificant part is Python's flexibility.
I can vouch for the apparently unbelievable productivity gains but I'm just not sure how to prove them!
Edit: As for not sharing these gains -- that's part of the point of this post to the official PayPal engineering blog :)
I figured 2500 words was quite enough for an introductory post. It definitely has happened, multiple times, but the rather mundane specifics will have to wait til a future post :)
I would have to agree with you, choice of language does not give a 60x productivity gain.
However, it's not crazy to think that a really top notch engineer, who is an expert in Python, and who is operating on a much healthier and efficient team would give you a 60x improvement. Heck, 60x might be too low.
It's not a priori crazy to find a 60x productivity difference between two teams. What is the productivity improvement between one team who spends 1 year on a project and fails to deliver it, vs another team that delivers the project in 4 months? It's not 3x, because 3x better than nothing is still nothing. The second team is literally infinitely more productive.
However, it's not crazy to think that a really top notch engineer, who is an expert in Python, and who is operating on a much healthier and efficient team would give you a 60x improvement. Heck, 60x might be too low.
It's not a priori crazy to find a 60x productivity difference between two teams. What is the productivity improvement between one team who spends 1 year on a project and fails to deliver it, vs another team that delivers the project in 4 months? It's not 3x, because 3x better than nothing is still nothing. The second team is literally infinitely more productive.
Does anyone actually believe any of these "Myths?" #6 and #8 are the only ones that could even be remotely considered half-true.
I hear #9 a lot - Java programmers are thought of by management as a raw ingredient, like concrete, that can be ordered up and poured into a project. Python can be used effectively by anyone who really understands computers and software, but that understanding is less common, and the practitioners are more idiosyncratic.
edit for correctness.
edit for correctness.
Unfortunately, unequivocally, yes, there is so much misinformation. I definitely would not have spent so much time on citations, otherwise ;)
Tragically, yes. I've been in meetings where each of these is brought up as a concern of using Python over a more traditional language like C++ or Java.
This is kind of like debating with creationists -- yes, it is absurd and dumb that the discussion even needs to be had, but they must be challenged.
This is kind of like debating with creationists -- yes, it is absurd and dumb that the discussion even needs to be had, but they must be challenged.
I must say, this is one of the most dishonest image macros I've seen in a long time: https://www.paypal-engineering.com/wordpress/wp-content/uplo...
Disclaimer: I work with Mahmoud.
Presumably "ASF" doesn't mean anything to you. That's because this isn't an image macro, but rather a slide from an internal presentation that compared PayPal's Python API for a custom serialization format to PayPal's C++ API for the same.
Consequently it's important to keep in mind that advances in C++ aren't uniformly available and expertise in it is hard to acquire. That's why the image appears in a section describing the productivity wins available in Python. The point is that Python allows us to develop something that presents a clearer interface to a powerful and performant implementation, and allows our users to worry less about blowing their feet off.
Presumably "ASF" doesn't mean anything to you. That's because this isn't an image macro, but rather a slide from an internal presentation that compared PayPal's Python API for a custom serialization format to PayPal's C++ API for the same.
Consequently it's important to keep in mind that advances in C++ aren't uniformly available and expertise in it is hard to acquire. That's why the image appears in a section describing the productivity wins available in Python. The point is that Python allows us to develop something that presents a clearer interface to a powerful and performant implementation, and allows our users to worry less about blowing their feet off.
I guess you aren't really experienced with the two languages then?
For example, in the programming language shootout (http://benchmarksgame.alioth.debian.org/) the regex DNA test has a 5x lines of code difference between Python and C. That was code written by experts in each of the respective languages, and highly tuned for performance. About half the lines in the Python entry are just string constants that could easily be exported to a data file, which would give you almost exactly the 10x difference this slide represents.
Now, that doesn't mean it is always so, but it's totally reasonable to see that happen routinely.
For example, in the programming language shootout (http://benchmarksgame.alioth.debian.org/) the regex DNA test has a 5x lines of code difference between Python and C. That was code written by experts in each of the respective languages, and highly tuned for performance. About half the lines in the Python entry are just string constants that could easily be exported to a data file, which would give you almost exactly the 10x difference this slide represents.
Now, that doesn't mean it is always so, but it's totally reasonable to see that happen routinely.
What do you feel is dishonest about it?
you might enjoy a comparison between c++ and erlang: http://youtu.be/xrIjfIjssLE?t=1m21s
One little niggle though, "great concurrency primitives"? I don't know about great. Acceptable for sure, usable, good enough. If you use great then you aren't leaving much room for languages with objectively better concurrency primitives.
If Python has great concurrency primitives, what does Clojure have for example? Super-duper-hyper-great?