The argument that new graduates will know Python and have an easier time with embedded systems never sits well with me. If they graduated in something to do with embedded systems then they will know C. If they have a general programming background then they will need some training anyway, as embedded systems often require a different mindset geared more towards low-level programming. So they might as well learn C while they're at it.<p>I think the popularity of Arduino with complete beginners shows that the barrier of entry is rolling the bootstrapping code and getting tools set up, not the language itself.
Embedded systems has begun changing in a way that makes much of this discussion (about Python vs. C++) moot. There are small devices with a ton of compute power that run Linux quite easily, i.e. Raspberry Pi. However, devices are also getting much smaller and consuming less power, i.e. chipsets for smart watches.<p>Saying all embedded will get so fast that you can always use Python ignores the side that is focused on smaller footprint and power consumption. Saying that embedded is only hard-core C or C++ stuff that must be compiled is ignoring the Arduino/Pi world where devices that used to be clearly embedded are now powerful but still very small.<p>However, in either case, we do still regularly deal with a lot of issues such as constrained resources, real-time needs, etc. Grabbing a random engineer who knows Python and saying they're going to be good at that is silly. In many, many cases you'll still need to learn how the system truly works top to bottom to be effective.
Python being or becoming the most popular <i>introductory</i> language for CS is irrelevant to understanding what <i>graduates</i> know. There's 4 years between their introductory course and their graduation.<p>A good CS program will introduce CS students to several (hopefully many) languages. Some form of assembly, imperative languages like C, something like C++/Java/C#, hopefully a "purer" OO language like Smalltalk, functional languages like the ML-family, and others. Ideally with a properly chosen language (or a couple languages) in each of the first series of courses, and leaving it up to the students after that for their 3xx and 4xx courses.<p>And any CS graduate who can't pick up a new language in short order has been cheated out of a good education by their school.
Python is already incredibly popular when it comes to testing embedded systems, and also incredibly popular when it comes to prototyping algorithms and doing data analysis.<p>From my perspective, C and Python provide a nice complement to one another and whilst I wouldn't necessarily put Python onto a very constrained embedded target, I'd certainly use it for everything else - simulators, build systems, unit tests, requirements tests, nonfunctional KPI testing, end-of-line production testing, calibration, documentation generation, configuration file generation and all that jazz.
How about distinguishing between arduino-level embedded systems and raspberry-pi-level?
In first case python is fine, you have full-featured OS anyway already. in second case python doesn't fit at all. what's the question then?<p>Also, for arduino-level systems i wish there would exist (and in active use) better language then C/C++
something in Rust/Nim/mruby/Crystal-direction. Low overhead and better syntax
> When it comes to speed, however, runtime speed isn't the only aspect of development to consider—you also have to consider development speed.<p>It is not clear what sub-domain of the embedded-systems world this article targets. I read once somewhere that controlling equipment for nuclear stations is also embedded development. In general though, first and foremost, you will be considering the BOM cost -- how to reduce it, and how your software choices will impact it.<p>Several strategies are possible: in the small-uC world, people start by developing on higher-end models, then optimise the size and speed as the product ships, to shoehorn the sw into a smaller, less expensive models. This is only possible if the cost of validation is not prohibitive (and if it is at all possible to re-validate the product again -- think about any possible re-certifications to do if the hw changes).<p>If such re-validation is too costly or impossible, one will be cost-optimising the platform right from the start, and in general, cost of development -- an important factor (especially for those who has failed a product at least once ;-)) -- will come only in second to that.
I think an important point in the context of Python (and other languages) vs. C/C++ is the proliferation of cheap hardware capable of running Linux. The relatively new phenomenon of a $10 Linux device makes it an attractive option in many situations. The cost gap between a traditional microcontroller (no Linux) and a linux device is closing.<p>The Linux device is compelling when speed (and ease) of development is important, scale is low, or the market is insensitive to pricing. Not to mention the added bonus of more processing power. On the other hand a traditional microcontroller is still compelling where volumes are high or there are strict real-time concerns.<p>As an embedded software engineer, I'm watching closely. Personally I'm reaching up to higher languages like Python to make myself more attractive in an industry that I see moving toward more Linux devices.
Python is great for simulating, processing data, providing an interface to automation control, but I'd still use C++ for anything time critical. With more recent versions of the standard and Boost, you can be quite productive with C++ without giving up much in the way of runtime performance.
I think 'Python vs C ...' and 'Python vs C++ ...' are different questions. Much like 'C vs C++ in embedded systems' is its own topic.