23 ms·

it's funny that when "discipline and rigor" is advocated for, the underlying premise is basically "pain builds character".

bborud 3y ago
Quite the opposite. You can essentially choose what kind of pain you want. On one hand you can have the pain of having to work with a compiler and toolchain that aims to eliminate problems early by requiring you to be more consistent and more correct. On the other hand you can choose to deal with the pain later - as your errors and inconsistencies come back to haunt you later. Or if you are a professional: have to invent your own consistency and error checks through extensive testing. Not that I would expect rigorous test from someone who chooses to avoid compilers that can help them write higher quality code. It is a lot more painful to have to deal with errors later, than it is to deal with them as you write the code. Not least in terms of financial pain and risk. For a lot of embedded systems "just updating the software" isn't always easy, it usually carries significant risk, and it isn't always even possible depending on how something is deployed. Or to express the above with fewer words: you can choose between pain now and pain later. As for tooling: using an interpreted language like Python means that it will only work for as long as the runtime environment is in a particular state. That all the right libraries are available in the right versions, and even the language runtime itself. Thousands upon thousands of files splattered across your filesystem. Every update of any part of the environment risking you suddenly have to spend days figuring out how to get things to work again. Brittle toolchains are a pain. Don't waste time on things that lead to brittle toolchains. I see a lot of hobbyists downplaying this online. I don't see a lot of people who work on this full time downplaying it. Be it people I know at MCU manufacturers who have to support customers or companies that manufacture devices and have large teams of embedded developers who regularly have to waste time because every new release means weeks of getting builds to behave somewhat predictably and reproducibly. Having more modern compilers and tooling that can be relied upon isn't about more pain. It is about considerably less pain. If dealing with a compiler that is strict is too much pain for you, then embedded programming probably isn't for you. Because having lax compilers (or no compiler) means you'll learn about your mistakes when it is quite possibly too late to do anything about them. C/C++ are not very nice languages if you want to ensure quality. Python gives you a sense of productivity over C/C++, but it provides no added benefit in terms of quality and de-risking. Rather the opposite because even the meager discipline a C/C++ compiler gives you is more than what Python gives you.

bborud 3y ago

Quite the opposite. You can essentially choose what kind of pain you want. On one hand you can have the pain of having to work with a compiler and toolchain that aims to eliminate problems early by requiring you to be more consistent and more correct. On the other hand you can choose to deal with the pain later - as your errors and inconsistencies come back to haunt you later. Or if you are a professional: have to invent your own consistency and error checks through extensive testing. Not that I would expect rigorous test from someone who chooses to avoid compilers that can help them write higher quality code. It is a lot more painful to have to deal with errors later, than it is to deal with them as you write the code. Not least in terms of financial pain and risk. For a lot of embedded systems "just updating the software" isn't always easy, it usually carries significant risk, and it isn't always even possible depending on how something is deployed. Or to express the above with fewer words: you can choose between pain now and pain later. As for tooling: using an interpreted language like Python means that it will only work for as long as the runtime environment is in a particular state. That all the right libraries are available in the right versions, and even the language runtime itself. Thousands upon thousands of files splattered across your filesystem. Every update of any part of the environment risking you suddenly have to spend days figuring out how to get things to work again. Brittle toolchains are a pain. Don't waste time on things that lead to brittle toolchains. I see a lot of hobbyists downplaying this online. I don't see a lot of people who work on this full time downplaying it. Be it people I know at MCU manufacturers who have to support customers or companies that manufacture devices and have large teams of embedded developers who regularly have to waste time because every new release means weeks of getting builds to behave somewhat predictably and reproducibly. Having more modern compilers and tooling that can be relied upon isn't about more pain. It is about considerably less pain. If dealing with a compiler that is strict is too much pain for you, then embedded programming probably isn't for you. Because having lax compilers (or no compiler) means you'll learn about your mistakes when it is quite possibly too late to do anything about them. C/C++ are not very nice languages if you want to ensure quality. Python gives you a sense of productivity over C/C++, but it provides no added benefit in terms of quality and de-risking. Rather the opposite because even the meager discipline a C/C++ compiler gives you is more than what Python gives you.