5 ms·

Myths of Enterprise Python

45 points by justin_vanw 12y ago

debacle 12y ago
Does anyone actually believe any of these "Myths?" #6 and #8 are the only ones that could even be remotely considered half-true.
- mhashemi 12y ago
  Unfortunately, unequivocally, yes, there is so much misinformation. I definitely would not have spent so much time on citations, otherwise ;)
  - debacle 12y ago
    I'm not even a python developer and I know most of these are completely untrue.
    - mamcx 12y ago
      Well, sure you are not a python developer... most untrue? Which ones? Why?
- lanstin 12y ago
  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.
- pythonautical 12y ago
  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.
vezzy-fnord 12y ago
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/uploads/2014/12/cpp_py_medium.png https://www.paypal-engineering.com/wordpress/wp-content/uplo...
- pythonautical 12y ago
  What do you feel is dishonest about it?
- markrwilliams 12y ago
  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.
- albemuth 12y ago
  you might enjoy a comparison between c++ and erlang: http://youtu.be/xrIjfIjssLE?t=1m21s http://youtu.be/xrIjfIjssLE?t=1m21s
- justin_vanw 12y ago
  I guess you aren't really experienced with the two languages then? For example, in the programming language shootout (http://benchmarksgame.alioth.debian.org/ 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.
pc86 12y ago
> 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.
- markrwilliams 12y ago
  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 :)
- mhashemi 12y ago
  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 :)
- justin_vanw 12y ago
  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.
GFK_of_xmaspast 12y ago
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.
freshhawk 12y ago
That's a great overview, will come in useful when debunking this stuff in the future. 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?

45 points by justin_vanw 12y ago

Does anyone actually believe any of these "Myths?" #6 and #8 are the only ones that could even be remotely considered half-true.

mhashemi 12y ago
Unfortunately, unequivocally, yes, there is so much misinformation. I definitely would not have spent so much time on citations, otherwise ;)
- debacle 12y ago
  I'm not even a python developer and I know most of these are completely untrue.
  - mamcx 12y ago
    Well, sure you are not a python developer... most untrue? Which ones? Why?
lanstin 12y ago
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.
pythonautical 12y ago
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.

vezzy-fnord 12y ago

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/uploads/2014/12/cpp_py_medium.png https://www.paypal-engineering.com/wordpress/wp-content/uplo...

pythonautical 12y ago
What do you feel is dishonest about it?
markrwilliams 12y ago
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.
albemuth 12y ago
you might enjoy a comparison between c++ and erlang: http://youtu.be/xrIjfIjssLE?t=1m21s http://youtu.be/xrIjfIjssLE?t=1m21s
justin_vanw 12y ago
I guess you aren't really experienced with the two languages then? For example, in the programming language shootout (http://benchmarksgame.alioth.debian.org/ 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.

pc86 12y ago

> 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.

markrwilliams 12y ago
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 :)
mhashemi 12y ago
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 :)
justin_vanw 12y ago
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.

GFK_of_xmaspast 12y ago

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.

freshhawk 12y ago

That's a great overview, will come in useful when debunking this stuff in the future. 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?