Dear community –
Dear Mbed team –
(cc @Kojto @rwalton @jaeden @AnnaBridge)
Reading the comments on PR #170 and issue #171 of mbed-tools , it says:
[…] We should only depend on what mbed-tools itself needs, and count on an Mbed Installer to have installed anything that mbed-os needs.
What is the idea behind an “Mbed installer”?
I might be worrying for nothing, but reading this got me thinking and I’d like to share my thoughts with you: (it’s quite long, please bear with me)
Having an installer packaging “everything” (Mbed Studio, Mbed Tools, ARM GCC(?)) surely is nice for beginners and hobbyists who just want to get up and running without worrying or messing with toolchain setup and command line tools.
But power users, people using Mbed in real life, real production, shipping hundreds/thousands of units per year, do need the command line tools. We have CI, we have CD, we need to be able to work on the details and it’s absolutely okay and normal for us to mess with the command line, with pip install and CMake configuration.
We don’t need too much automation, we need good documentation, we need clear code, we need to able to write the code with vim if we want and still get autocompletion. We might spend some time setting it up, but it’s okay because in the end Mbed and the tools will comply with our workflow. And not the other way around.
We don’t want to have to download an installer to start working with Mbed or compile on our Github Action CI. Heck! Mbed Studio is 1.2GB (!!) – VSCode is 90MB, and with CMake, you just need to install the cmake-tools and the C/C++ Intellisense extensions to have perfect code completion and debug.
It feels like Mbed Studio is reinventing the wheel. Sure you can “select your target”, but based on the number of people complaining on the forum that “it doesn’t work”, is it really better than a nice and clean command line tool to do it for you?
We’re writing C/C++ for embedded software, we need to dive deep into obscure documentation to find what we need, surely we can handle running a few, well explained, commands to make it work. When adding sensors, BLE modules, actuators to your project, you don’t expect them to just work with a few clicks. You know you’ll need to write some code and read the documentation. I think it’s okay for Mbed to be the same. Mbed is really worth the effort, I mean it, compared to other RTOS.
I personally don’t want another Arduino IDE, I don’t want another STM32CubeIDE nor a new Eclipse clone.
Mbed is going through some amazing changes with the new CMake build system. At our company we feel that we are finally in control of our workflow, there’s no magic (well still a little with the targets.json but that’s okay), nothing’s hidden away, we understand everything that is happening.
Those new tools must be pushed forward to expert users. They will use them, they will change them, they will break them, they will explore the corner cases.
You’ll get amazing feedback on what people are doing, are trying to do, would like to do and absolutely don’t want to do.
Then, when things settle down, when the picture is finally clear, it will be time to crystallize all this in a pre-packaged installer that people can just run to install what they need.
IMHO, doing it the other way around, like the Online Editor or even Mbed Studio, will not work.
Because once you have a “final application” as complex and as big and as heavy as this one, changing how the underlying things work, even for the better, becomes hell on earth. You end up with the Arduino IDE that nobody likes, something good for beginners but absolutely not usable for people who want to push their code to production. (Talking about Arduino, they have finally launched their own command line tool. I guess it’s a sign they are listening to their users after all…)
Mbed supports so many targets, they are so many great libs available, the drivers, the HAL, the RTOS, the team, the discussions on Github, it’s an absolute pleasure to work with it. We owe you to read the docs and follow some steps to get up and running.
Is it really worth all the efforts put in the new CMake build system, in the number of targets supported, in the quality of the code, to have a half backed “double-click installable solution” that will only bring more “I can’t find my target/I can’t import the library” and less happy expert users? Are we really too tired for a git clone, wget <url> or touch CMakeLists.txt?
To draw a parallel for the complexity of providing a first class full features IDE, I’ll take the exemple of Xcode.
I’ve done quite my share of iOS development. Xcode is both hated and loved. It’s a pain in the neck because it’s the only way to write software for iOS. It’s buggy, it’s heavy, it’s slow. But it’s also the IDE that works the best and it’s free.
Of course Xcode is more complex than Mbed Studio (a lot heavier too with ~11.2GB). But it’s made by Apple. Apple, the company that introduced the M1 to the world and will likely kill Intel in the process. Even for them, for their resources, it’s a humungous product to maintain (insiders source).
When Apple introduced Swift, they also introduced the Swift Package Manager (SPM), a new command line utility to create packages (libs) in Swift.
Swift was supported by Xcode, but not SPM. They first kept SPM as a separate project, that was not even compatible with iOS development (the majority of people using Xcode), so only usable for creating other command line tools and server apps.
They did that so that the Swift community, people working hand in hand to make Swift better, could see what they could do with the tool. It spawned a lot of discussions about the shortcomings of SPM, the missing features, but also its power, its simplicity, the cleanliness of the projects and the code written.
After all that, Apple eventually added support of SPM to Xcode, in the best way possible, based on the feedback from the expert users and the community.
I think ARM should do the same with Mbed.
TL,DR:
Focus on the tools, CMake and Mbed OS;
Provide a full feature IDE later, and only if really needed
Thanks for reading 
Best,
– Ladislas