> it’s my opinion that the Arduino ecosystem is a hinderance
I'd say this blog post is the real hindrance.
It's ridiculous to suggest that people should always start at the very lowest level; that newcomers to a space are somehow "hindered" by not doing everything the hardest way possible from the get-go. It's like saying Basic was a hindrance to game programming because the people who cut their teeth on it were shielded from the concerns that "real game developers" have to deal with in C and C++. Quite the opposite! Anything that opens things up and helps more people discover an interest is good for that field in the long run, even if they have to learn more as they progress (who doesn't?).
This just reads as a big, tasteless, "look how much smarter and more experienced I am than you"
I agree. I've been programming embedded systems of all sizes from 8-bit CPUs with 500 bytes of ROM to systems powered by 64-bit desktop processors for the better part of 30 years and I disagree with most of his post.
When I start a project with an STM32 microprocessor, I don't start by digging into the hundreds of pages of data sheet and bit twiddling each register. I start up the STMCube tool and specify what peripherals I need on which pins and let the tool configure the registers correctly.
If I need better performance than it provides, then I start tweaking bits.
There is rarely any benefit to making things harder on yourself. I use C++ in embedded systems because it makes things easier to abstract than C does. Hell, I've seen people basically recreate concepts like polymorphism in C because they were on a CPU that didn't have a good C++ compiler.
I feel like all the lessons learned in desktop programming over the decades are struggling to find a foothold in the embedded world.
Yeah, this blog post is a real drag. Ok, so you've been at this for a long time and are super smart and experienced. Great. That's not who Arduinos are for. They're for folks who want to use a microcontroller and don't want to have to worry about toolchains, bootloaders, and programmers.
I'm getting strong notes of "crusty old curmudgeon", and just a hint of "Get off my lawn with your new-fangled ideas!"
The unfortunate part is, I think he has a some good underlying points, especially about hidden details; and I agree that for many serious use cases, Arduino libraries are just too fickle and unreliable.
If only he had not written that whole piece from a place of professional insecurity...
One place they do have a point (for AVR-based Arduinos at least) is how damned inefficient the basic IO stuff is.
Look at this, for crying out loud![0] All of that assembly for no good reason. The pin mode only requires one or two instructions. If there's no timer config needed, a digital write is a single instruction, as is a digital read.
Even my amateurish attempts[1] (granted, with a C++17 feature) resulted in a better performing, less error-prone result, which is also easier to read.
You should contribute these improvements upstream then.
The Arudino developers are not trying to write slow code on purpose. Mocking them on hackernews doesn't solve anything. I'm sure they would greatly appreciate you pointing out how slow this code is and offering your improved implementation.
> You should contribute these improvements upstream then.
You honestly think they'd accept changes that would break literally every single library using these functions? Somehow I find that hard to believe.
> The Arudino developers are not trying to write slow code on purpose.
Of course they didn't. No reasonable person goes out of their way to make a terrible API. That's why I'm confused and irritated about how they managed to do such a bad job.
All the inputs are bare integers, pins and mode/state, so you get no warning whatsoever when you get it wrong. I've seen posts from people confused because they tried to digitalWrite pins A6 or A7 on a Nano which is accepted by the compiler and runs, but doesn't work correctly because those pins aren't on a digital port. The other analog pins are on a digital port, so work fine.
It gets better. Let's say I digitalWrite with a pin number higher than 19 on a Nano, what happens? Well, it will start off by doing lookups in its pin tables [0]. How does it do the lookup? It just adds the user's value to the lookup tables' addresses [1], and reads that address. On the Nano, these tables are 20 items long [3]. It's going to read god knows what from your flash, and use whatever gibberish it received to decide what to do!
And, because of the need to use inline assembly for the lookups, the compiler can't reason about the data in the tables, and so can't optimize out the lookups, nor can it properly optimize code that relies on those lookups. So the result is it ends up needlessly consuming your limited flash space.
And this is an API that's supposed to be used by beginners! Beginners are the ones most likely to get it wrong because they don't know better.
They're using a C++ compiler in C++11 mode, they're not stuck in the dark ages! Why use a bare integer to represent the pin, a pin's IO mode, or the pin state, or the analog reference voltage source (which, by the way, also makes no attempt to ensure it's a valid value [4])? At the very least they could have used enum classes instead of bare integers so users get a compiler error when they fuck up.
[2] Because of the separate memory spaces, it has to use inline assembly to do this. The pgm_read_byte macro from the AVR header is what does that here.
I started embedded programming with 8 bit PICs and it had to be done in assembly or and limited c compiler. I hated working on microcontroller projects become Arduino came around (got my first one in 2011). With Arduino I could make some really cool stuff and not worry about setting up the the build environment on my machine. Arduino also just works on windows, Linux, and Mac which makes it very appealing to newbies. I love my original Arduino I made some many fun projects.
I'd say this blog post is the real hindrance.
It's ridiculous to suggest that people should always start at the very lowest level; that newcomers to a space are somehow "hindered" by not doing everything the hardest way possible from the get-go. It's like saying Basic was a hindrance to game programming because the people who cut their teeth on it were shielded from the concerns that "real game developers" have to deal with in C and C++. Quite the opposite! Anything that opens things up and helps more people discover an interest is good for that field in the long run, even if they have to learn more as they progress (who doesn't?).
This just reads as a big, tasteless, "look how much smarter and more experienced I am than you"