Why do people seem to think Ada is painful? It's quite strict, but that's a blessing, not a curse. You end up making anything remotely dodgy but necessary very obvious, and in general well founded ideas are clear and concise. You can also define your program much more precisely and make sure that things never go wrong (You can't accidently treat an int and an enum)
I have a possible explanation on this. A lot of people only know Ada in passing, from classes. For someone fluent in another language typically derived from C, the syntax is very new and frustrating initially. People normally comfortable with coding in their preferred language become newbies again, making a lot of frustrating mistakes. And they hate Ada for it.
I've seen several persons being forced into using Ada for a longer time. Geek types, including two long haired ones. They all hated it initially, but after a while they all come to appreciate and enjoy it. Two of them ended up contributing to GNAT. The cross-over time is roughly around 6 months of full time work with Ada, so more than what you get from a class.
So I guess Ada is different enough to be frustrating at first, and most people don't use it long enough to come over the initial shock and appreciate the good sides of the language. They just hate it, and stay with the "Ada is bondage" meme. Too bad.
For any one interested in large software system design and languages, I recommend looking at the "Rationale for the design of the Ada programming language" book. Even if you don't like the result ;) it's an interesting analysis of the challenge of doing large, safety critical system software IMHO. Just read the latest version, the intial one (though interesting) is now dated and made some wrong bets, like using synchronous tasks as the base for concurrency because there was hope that a formal model enabling proving behavior would develop around it, and that never happened.
The reason that a formal model didn't arrive is because it's impossible; the foundation of concurrency is the ability to change state and return the previous state atomically (even if it is only one bit/byte; xref cmpxchg). This necessarily makes the system non deterministic. So building a base for concurrency from synchronous tasks is impossible unless those synchronous tasks are atomic from start to end; most tasks are more than one op code long.
My experience with Ada was that it didn't actually make it any easier to make my code correct, because mixing up an int and an enum when you shouldn't is a trivial problem that's easy to fix in C (never mind that the majority of enums are actually labels for ints); the errors that were hard to figure out and costly to fix were the conceptual ones that were independent of language. Ada just made everything clumsier, more verbose and less readable for no benefit. I suspect on a larger project it would start significantly detracting from correctness by discouraging refactoring.
From memory, he made those comments after he'd been working for a long time in C/C++. He's since seen that language like Haskell and Ada which enforce much stricter requirements have a huge benefit to developers; the inital extra work to learn the language pays off when you get used to spotting even more bugs before you write them because you've been punched in the head by the error messages in the past. You begin to think about code not just from a "how doI get this done?" standpoint, but a "how do I get this done properly, safely and clearly, and make sure the compiler will catch me WHEN I make mistakes". Fixing bugs at development time is vastly less expensive than in testing or after release, so the extra errots can easily be justified.
As far as I see the Ada Doom project is able to do more in less lines of code despite it being verbose (see https://github.com/AdaDoom3/AdaDoom3/blob/master/FOSDEM%20Pr...). For readability, clearly your argument is subjective. Its like saying English doesn't make any sense because it is nothing like Chinese which everyone knows
The sharpest edge of that language meeting bad design and sloppy or inadequate code review. Bad design is a problem in any language, safety critical projects need and typically have much better code review that would have caught the likes of Heartbleed, and every language has its particular sharp edges, e.g. the first launch of Ariane 5 would have successfully reached orbit had the code been written in C. (Yes, it would also have successfully reached orbit had that part of the code been adequately checked - see my above point about code reviews.)
Or more realistically, your experience is on small projects, with only you coding so it is worthless, try opening a large C codebase and fixing all its flaws: good luck.
Ada and its better strict typing is a pain for small projects which is why students don't like it but it really shines on large project (no, it doesn't fix all the issue but it helps).
IMHO what should be done is to take Ada's semantic/strictness and wrap it around a less verbose syntax (1) because if the beginners hate the syntax then the language, no matter how good it is will NEVER take off (and even if it starts taking off it will fall down quickly: see Lisp).
1: yes, I know this was done on purpose but the lack of adoption of Ada EVEN AFTER there was free compilers available show that (IMHO) it was a mistake.
C safety is a oxymoron, which is only enforcable with externals tools.
I also don't regret learning C. It provided me a path to jump into C++ and use its features to close its C underpinnings into a dungeon, as much as possible.
Time for a car analogy. If all languages are cars... I would call Ada's extra checking safety belts - they came with the car from the factory and are guaranteed, within certain amount, to keep you alive. With C you can either make your own safety belts (with duct tape or something), fit on aftermarket safety belts, or you can just be a good driver and not have an accident. I wouldn't call the C car safe, but that's just my opinion : p
