5 ms·
This doesn't look good for Python: "Whenever possible, we use Python" "When necessary, we use C++" "As of right now, it ends up that about 75% of our code is
by stefantalpalaru 14y ago
This doesn't look good for Python:
"Whenever possible, we use Python"
"When necessary, we use C++"
"As of right now, it ends up that about 75% of our code is C++ and 17% is Python (link) since it turns out that a lot of BIND 10 is performance-critical."
- sigzero 14y agoI don't think you are interpreting that correctly. Python is never pushed as "fast". That is exactly how I would use it. Python wherever I could and C++ (or whatever) when performance is crucial.
- potkor 14y agoGenerally you start with Python and 1) get the code correct (hardest part) and then 2) port the performance critical parts to C/C++. So even they ended up with 0% in Python, it wouldn't "look bad". You got the benefit in part 1. (And as others have said, 17% of LOC in Python might still mean majority of the functionality in Python).
- reidrac 14y agoIt could mean that you need more C++ to do stuff (or less Python code to do stuff, whatever your like). What I'm saying is that "amount of code" is not a valid magnitude when comparing different languages. In my experience converting some unmaintained Perl tools to Python, the Python version was almost as long as the Perl one, but it included more functionality, comments and error handling (I'm not criticising Perl here but the unmaintained code that I had to convert).
- misnome 14y agoWhy doesn't it look good for python? As far as I'm aware, Python has never been advertised as a top-performance language, and part of the advantage has always been that you can rewrite performance-critical paths in c. Adding to this, the fact that BIND is something pretty performance-intensive, I don't think this makes it look bad at all.
- papsosouid 14y ago>Why doesn't it look good for python? Because it directly contradicts the "only 20% of your code is performance sensitive and the other 80% can be scripting language X" nonsense that scripting language apologists constantly parrot with no evidence. This is a good example of how scripting languages are in fact not well suited to application development, and should instead be used for scripting.
- fijal 14y agoOr you should use a fast Python interpreter instead of the slow one. The 20/80 (or 10/90 or so) is mostly nonsense in my experience too.
- halostatue 14y agoI would argue that BIND isn't "merely" an application: it's almost kernel-level in what it needs to do and how it needs to respond. At a minimum, it's system-level—but definitely not application-level.
- papsosouid 14y agoThere is nothing almost kernel-level about it. It is an application. You seem to be trying to draw a very arbitrary distinction between applications and applications that you want to consider special for no particular reason.
- DannoHung 14y agoThe question isn't how much Python there is relative to C++, the question is how much C++ there would be if there were no Python. To put it more concisely: "only 20% of your logic is performance sensitive and the other 80% can be encoded in scripting language X leading to a significant reduction of your total code."
- papsosouid 14y agoIt doesn't lead to a significant reduction though, it is hardly any reduction at all. Look at their code, the python could be replaced with C++ at an almost 1:1 ratio.
- gus_massa 14y agoHow many lines of C++ would be necessary to replace each Python line? Let's make a table: Expansion Expanded 1 to 1: 75/ 17 --> 75% 17% 1 to 3: 75/ 51 --> 56% 38% 1 to 5: 75/ 85 --> 45% 51% 1 to 10: 75/170 --> 30% 67% The LOC doesn't measure how many features are implemented in each language. If a language is more verbose or need more detailed management the same features will appear to be longer.
- justin66 14y agoI can see what you're saying but it's worth contemplating what percentage of the total codebase that Python code would represent if it were replaced by C++ code.
- stefantalpalaru 14y agoPoint taken, but if by this metric the percentage replaced by C++ code is still bigger my original criticism still stands.
- alpatters 14y agoI often convert python code to C++ and you'd be surprised how often the difference in loc is not that much. Certainly no hassle to do so. Not that I'm suggesting that one always should. Several boost libraries are inspired by python and C++11 features all help to write C++ code that is surprisingly similar to python, with a bit of extra type sepcification. If you think otherwise I'd suggest you're probably thinking of the C++ of the 90s - a more C with classes, and not modern C++. I often find it useful to develop and prototype in python and convert to C++. Most often I'm doing this because my python simulations can take days and the C++ versions hours. Often I find it is not just the performance critical areas, but it is easy enough just to wholesale convert the lot.
- danieldk 14y agoI often convert python code to C++ and you'd be surprised how often the difference in loc is not that much. I agree, especially with C++11 and (besides Boost) Qt. It's often the header/code separation that makes things a bit tedious, having to keep function and method signatures in-sync. Of course, if you are template-land that is not that much of a problem.
- justin66 14y agoThanks, this is interesting. I'm thinking of getting back into C++ after being forced to work on (of all things) a C project. It's hard to know where to dig in, since actually working with existing code means not playing with C++11.
- 14y ago
- aviraldg 14y agoThat is (the official/BDFL) Guido's stance on the matter too - whenever possible, use Python, but switch to C for computationally expensive tasks. (https://plus.google.com/115212051037621986145/posts/HajXHPGN752 https://plus.google.com/115212051037621986145/posts/HajXHPGN...)