[Geminidog]

>If I hit a reproducible crash in C++, I can drop into a debugger, and work out where it came from. If necessary, I can look at the disassembled code, because it's reasonably feasible to map assembly language to C++ constructs.

I currently write more C++ then python. I'm primarily a C++ programmer. This was not the case for most of my career it is now, so I have enough experience from both perspectives.

The python debugger can display the stack and you don't have to compile it in debug mode. The pycharm debugger is excellent, but even if you don't use that pdb libraries can drop the app itself straight into a debug console with one line of code...

   pdb.set_trace()

As for low level debugging of assembly, in general programmers on the web stack who work at a higher level of abstraction... demarcation is so solid that in my entire career I never had to even know what assembly language was to do my job. That's the point of an abstraction, if you find yourself digging into assembly that means it's a leaky abstraction. Which is basically what C++ is...

[microtherion]

> I currently write more C++ then python

You mention in the grandparent post that you "just" made that switch, so that's a relatively recent development?

> so I have enough experience from both perspectives

I don't mean to be snarky, but evidently you're not nearly as comfortable working in C++ as you are working in Python. Your interpretation of this is that you have gained sufficient experience with both languages to know that the problem is with the language and more experience won't help, but what makes you so confident about this?

> I never had to even know what assembly language was to do my job. That's the point of an abstraction, if you find yourself digging into assembly that means it's a leaky abstraction.

Yes, that's a perfectly valid view, and, in the larger context of this discussion (about whether a programmer should switch to low level programming), if you prefer your abstractions to be solid, you'll probably find yourself happier in higher level programming.

But where the high level programmer is concerned about leaky abstractions, the low level programmer is often concerned about intransparent abstractions — that in some languages, it's hard to develop a reliable intuition how much time and memory a particular line of code will take. That's an equally valid view, and if that's your primary perspective, you might be more comfortable in low level programming.

> [a leaky abstraction] is basically what C++ is...

It's possible to write perfectly sound code in C++, but admittedly, it's also possible to punch holes in abstractions, and that possibility is often exploited.

[Geminidog]

>I don't mean to be snarky, but evidently you're not nearly as comfortable working in C++ as you are working in Python. Your interpretation of this is that you have gained sufficient experience with both languages to know that the problem is with the language and more experience won't help, but what makes you so confident about this?

Give it a year of experience on the job with C++17 and 4 years of C++ at school with C++98. In school I mostly did programing under windows and the Visual Studio IDE, and now it's linux with cmake (another nightmare unique to C++).

This is versus 10 years of experience with python and JavaScript. I would say based off of this experience in general python is a better language in everyway if you discount implementation details. (Almost) Everyone would rather work with the current versions of (typed) python and C++ still only exists because of legacy code and performance critical applications like OS's and games.

That's not to deride C++, performance is very very important . However let's say by some black magic that python performance becomes on par with C++... You'd definitely see a huge paradigm shift in the industry. Huge Performance issues imo is the only thing keeping python from completely taking over.

>But where the high level programmer is concerned about leaky abstractions, the low level programmer is often concerned about intransparent abstractions — that in some languages, it's hard to develop a reliable intuition how much time and memory a particular line of code will take. That's an equally valid view, and if that's your primary perspective, you might be more comfortable in low level programming.

I'm finding that the former view is what most people in general share. It's like worrying about paint pigments vs. Brush strokes. In general most of the population are painters that worry about the brush strokes, but you still need specialists who make the pigments.

>It's possible to write perfectly sound code in C++, but admittedly, it's also possible to punch holes in abstractions, and that possibility is often exploited.

It's not about exploitation. The knowledge needed to write sound C++ code is quite enormous and when a mistake is made and code is unsound C++ makes it very hard to find out what you did to create that unsound code.