I'll give you it's overly verbose even though quite a bit of it was justifiable. The theory of Ada's designers was that people read software more than write it. So, the syntax should be designed to facilitate catching errors in maintenance mode, during extensions, or during integrations. It's done phenomenal at that per industrial, case studies despite having been invented in the 80's when lots of language decisions were still being debated.

EDIT: I keep thinking a different language that acts as a front end w/ a better syntax might be a good idea. It outputs Ada that integrates with the tooling ecosystem. Also, a seemless FFI for C libraries like Julia's.

I totally agree that code should be written to be read.

It certainly wouldn't hurt if people simply used a more literate programming style no matter what language they choose

Far too many people think code as below is acceptable.

This is C obviously, but pretty much equal horrors around in every language.

This isn't 1994 and the compiler really doesn't care how long your variable names are, plus EatWhite() is pretty damn fast.

  const int to_pn  = base_n ^ label_n;
      const int from_p = _array[to_pn].check;
      const int base_p = _array[from_p].base ();
      const bool flag
        = _consult (base_n, base_p, _ninfo[from_n].child, _ninfo[from_p].child);
      uchar child[256];
      uchar* const first = &child[0];
      uchar* const last  = flag ? _set_child (first, base_n, _ninfo[from_n].child, label_n)
        : _set_child (first, base_p, _ninfo

> This is C obviously

No, that's C++.

You can't say that definitively based on that code. It could very well be C code. There's nothing there syntactically that a straight C compiler would barf on.

Absolutely correct.

It could be C if `_array` is an array of

  struct {
          int check;
          int (*base)(void);
  };

It is!

It is C.

> I keep thinking a different language that acts as a front end w/ a better syntax might be a good idea... Also, a seemless FFI for C libraries like Julia's.

You mean Rust I think ;)

People have had a hard time learning Rust. I also get gripes about its inconsistency in language syntax. The FFI I hear is good. It certainly doesn't output to SPARK or a C subset designed for easy, static analysis.

So, Rust ain't the Ada makeover Im thinking about. It's also in a stability-oriented freeze of existing design right now. So, the makeover will need to be a different language.

> People have had a hard time learning Rust.

I won't lie to you. It took me longer to produce good code in Rust than almost any other language I've recently learned. But it's worth it; it's quite simply amazing that it is capable of guaranteeing what it does, with nearly zero overhead. Also, I'd say in many ways it's simpler than C, because it has no undefined behavior; I don't need to concern myself with any of the nuances that I had to learn in C. I highly encourage you to give it two weeks, that's what it took me to become hooked.

That type system is pretty sophisticated. You could probably slap a FP front-end ala Haskell but that would hardly make it more accessible. Might as well just bite the bullet and learn the language.

Regarding #2, there's definitely a penalty a language pays for not following C-like syntax and semantics, as people consider it "harder" to learn, because people generally discount the time they've already put into learning similar languages when considering how easy a language is to learn. I suspect someone that knows Lisp but not C might find Clojure easier to learn than Rust, or even Python. The less software in use written in C, the less fundamental it is.

There's also a penalty a language pays for following a C-like syntax and semantics but diverging in specific but significant ways. In this category, I present Perl, which much of whole generation of users decided to treat like C, and got very confused and upset when it didn't always behave like they expected (which I maintain is because they didn't actually understand the language as well as they thought). There's a penalty for being very like something else to the point that people can mostly ignore the differences, but occasionally those differences come out to bite them if they haven't actually learned what they are.

"BEGIN" and "END" aren't all that bad. Some of us got our start in software using Turbo Pascal long, long ago.

"End" didn't stop Ruby from taking off... admittedly a different crowd.