Live data from Hacker News

Why Ada Is the Language You Want to Be Programming Your Systems With

hackaday.com

131–140 of 330 posts

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#131

Earlier quoted context omitted.

Why can't someone write an article about Ada without it having to be about Rust?

Because they overlap almost entiely in use case?

How?

Ada was designed for programming safety-critical, military-grade embedded systems.

Rust was designed as a memory-safe, concurrency-safe programming language, largely to overcome the shortcomings of C++.

Each excels at what it was designed for, but the intended use cases are very different.

Rust is not (currently) being used for aircraft flight control systems--Ada is.

Ada is not (currently) being used for high-performance web browsers and servers--Rust is.

While there are SOME similar design goals in terms of memory safety, concurrency safety, and error prevention, they do not "overlap almost entirely in use case".

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#132
post #125
post #99

Earlier quoted context omitted.

> As I like to write, Ada is used in critical systems such as ballistic missiles and trains, whereas Rust is used in Firefox. You mean to say that Ada is good for much simpler, easier, smaller-scope projects?

Only a person who has never worked on a safety-critical application would say something ignorant like that. (I am neither a Rust nor an Ada user.)

I have actually worked on safety-critical applications. ISO 26262, MISRA C, ASIL, etc. :D . I even own and drive a car that has my software in it.

I am obviously teasing the OP, but there's IMO a lot of truth to it. Safety-critical stuff damn better be simpler, smaller and fundamentally easier or it will fail and kill people. That's why stuff like https://groups.google.com/forum/message/raw?msg=comp.lang.ad... makes sense. In a lot of aspects, mission critical-software is much, much "easier": easier to stretch the budgets, easier to not have competition, easier to justify why something can't be done or why it has to take another 3 years of work.

While a modern fully functional web browser is a huge pile of complexity, technologies, requirements and yet it is still needs to work under much tighter social, economical and performance pressures. Any bug being widely exploited, could lead to people literally dying or at least having their lives ruined. It's just not as spectacular as "missiles".

So I think the OP (and probably you as well :P) is being arrogant by dismissing "firefox", that's all.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#133
post #32

> Ada code controls rockets like the Ariane 4 and 5, many satellites, and countless other systems where small glitches can have major consequences. A somewhat amusing endorsement given that the infamous failure of the maiden launch of the Ariane 5 due to series of interconnected software bugs - a reminder perhaps that the choice of implementation language does not automatically make for a reliable system.

There's always someone who brings this up whenever Ada is mentioned, as if it serves as a damning refutation of Ada's reputation as a safe language. That bug was caused by a series of design failures if anything, rather than software bugs. From memory, they reused the inertial reference system from the Ariane 4 mission without testing its suitability for a different delivery vehicle. The actual 'bug' was caused by an integer overflow occurring due to the velocity variable not being wide enough to handle the higher horizontal velocities of the newer rocket. This caused the rocket to go off course and require termination. The backup computers had the exact same flaw due to having the same programming. I'm guessing they used Ada's modular integer types, which wrap around when they overflow. This is the same as C, and I'm guessing the same as Rust. Using either of those languages wouldn't have helped in the slightest here. It's not some software bug caused by Ada. It was a domain issue caused by a failure in management and testing.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#134
post #10
post #4

Earlier quoted context omitted.

Why not FSF’s GNAT? It’s been a while since I used it, but I remember preferring its error messages to some commercial offering we had around.

AdaCore's compiler is GNAT. They sell a pro version with bells and whistles but AFAIK the actual compiler is the same.

GNAT Community version does not offer support for old versions of Ada, GNAT Pro does, but at the same time GCC's Ada (gcc-ada is the package for Arch Linux, for example) supports all versions of Ada. Funny that. I cannot say I am completely happy with the way they are trying to get money.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#135
post #111

I'm missing SPARK, the restricted and formally defined language based on Ada, extending Ada with contracts and aspects, and disallowing the insecure parts. https://en.wikipedia.org/wiki/SPARK_(programming_language) This is the real highlight of Ada.

Exactly. See this post: https://news.ycombinator.com/item?id=20934511

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#136
post #72

This article promotes a popular misconception of the programming situation for defense projects in the 1970s. There may have been "hundreds of specialized programming languages" in existence that could be used, but just a handful actually predominated. Most aeronautical projects were done in JOVIAL. I've talked about this history with engineers from the 1960s-70s. They did not regard the introduction of Ada as a good…

I'm sure that's all true.

There is something to be said for a language that was written to a spec from the beginning, however. That is a luxury that few languages today can claim; most language specs were written after the first version(s) of the language were implemented, and were written to match the implementation, not the other way around.

Writing the specification first makes for a much cleaner language, though not always the most comfortable, if you put any weight in your own opinions.

[I am speaking generally from here onwards and I am not looking for specific examples to the contrary. I know full well that there are exceptions to the generalizations below.]

Lots and lots of engineers today would (and do) express complete comfort in their daily drivers of C and C++, while producing buffer overflow bugs and use-after-free bugs all the while. Maybe it isn't in the best interest of the software landscape to let developers choose the languages they use...

We have, as a community, let our feeling that software development is an art dictate how we react and deal with new information; we overwhelmingly reject it. What we're doing now is so much more comfortable, and we feel like we know what we're doing with [language x] finally! Why would I want to overturn all that comfort?

Software development is not an art, it is a science, and we've been ignoring the science part of that as we refuse to abandon our favorite language(s) for things that could easily be proven to be better, if we would just do the testing to determine performance numbers, ease of bug introduction, ease of maintenance, and so on.

We call ourselves "software engineers" and we don't measure anything beyond the most rudimentary measurements. We DEFINITELY do not actively look to overturn our comfort in favor of finding a better language to use. We don't try to improve anything the moment that might mean that we switch languages, no matter how significant the long term advantages could be. We don't even think about what the long term advantages could be; we're too busy telling ourselves that we are smart and that we can do it in whatever language we are comfortable with.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#137
post #72

This article promotes a popular misconception of the programming situation for defense projects in the 1970s. There may have been "hundreds of specialized programming languages" in existence that could be used, but just a handful actually predominated. Most aeronautical projects were done in JOVIAL. I've talked about this history with engineers from the 1960s-70s. They did not regard the introduction of Ada as a good…

Many of the 'programmers' of those days lacked the sophistication and education to appreciate Ada. Just the mojo required to print an integer (having to instantiate a generic) was considered complicated Ada was also very slow to compile, on the order of 10 times slower than Jovial. (my experiences) Avionics systems back then were tiny. Jovial usually ran on a 16 bit processor. Ada enabled a certain maturity and corre…

I can sympathize with resistance to Ada in a sense: Big "enterprise-y" languages can feel unwieldy and cumbersome if you're used to bit-twiddling and struct-packing in something like C.

But as the recent Boeing debacle has shown, the avionics domain is in need of greater sophistication and reliability. What it doesn't need is more hackery, as satisfying as that may be for the hardware hackers.

Though Ada isn't a massive household name, I think its designers were vindicated by history.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#138

Earlier quoted context omitted.

Nobody wants to play with their compiler to get a small binary. Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries.

If big binary works faster, I would prefer big binary any day. Nobody cares about disk size.

>Nobody cares about disk size.

Embedded people care.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#139

First, this is a great introduction article to Ada. It's a great history lesson, and analysis of where it's used and why. That said, it seems to be arguing for something in a vacuum. Where is the mention of other new programming languages that also fit this category? Where is the mention of Rust? Rust fits all the same requirements: - A general, flexible design that adapts to satisfy the needs of embedded computer ap…

Might as well mention F* then!

> F* (pronounced F star) is a general-purpose functional programming language with effects aimed at program verification. It puts together the automation of an SMT-backed deductive verification tool with the expressive power of a proof assistant based on dependent types. After verification, F* programs can be extracted to efficient OCaml, F#, C, WASM, or ASM code. This enables verifying the functional correctness and security of realistic applications. The main ongoing use case of F* is building a verified, drop-in replacement for the whole HTTPS stack in Project Everest. This includes verified implementations of TLS 1.2 and 1.3 and of the underlying cryptographic primitives.

> Its type system includes dependent types, monadic effects, refinement types, and a weakest precondition calculus. Together, these features allow expressing precise and compact specifications for programs. The F* type-checker aims to prove that programs meet their specifications using a combination of SMT solving and interactive proofs.

https://www.fstar-lang.org/

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#140
post #72

This article promotes a popular misconception of the programming situation for defense projects in the 1970s. There may have been "hundreds of specialized programming languages" in existence that could be used, but just a handful actually predominated. Most aeronautical projects were done in JOVIAL. I've talked about this history with engineers from the 1960s-70s. They did not regard the introduction of Ada as a good…

When Ada came out it was a large intimidating language. The saying was "to learn Ada, it's best to know Ada first."

I haven't touched it in a long time, but I remember some of the impressions it made on me when I first used it.

The type system: I think you could do some really fancy things like:

  speed := miles_traveled / elapsed;
You could use types to make speed type mph, miles_traveled be miles and elapsed be hours.

the thing is, I think you had to create some conversion stuff for the "/" so that it allowed two types to be divided, returned a third type.

unchecked conversion: no matter what you did, you had to interface with hardware. So there was a lot of unchecked_conversion() stuff to convert between basic machine stuff.

argument lists: You couldn't have a printf() or any other varargs type stuff that I remember. This made interfacing with external libraries that needed this kind of stuff lots harder. (maybe there are ways to do this)

there were things I really did like

the package and package body stuff: You could implement a bunch of interfaces, and compile against the prototypes before the implementations were written.

the attributes, like foo'Size and the system package let you write your code to be correct even if system types or machine types changed

A lot of Ada is really tedious, but once you got over that, working with an existing project was usually really nice.

Post reply on HN