I'm learning SPARK2014, a subset of Ada, for a controls software package I am trying to put together. I started in C, thought about using Rust or Zig, but finally settled on SPARK after reading through most of these two books:
Analysable Real-Time Systems: Programmed in Ada
Building High Integrity Applications with SPARK
I typically enjoy conciseness, and at first I was put off by Ada's verbosity, but then I think my old memory of Pascal clicked and I am enjoying the experience.
A few examples of Ada/SPARK on embedded processors also added to the range or possibilities along with High-integrity software and tooling.
What did you think of this book? I'm thinking of picking it up, coming from a non-Ada background.
>I typically enjoy conciseness, and at first I was put off by Ada's verbosity, but then I think my old memory of Pascal clicked and I am enjoying the experience.
Ada is verbose, though is it complex? I've been reading some Ada looking to use it for some projects and I like what I see (SPARK and the type system especially). I just worry about complexity... I use C++ for my work and I hate the language for it's messiness and complexity and the myriad of footguns. So I was just curious what you thought of Ada's complexity coming from a far simpler C (well, I guess the complexity in C is hidden... but I digress).
A couple of my college friends use Ada daily and have been working with it for over 15 years now. One of them fell in love with the language when our first ever programming course was taught in Ada, presumably to get students with started with a solid base :-)
They now work on radar systems at Thales Group. I've read that it's also widely used in aviation, e.g. at Boeing[1] or Airbus. As for general development, from my (albeit limited) experience the type system is a bit heavier than I'd like. It's certainly a great help for highly reliable systems, but most applications probably don't need such a strict language.
I've been doing my hobby projects in Ada for the last couple of years. At the moment, I'm building a game for the Pimoroni Picosystem. Most of my code is open source.
I use it for pretty much everything (personal projects), unless it's a one-day/one-run script kind of deal. And even for those little throwaway things... I'm real tempted to use Ada anyway.
It's just so damn comfortable to use that I often have a hard time using other languages now. I think writing down what things mean in the type system helps catch any issues in my approach before I get too far with it. Being able to easily but powerfully write down what things mean in my programs is amazing. I don't need to worry about unloading some part of the program from my head, because everything I need to remember is written down - and enforced by the compiler.
Once I got over feeling paranoid when my programs just worked after they compiled, I found I could actually relax quite a lot while programming. There's just so much stuff I no longer need to be constantly watching out for. It's great.
> Please leave your echo chamber. Not everyone uses IDEs.
You are so wrong about embedded development I don't know where to start.
Trying to have a fully command-line development path requires you to actually fight with most chip manufacturers (this has finally gotten better in the last 5 years as basically everything has converged to ARM Cortex-M which is supported via official gcc releases from ARM).
I can't think of anyone who developed for a PIC without MPLAB in the last 20 years (probably 30, but I'm being nice). Well, there are some people who didn't use MPLAB, but they used IAR or some other IDE.
Keil is the standard for your ARM processor. Every manufacturer supports Keil first and then worries about whether you can use another IDE. The raw toolchain is almost never tested.
Nordic forced you through Segger Embedded Studio but now has thrown in behind VSCode. Fortunately, you could generally peel out the pieces you needed for command line development.
And the ones who didn't fall into those categories generally bodged some horror together using Eclipse.
Even as far back as PowerPC and ColdFire people were using things like CodeWarrior. Command line things like Cygnus were not common.
I would suggest you get out of the HN echo chamber and realize that the vast majority of software development is done on Windows where "pointy-clicky" is the rule and "command line" is anathema.
Yup, the expectation from a huge portion of embedded developers is a complete package of tools where if it doesn't exist in the GUI, it doesn't exist. See here for an example of that attitude (relating to rust): https://www.reddit.com/r/embedded/comments/pwkr5w/writing_em...
(I think this attitude is one of the ways/reasons that embedded is a bit of a ghetto in the software development world. It also makes it far more difficult to have a codebase which supports multiple platforms)
Maybe, but I suspect it's mostly just a function of vastly fewer programmers doing embedded than "standard" programming.
One of the reasons why I have been banging on chip companies to support VSCode is solely that. The total amount a chip company is willing to spend on software is less than a rounding error in the budget of any Microsoft division.
The only thing that will get embedded out of the ghetto is to ride the coattails of the mainstream--nowadays that's pretty much VSCode and clang/gcc.
VSCode, XCode, VS Community, Android Studio aren't free beer as such, the salaries of the teams come from Apple hardware, Windows and Azure licenses, Google Cloud and 30% app store,...
Thanks for pointing that out, because it was not on the linked page nor on the main page. They do a good job of never mentioning it anywhere on the main pages. (I suspect that's intentional. It's always one extra click hidden--It's buried under the Community tab which then has a Download tab. Or it's under the Try Ada now which then gives you a GNAT Community Download button.)
The lack of transparent pricing is still an issue, though.
Analysable Real-Time Systems: Programmed in Ada
Building High Integrity Applications with SPARK
I typically enjoy conciseness, and at first I was put off by Ada's verbosity, but then I think my old memory of Pascal clicked and I am enjoying the experience.
A few examples of Ada/SPARK on embedded processors also added to the range or possibilities along with High-integrity software and tooling.