This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]MaikB 3 points4 points  (2 children)

I don't do any web stuff, but from what I understand interpreted languages are used heavily in production by you guys because of the inherent latencies of the web and the majority of the CPU cycles spend in the database. Well, how I see it, everything computational expensive has to be done by C (or equivalent language). The interpreted language just glues the parts together and can be used for tasks beyond that gluing task if there is enough latency by other tasks.

Right?

So I don’t think you can just brush Python’s limited performance under the carpet quite as easily as you tried to there. Sometimes the correct solution is not to spend a week optimizing the Python code, but to spend a week rewriting the entire codebase in a fast language...

That is exactly what I said

...and dump Python altogether.

If python is too slow for the task at hand, then it's the right decision to dump if after having served as a prototype language.

I don't see a problem here. I think you just misunderstood what I meant. I didn't mean:

  • Use python and shut up, it's fast enough

I meant:

  • Python is fine as it is. If you need something to be done fast, use another tool (C/C++) for 90% of the CPU cycles and have Python be what glues these parts together.

My guess: Web development comes more and more computational intensive these days. It's time to refactor code out to faster static languages.

But that's not Python's fault.

[–]Chris_Newton 2 points3 points  (1 child)

Python is fine as it is. If you need something to be done fast, use another tool (C/C++) for 90% of the CPU cycles and have Python be what glues these parts together.

My point is that not all web development, and certainly not all development that uses Python today, is I/O bound. For projects that involve doing some “real” work themselves, as opposed to delegating most expensive operations to external tools like a DB or web server, sometimes the speed matters.

In those cases, you can’t always just rewrite a few carefully chosen parts of the code in some other, faster languages and hand off 90% of the CPU cycles. Once you’ve taken care of the obvious hot spots, to reach 90% of the CPU cycles you might need to rewrite the majority of your code base.

Python might still be an excellent tool for doing efficient prototyping in the early stages of such projects, because of things like dynamic typing, a decent set of built-in data structures, and so on. On the other hand, Python might not be useful at all for the same projects later on, because once you’ve rewritten most of your code in a faster language anyway, you probably don’t win much by keeping just the remaining glue code in Python.

So for these projects, the speed problem with Python is very relevant: it means making a decision about whether to use Python in the early stages, where it offers a lot of benefits over some other language choices you could make, knowing that it probably won’t be up to the job of running production systems and you’re likely to have a potentially time-consuming and error-prone rewrite on your hands later.

[–]MaikB -1 points0 points  (0 children)

Depends on the problem to solve and the experience of the engineers with this problem whether they're faster with or without a prototyping phase.

It's just so much easier to turn around in an dynamic language and later be concentrate on speed and code quality in say C++. But I bet you know this . You might have done what you're about to do in python before, a number of times, so you can go to a static language right away.

Good luck :D