Ada for the C++ and Java Developer [pdf]

It does have operator overloading so you could certainly define some

  function "*"(Left, Right : Distance) return Area 

and if dedicated enough build up a whole set of unit-types with corresponding conversion rules.

Not an Ada guy at all though so no clue if there's a less by-hand way of doing it.

I got it working with:

with Ada.Text_IO; use Ada.Text_IO;

procedure Main is

     type Distance is new Float;
     type Area is new Float;

   function "*" (Left, Right : Distance) return Area is
     temp : Distance;
   begin
     temp := Left * Right;
     return Area (temp);
   end "*";

     D1 : Distance := 2.0;
     D2 : Distance := 3.0;
     A  : Area;

  begin
     A  := D1 * D2; -- OK
     Put_Line(A'Image);
 end Main;

Interestingly, it took me several attempts to create this overload, make it a single line return would make it recursive:

   function "*" (Left, Right : Distance) return Area is
   begin
      return Left * Right;
   end "*"; --   ^ Does not work
            --   raised STORAGE_ERROR : stack overflow or erroneous memory access

Also:

   function "*" (Left, Right : Distance) return Area is
   begin
      return Area (Left * Right);
   end "*"; --  ^ Does not work either, compiler gives me "ambiguous operand in conversion"

There is now, at least with Ada 2012 and GNAT[0][1]. While I'm pretty sure only GNAT has implemented it, I'm not sure if it's actually in the 2012 standard or not.

I haven't played with it yet, but it does looks pretty interesting.

[0]https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gnat_ugn_unw/Perfor... [1]https://blog.adacore.com/uploads/dc.pdf

I am not an Ada expert, but I came up with this. Please notice that the idea here is not to have the compiler do proper dimensional analysis but simply to avoid the default operator overloading of "*" for the Distance type that also returns a Distance value.

Nothing very high-level, as we need to explicitly manipulate the single-component records, but it does the job.

    with Ada.Text_IO; use Ada.Text_IO;
    
    procedure Main is
       type Distance is record
          Value : Float;
       end record;
    
       type Area is record
          Value : Float;
       end record;
    
       function "*" (Left, Right : Distance) return Area is
       begin
          return (Value => Left.Value * Right.Value);
       end "*";
    
       D1 : constant Distance := (Value => 10.0);
    
       D2 : constant Distance := (Value => 20.0);
    
       -- D3 : constant Distance := D1 * D2;
       -- Does not compile. GNAT returns the following error:
       --   main.adb:21:33: expected type "Distance" defined at line 4
       --   main.adb:21:33: found type "Area" defined at line 8
    
       A : constant Area := D1 * D2;
    begin
       Put_Line ("Area A is " & Float'Image(A.Value));
    end Main;*

There's a library for that: http://www.dmitry-kazakov.de/ada/units.htm

The problem I’ve seen with trying to add non-static contracts to performance-sensitive languages has been ideological rather than technical.

Specifically, do the language semantics allow a mode where these checks can be turned off? Leaving them on all the time can be a huge performance burden, both directly and in the barriers they add to optimization (while there are potential optimization benefits to exploiting the guarantees of contracts, I don’t think as a practical matter they balance out).

But allowing them to be turned off in “release mode” eliminates much of the benefit in all modes: Developers can no longer assume that their code always runs in a context where the contractual guarantees are met, so they have to guard data integrity or safety critical operations dynamically anyway.

C++20 was supposed to have them, but they were removed on the very last minute, if we are lucky maybe C++23 will get them, but C++26 is most likely, if they ever go forward with them. [1]

For C you can have a look at Frama-C. [2]

D also has DbC. [3]

In case you can target Windows only, VC++ supports SAL Annotations, while not DbC they help to improve code security

[1] - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p233...

[2] - https://frama-c.com/html/acsl.html

[3] - https://dlang.org/spec/contracts.html

[4] - https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-...

I never understood how is that different from decorating your function with `assert` statements. Is it analyzed statically ?

Any language that has assertions can be used to simulate at least preconditions and postconditions, and maybe some support for invariants.

As the team leader for the second version of a database middleware product developed in C, being convinced by study of the efficacy of assertions for DbC and hence better quality software, I made sure my team used C assertions heavily throughout the codebase, at the entry and exit points of functions, to implement preconditions and postconditions, despite some opposition to it.

End result: the product was a success, and was used in multiple software projects for customers.

We were rewarded well for it.

Edit: I first learned about DbC myself, via reading about Eiffel and Bertrand Meyer's work, early on.

That is one reason why I never liked C and C++ was a better option when coming from Turbo Pascal 6.

Although Turbo Pascal isn't Ada, it did allow for a similar approach with stronger types, which C++ also kind of supports (but C compatibility spoils it).

It was historically too expensive (ie: not free).

While a bit old this might explain why it wasn't popular back then.

Why Ada isn't Popular (1998): https://news.ycombinator.com/item?id=7824570

There's a lot of FUD spread online, partly derived from historic facts, partly total bogus. I like how Luke A. Guest (https://github.com/Lucretia) put it:

"You’ve got to love it when people who [know] nothing about Ada like to tell other people, who know nothing about Ada, things about Ada that they probably heard from someone else, who knew nothing about Ada." -- https://users.rust-lang.org/t/if-ada-is-already-very-safe-wh...

That also applies to lots and lots of comments on this site!

(If you read here, hello, Luke :-)

Ada was standard in aerospace and defence projects in the UK when I started in s/w back in the 80's, although personally never worked in those areas. It may be that its perceived lack of popularity is tied to its association with those rather more secretive lines of work, although that doesn't in and of itself explain why it didn't become more broadly used - other commenters have mentioned cost, and that consideration was enough to kill another technically excellent language (Smalltalk).

My gut perception of Ada is unfortunately mediated through the murky lens of its bastard offspring PL/SQL, which is by a good distance the least favourite of any language I have ever used, although I'd be willing to entertain the argument that this is in large part due to all the ugly and ill-considered bits nailed onto it by Larry's mob rather than inherent defects in the parent language itself.

My personal reasons as someone who has learned the language quite intensively but ultimately decided not to use it: (i) Vendor lock-in and too much future dependence on Adacore (other commercial Ada compilers do not count as alternatives to me because they are super-expensive), (ii) I can't always use the MGPL and would prefer MIT licenses of important Ada packages, (iii) the user community is split in a weird way between very professional aerospace and high integrity systems engineers and fairly dilettante hobbyists, but not many users in the space in-between those extremes, and (iv) not enough libraries for mundane tasks/operating system integration/GUIs.

I'm currently using Go. Although I would prefer Ada as a language, (iv) is in the end decisive for my tasks. If I used Ada I'd spend half of my time reinventing the wheel or interfacing with C libraries. I'm hoping to find a use for it in the future, though.

1. Being good is not enough to be popular. In most cases to be popular a technology needs to be actively promoted by a big brand (of at least a non-profit foundation). E. g. Java is popular thanks to Sun and Go thanks to Google. Also it helps to have free of cheap tools.

2. This problem also has another side - C is much more popular than the language itself warrants.

I see here following reasons: 1. Unix (which is popular in academia since 70s-80s) and later GCC (it was hard to compete with a free compiler at times when most other required an expensive license) 2. Microsoft designated C and C++ as "official" languages for Windows: MS provided IDE - Visual C++ supported only C/C++ [1] and official documentation implies that everybody uses C or C++ to create Windows apps.

[1] Visual Studio later added .Net support, but this not reduced C/C++ popularity because .Net competes mostly with Java.

> Is there any reason why it isn't more popular?

There are a few; if you head over to comp.lang.ada you can find threads on the issue by people who were involved at the time. As I understand it though there are four or five points:

1. Ada was designed and specified completely before any implementations were extant, it used then bleeding-edge theory and integrated several big concepts/features: this lead to the very first 'implementations' being either incomplete or pretty bad performance-wise.

2. The backlash among DoD contractor's programmers; "Don't tell us what language to use!"

3. The rise of C's popularity; I believe this had massive consequences, ultimately setting back the field of computer science by decades. [Take a look at Multics, VMS, and the Burroughs... then realize how many of their features have been added to 'popular' OSes in the last 10–15 years.]

4. Misunderstanding the compiler's mindset: a lot of programmers take the view that they need to "shut the compiler up" rather than as the compiler helping them out by finding problems.

5. Misunderstanding "mandatory checks" — a lot of programmers are used to C & decedent's "simple" nature and really don't understand how things can be leveraged. A good example here is the sequence F(F(F(X))); if F takes Natural and returns Natural, then there is only one check that is needed for this sequence: N on the innermost call... and if X is defined as natural, even that check can be optimized away.

VHDL was initially developed by the DoD back in the time when there was a strong push towards unification of programming languages used in government/defense contracts.

Newer VHDL deviates from Ada syntax in some unfortunate ways that can lead to confusion. For example ".all", in Ada is used to "dereference pointers" while in VHDL it is used to import everything from a library.

Also, coming from Ada you eventually realize that many FPGA vendor's tools are non-conforming to the standard in regards to certain features that are seldomly used by hardware designers but are bread and butter for Ada developers. (enum -> int, int -> enum conversions were partly unsupported in the Xilinx toolchains some years ago, not sure if the problem persists.)

"Java" is probably not a good name for a cryptocurrency either.

Why did they name that cryptocurrency "Ada"?

Yes they are bounds checked, at compile time, or runtime if not able to prove them at compile time.

Overflow is checked.

However both can be disabled via unsafe code pragmas if so desired.

As of Ada 2012, the SPARK proof system was integrated into Ada and you can also use DbC as formal proofs.

Many of the use cases that in C++ would require new/delete are handled by the compiler itself, thus there is an error if when a function is called there is not enough space available.

In the cases that there is a need to explicilty do malloc/free like programming, only malloc (new) is considered safe, manually releasing memory is an explict unsafe operation and marked as such.

From the book:

> dynamic checks (such as array bounds checks) provide verification that could not be done at compile time. Dynamic checks are performed at runtime, similar to what is done in Java.

In addition to what other's have mentioned in direct response to the examples you mentioned, there are additional safety factors - both by default and opt-in.

Pointers - accesses in Ada parlance - have rules that help ensure you can't have an invalid access. For one, the object itself has to be declared 'aliased' to create accesses to it. There are also rules to do things like ensure you can't create an access to some type at a higher scope than the type itself.

There are also memory pools that you can use. So you can specify that all allocations of a type occur in a specific pool or sub-pool. In addition to letting you control how allocation occurs, you can also use them for memory safety. All items in a sub-pool will be freed when the pool falls out of scope, so you can simply leave deallocations to occur that way.

There are also concurrency tools baked-in, with runtime support at least. Specifically in terms of memory safety, you have protected objects. They will automatically ensure you have a single writer at a time, and will do other nice things like still allow multiple readers. If you need to, you can get a fair bit of control over how it all works.