3 ms·

I just did the switch from 10 years of python to C++. Low level programming is way harder with the C++ stack. I blame mostly the language rather then the level

I just did the switch from 10 years of python to C++. Low level programming is way harder with the C++ stack. I blame mostly the language rather then the level. C++ is just a pain in the ass. If you get a low level programming job that uses rust things might be better. Basically at the higher level, when you hit an error it is (generally) much more trivial to solve... not so with C++. With C++ you can hit crashes and not know where it even came from, this is much more rare in higher level languages. I know several people who vehemently hate C++ with a passion and if you're going into low level stuff, very likely you'll have to deal with C++.

nicoburns 6y ago
> I blame mostly the language rather then the level. C++ is just a pain in the ass... With C++ you can hit crashes and not know where it even came from, this is much more rare in higher level languages. Yep, it's definitely the language. You can do low-level programming with Rust and pretty much never have this problem (never say never, but it's certainly not a common issue).
- Geminidog 6y ago
  Unfortunate that as of right now, most low level stuff is basically C++.
microtherion 6y ago
> With C++ you can hit crashes and not know where it even came from As somebody who writes more C++ than Python, I have pretty much the opposite perspective: 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. Python code generally doesn't crash that way, it's true (unless it interfaces with C modules). But when errors occur, I have to debug them on a Python level. Dropping down the stack is nearly hopeless because the Python interpreter is just too thick an abstraction layer between assembly language and the Python code. And I find myself having similar problems with Swift, for all its elegance. The mapping into assembly language is just considerably more complex than in C++, so you lose a low level debugging tool.
- Geminidog 6y ago
  >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 6y ago
    > 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.

nicoburns 6y ago

> I blame mostly the language rather then the level. C++ is just a pain in the ass... With C++ you can hit crashes and not know where it even came from, this is much more rare in higher level languages. Yep, it's definitely the language. You can do low-level programming with Rust and pretty much never have this problem (never say never, but it's certainly not a common issue).

Geminidog 6y ago
Unfortunate that as of right now, most low level stuff is basically C++.

microtherion 6y ago

> With C++ you can hit crashes and not know where it even came from As somebody who writes more C++ than Python, I have pretty much the opposite perspective: 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. Python code generally doesn't crash that way, it's true (unless it interfaces with C modules). But when errors occur, I have to debug them on a Python level. Dropping down the stack is nearly hopeless because the Python interpreter is just too thick an abstraction layer between assembly language and the Python code. And I find myself having similar problems with Swift, for all its elegance. The mapping into assembly language is just considerably more complex than in C++, so you lose a low level debugging tool.

Geminidog 6y ago
>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 6y ago
  > 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.