Ada and C: differences as the language for system programming (1993) [pdf]

[hazelnut-tree]

https://dl.acm.org/doi/10.1145/165354.165360

[thesuperbigfrog]

It should be noted that this paper was released before the Ada 95, Ada 2005, Ada 2012, and soon-to-be Ada 2022 standards were published:

Ada 95: https://www.adahome.com/rm95/

Ada 2005: https://www.adaic.org/resources/add_content/standards/05rm/h...

Ada 2012: http://www.ada-auth.org/standards/12rm/html/RM-TTL.html

Ada 2022 (draft): http://www.ada-auth.org/standards/ada22.html

The paper's abstract states: "Although Ada supports concurrency and can thus be used as a concurrent programming language, it is not generally considered to be an object-oriented programming language."

Object-oriented programming was added in Ada 95, so this paper is probably not relevant to modern programming unless you are interested in the history of the Ada programming language.

[uticus]

"Conclusions... Concerning low level programming, C is superior to Ada for its flexibility and for handling pointers or strings"

[musicale → uticus]

;-) Ada's advantages such as memory safety, concurrency model, range types, exception handling, pre/postconditions and invariants, etc. seem even more valuable now compared to C. Ada's memory-safe string handling seems like a very good idea vs. C.

Ada Minix sounds like it was an interesting exercise - I'd like to see more OS kernels written in memory safe languages.

[thesuperbigfrog → uticus]

True in 1993.

[modshatereality → thesuperbigfrog]

cracks open the "REFERENCE MANUAL FOR THE Ada(r) PROGRAMMING LANGUAGE"

looks like Ada83 specification has address clause though, which can effectively be used as a pointer when combined with System.Address / 'Address attribute. Also has access type, but you can't pass access type around all willy-nilly-like without unchecked_access (added in 95?).

C pointers are more flexible though, that much is true.

edit, almost forgot: the main downside of Ada < 95 is you don't get function pointers, or import/export pragma

[vba616 → thesuperbigfrog]

I don't remember much of Ada, but here's something very basic I liked (had to look the details up):

You could declare custom integer types like this:

type My_Type is range -5 .. 10;

And then you could reference the range with My_Type'First or My_Type'Last

And there were named parameters.

   for A in Range_Type loop
      I_IO.Put (
         Item  => A,
         Width => 3,
         Base  => 10);
      ...
   end loop;

[cb321 → vba616]

Nim [1] is like Ada in these ways but less verbose:

    import strutils # Or from strutils import repeat Or etc.
    type Foo = -5 .. 10                # Or range[-5 .. 10]
    echo Foo.low, " ", Foo.high        # range limits
    echo repeat(s = "x", n = Foo.high) # named params
    # var f: Foo = 15   # Will not compile

[1] https://nim-lang.org/

[Solvency]

Why didn't Ada take off and why did Rust? Doesn't Ada offer everything Rust does and decades earlier?

[mjw1007 → Solvency]

At a minimum there'd have to have been a free-as-in-beer cross-platform compiler.

I think Ada had a brief chance to take off around 2000 when gnat was added to the main gcc distribution, but the GNU maintainer was also the head of Ada Core Technologies and had very little interest in making the free version of the compiler useful for general purpose programming.

I wrote a few small things using it, but the "ecosystem" just wasn't there, and there was nobody trying to coordinate a community that might have built it up.

Even calling libc functions that didn't correspond to anything in the Ada standard library was no fun at all.

[nunuvit → mjw1007]

> but the "ecosystem" just wasn't there

I don't think it ever will be, either. Ada's "ecosystem" is really the tooling. I've seen plenty of Ada, but there's always been zero (or very nearly zero) exchange of code into or out of the company. There's not much opportunity to grow a natural ecosystem like that. The tooling for C and C++ is catching up, facilitating model-based design code generation, which is the direction Ada's niche is heading. Ada didn't entrench itself as a target language early on, missing another chance to surge in popularity.

[rramadass → Solvency]

Good question.

I think the reason is that Ada predates the rise of the Internet and thus it did not have the "Internet-based large bullhorn" that is available now. Also the main community it targeted were serious professional types rather than the "noisy fanbois" we have now :-)

Thus the reason for its "low profile" are mainly Social and Political.

[turndown → Solvency]

I think questions like this are both ultimately unknowable and assignable to a few realities. Rust is newer and thus was more likely to gain steam, all other things held equal. It was built for a specific reason, in response to a specific desire(a concurrent CSS renderer for Firefox?) so it was focused and useful in a difficult context. It featured many novel or under applied(in mainstream programming languages) features that solved annoying issues. Rust has enjoyed relatively few newcomers to its space since its inception. But on inspection many of these things might not matter at all(except the first one, IMO) and the truth may lie in other communities(as in, C++)

[vba616 → Solvency]

(1) Weren't there issues with making good compilers early on, because the language was complex? Another case of worse-is-better versus C.

(2) I think a lot of people were prejudiced against it coming from "the government", wrongly assuming that it was the product of a committee like COBOL.

(3) The aerospace industry did not greatly influence everyone else to use Ada, and eventually they just said "screw it, we should use C++ to be able to hire people and cut costs with COTS tooling"

[pjmlp → Solvency]

It did take off, in high integrity computing, Rust is yet to be allowed a place on that playground.

[ksec → Solvency]

Because people hate Ada, even on HN. Linus Torvalds himself hate Ada. People dislike its syntax so much they wont even try it.

[musicale → ksec]

If you can deal with VHDL, you can deal with Ada.

Every language has its quirks. Some people can't stand Python's significant indentation. Others can't bear Lisp's parentheses. Personally I can deal with them. But any library API (say for Java or Swift) with veryLongIdentifierNamesThatAreAlmostSentences drives me insane. I imagine IDEs are enablers for that regrettable trend, but at least they save human typing.

Oberon's capitalized KEYWORDS were probably a mistake.