Now, although C++ is a perfectly fine "HLL" language, I'll grant you that other languages are easier to program in. But patchwork programming can be bad advice

Now, although C++ is a perfectly fine "HLL" language, I'll grant you that other languages are easier to program in. But patchwork programming can be bad advice some of or maybe most of the time. Besides the issues of programming in a language different from what your libraries were written in (and more importantly, designed for), there are serious issues with the patchwork-performance code philosophy. The biggest is that the "routines" that you need to make fast often operate on data. You'll have a container of some sort in your "slow" language, and you'll want to do something with that container in the "fast" language. Do you expose the container's memory to the fast language (hard!)? Do you copy (slow!)? Do you use the more efficient containers in your fast language and expose them to the slow language (insane!)? When exposing complex objects between languages, you'll have similar considerations to make. You can't look at C++/Python or C++/Ruby programming and assume that you'll simply have to make the same sort of engineering considerations as you would for C/Assembly. It's an entirely different kettle of worms. Assembly is concerned with telling a computer directly how to handle memory addresses. C, for all intents and purposes, is just a simple abstraction for doing that. On the other hand, higher level languages present a lot of abstractions for doing a lot of things. And mixing those abstractions leads to serious complexity.