Feedback? A WIP "fun" presentation of Ada

General
,
1

This Sunday I will be presenting a bit of Ada to a friend. I have just managed to get the types done, but that will be more than enough. Could I receive some checks and/or feedback about it?

It is currently located in https://irvise.xyz/ada-presentation.pdf and it is a WIP document. I plan to expand on it and add your comments.

Best regards,
Fer

2

Typo? “entretaining”

“Proves” = Proofs

“The advance stuff” x3 = advanced

On page 8, I would put “originally ‘based on Pascal’ but evolved a lot.”

Since when do c/c++ programmers use const? They always use define’s.

I’m only skimming, did you define Mod_256?

“Ada also sucks balls” ??

3

For me, the foul language is a real turnoff. I realize that’s en vogue these days, but I’m pretty sure I’m not the only person who would feel that way. If you’re sure you’ll win more than you’ll lose, or that sticks in the mud like me are worth losing :wink:, then don’t mind me.

That aside, I don’t have much time to say more, but I’ll try to look at it later.

1 Like
4

I’ve actually seen a lot of use of const in C++, perhaps because some compilers (or at least linters) will advise it. (Then again, gnat’s advice is usually what it takes for me to remember to use constant.)

5

How much time do you think you will spend on each slide? 57 Slides with videos in between them will probably take you some time. And that’s just the type system that you’re explaining. Slide 11 till 48 are all about types, which are important but seams a bit excessive. A rough overview of the language might have been better with each 5 of the pillars of ada explained.

I don’t have a problem with the “foul“ language since the target audience is your friends but I do not like you accusing me of sucking balls. ”Ada also sucks balls“ (p. 55). I do not.

(/s for the last part :P)

6

So called “const-correctness” has been advised for C++ for decades (though the advice in linters might be more recent than that). I don’t have my copy with me, but a search for “const-correctness” in the Google Books entry for C++ Coding Standards by Sutter and Alexandrescu, published in 2004, turned up a line from the index: const-correctness, 31, 128, 179.

There is a more recent recommendation at isocpp.org in the so called Guidelines about declaring every variable as const unless one intends to change its value. I believe that is the origin of the advice in linters. I believe the Guidelines were written after the last time I coded C++ professionally, and I don’t remember seeing that advice from the linters I used (clang analyzer and Valgrind’s static analyzer).

I apologize if I’ve misunderstood the context since I haven’t read the slides yet.

1 Like
7
  • I like a lot of the substance. Pointing out the lack of (most) compile-time and runtime checks in C++ is effective, but I think you should include (if you don’t already) one or two slides that explain:
    • How it can go terribly wrong without them.
    • A practical example of how it can go terribly wrong without them.
  • On slide 65 (of 183) you wrote “creates” instead of “crates”.
  • Maybe I haven’t come across it yet, but: you mention anonymous types (e.g., ranges). You might want to omit those, because you can’t all of use them everywhere (e.g., an anonymous array for the type of a field of a record). But I might just be too cautious after getting burned by the compiler too many times.
  • I don’t understand why the MemCopy example appears in the middle of the type atlas. That seems like a slide about foreign function interfaces.
  • If slide 81 is supposed to link to a YouTube video, the link doesn’t work for me.
  • Same on 82. (Maybe the same on other slides; i only checked these two.)
  • On slide 125, My_Resutl is misspelled. I probably wouldn’t care if not for the fact that you’re raising an exception and calling the reader ..._You_Silly :grin:

I stopped at low level aspects for now; I’ll look more later.

8

Most of my C++ programming has been in the last 10-11 years, and what I’m referring to with linters comes from the last year, really. I’ve been writing so much Rust & Ada that I may be over-generous to C++. But these are examples that I have definitely seen & made use of from clang-tidy:

1 Like
9

Quick comments:

  1. I would avoid the Thing_T style, and use Thing instead.
  2. On the basics, there’s a comment saying that Positive is the default index for arrays; this is incorrect: it is the index for Strings, as arrays have no ‘default’ index.
  3. Later, when you say “in is the most powerful keyword, IMO”, you could elaborate that it helps to “think in sets” and that (a) a type is a set of values and operations on those values, and (b) a subtype is a [possibly null] set of restrictions applied to a [sub]type.
  4. In the attributes section, Succ and Pred comment should be “successor/predecessor, …”.
  5. Technically access is not a C-pointer (address/integer); however, because of GCC’s (and therefore GNAT’s) tight integration with C, things tend be a bit more “blurry”.
  6. You might also want to read these three papers I wrote up explaining some of Ada’s basics:
    1. Explaining Ada’s Packages
    2. Explaining Ada’s Object Oriented Programming
    3. Explaining Ada’s Generics
  7. Overall, pretty good, though I think I would have started with packages, this would allow the gradual introduction of records (say a geometric Point type), then private and limited types, then “double back” into the “basic types”, using that to springboard into unconstrained arrays and discriminated records (say using Type Message(Length : Natural)).
1 Like
10

Some notes from me:

For some revision of this presentation, I’d cut all language comparisons (with C++ or Rust) and simply focus on Ada.

The benefits are:

  1. time is not wasted on risky language comparisons
  2. smugness avoided (“they don’t have this feature”)
  3. more focused
  4. more compact

A crafted set of examples is enough for such a presentation.
The primary concern is to chose the features that are immediate, universal and not too specialized.
Since Ada excels at domain modelling and code organization, I’d focus on strong typing and packages, and perhaps mention contracts later (as a complement to the type system).
I’d only mention other topic such as generics, concurrency or OOP in passing.

The methodology is to show examples and engage the audience by asking if they think a feature is useful or if they have and use it in other languages.
This is interesting to the listeners and gives them opportunity to realize that they are missing out.

1 Like
11

Following up some more

  • On slide 152,
    procedure Free is new Ada.Unchecked_Deallocation -- Unchecked as it may be dangerous
(Object => Integer, Name => Int_Acc);
    When I read, “Unchecked as it may be dangerous,” I understand that one of checking or deallocation would be dangerous, and because of that we don’t check it. But my understanding is that it’s unchecked for other reasons having more to do with feasibility; e.g., Ada doesn’t have the constraints on access types that SPARK does, so it simply can’t check every circumstance (at least not right now), so it won’t try, so they named the deallocation procedure in such a way as to make it clear that that’s your job, buddy.
  • less bugs (multiple locations): I realize this is a losing battle, but I’m insane, so I fight it anyway: bugs are distinct as opposed to continuous, so the phrase should be “fewer bugs”.
  • Just like a record with “tagged” keyword: I don’t think that’s what you want to say.
  • There is a proposal to enable it on normal types). See GNAT language extensions! Maybe leave this out?
  • Called after initializing the data (slide 170): I think this wording is confusing, and should be closer to the ARM (7.6(12)), something like: "…after initializing subcomponents.
  • Remeber (slide 174) is misspelled

Modulo all the comments, I like it a lot.

12

If I had a nickle every time Fer gave a talk about Adas type system with the word “fucking“ in it, I’d have two nickles-- which isn’t a lot, but it’s weird that it happened twice.

13

Thanks!

I did not create the image, so I do not have the source to modify it. But I will verbally explain this.

Nop, but I think it is self-explanatory

Ada is not perfect and I also want to cover that too :slight_smile:

Thanks for pointing that out! I did that on purpose expecting to bring emotions out (check out the theory of why news coverage tries to evoke negative emotions). However, as you pointed out and some people in my personal circle indicated, I will tune it a bit down and probably take the foul language completely out of the slides :slight_smile:

I am thinking about adding some summary slides at the beginning as a showcase and quick first touch of the language and then go into depth. The point of this presentation is to be as anal as possible and showcase the full language. You could think of it as trial by fire kind of thing :slight_smile:

Indeed, specially since the introduction of constexpr, consteval and compile time evaluation :slight_smile:

The C++ videos that I include cover that in detail and are great for C++ programmers, so I will just make a reference to them :slight_smile:

Indeed a typo

It is a hint about aspects and how far they can go. I may reduce that section as I think it goes too deep and I want to cover that later…

Indeed… The export is not working great, I will try to fix it once I finish all of it :slight_smile:

Lol, true, thanks!

I thought about this… At the beginning I use it to distinguish things, but I drop it as the presentation goes on.

Done!

Indeed! I will explain this difference in detail verbally :slight_smile:

I think I will do a quick overview at the beginning :slight_smile:

To be fair, I am not the most well spoken person ever specially when I am passionate about something :stuck_out_tongue:

Thank you all for the feedback!

14

I would be happy to have the explaination… if it is implemented as a “pointer”, it is “technically” the same, and should have the same semantic.

And semanticaly (what’s matter)…

p = &a;
p := a'Access;

are equivalent

and

b = *p;
b := p.all;

are equivalent too.

You can even do some nasty conversions:

i = (long)p;
a := P.all'Address;

The main differences are: no arithmetic (p++,p[i]…), the restriction to aliased variable, and the possible not null restriction. (But unfortunately not by default. See the “billion dollar mistake” of Howard Hughes).

[Yes… (long)pis a relic of 32bits systems and will surely brake on a 64bits system. I guess Ada developpers would be more clever and use the System.Adress type instead of long… a little longer to type but safer]

15

Mmm… I get where you’re coming from, but I would disagree a bit.
As an example, System.Address on a 16-bit x86 could be a record of Segment/Offset, for a Forth VM it could be a variant discriminated-record of Stack/Index (return-stack, float-stack, or the default-stack). — Some of these would be nonsense to try to map to int, which is what C has as its pointer type, and doubly so for “pointer arithmetic”.

16

I think you mean Tony Hoare? I do remember that Howard Hughes was derided for some sort of expensive failure, but I thought that was the Spruce Goose.

17

Yes… I guess I am googling too fast.

18

I guess Borland C (a famous C compiler on MS-DOS) has also pointers mapped to a Segment/Offset combo (no choice !). Then I see no differences excepted the one I have listed. (But sure, if you cast a seg:off pointer into a long int then do some arithmetic with the int, the compiler won’t be able to make the result meaningful. Perhaps System.Storage_Elements.To_Integer in Ada would be clever, but I have no Ada/16bits system to try).

With FORTH, no specific rules, but the language has been designed as a low level language on small 16bits systems. Then with F83 (a famous MS-DOS FORTH), pointers are 16 bits. (@ and ! use the default segment), but far pointer functions are supported (FP@ and FP!), but not transparently. The Forth standard requires that an address is 1 cell (but permits many cell sizes : 32bits on WINFORTH and SwiftForth, 64bits on GForth in a 64bits system).

1 Like
19

Yep, and the C standard definitely allows for that. They knew that a direct address for pointers would not work in all contexts as well. It was not uncommon in a lot of 8bit compilers that I worked in the past to have pointers actually point to an internal struct of location info used to construct a physical memory location. I think because 32bit architectures were so common for so long that people got used to a pointer mapping directly to a machine address and just assumed that was how C does it (and that paired with how loosely typed C is).

Even operations on pointers in the C standard are worded to allow for the implementation to do special things (like what looks like a simple ++ operation on a pointer would actually reference internal structs, do some math, and return an appropriate value (as opposed to just incrementing the integer like value by the size).

1 Like