As the ISO WG9 Ada Rapporteur Group (ARG) finishes up its work on Ada 2022 and its first “corrigendum”, we are beginning the next major revision cycle. At this point we are looking for brainstorming and prioritizing of the next set of features for Ada. If you want to provide some inputs, please visit Request for Comments and Suggestions for the Content and Direction of the Next Ada Standard · Issue #134 · Ada-Rapporteur-Group/User-Community-Input · GitHub
10 Likes
As it happens, Brian Goetz, the lead architect of Java just gave a conference titled " Where is the Java language going?"
Very interesting to see the process, the major identified topics, the sources of inspiration (which do not include Ada, and yet!), to see how initial choices weigh in 30 years later, to hear the discourse on ‘we went too far’ with objects, the consequences of hardware evolution that now makes the widespread use of pointers costly, etc.
By the way, on this last point, it seems to me that with its more favorable stack vs. heap balance and its ability to use fewer pointers than other languages, Ada should position itself in the data-oriented wave.
It would be quite amusing if, decades after being considered heavy and slow, Ada made a name for itself in the arena of high-performance languages! 
1 Like
Thanks, I will watch that with great interest.
You make a very good point with regards to the increasing focus on data flows and computing rather than just applications.
It’s interesting to consider Ada as a language that enables that sort of programming.
Arguments about definitions of what is “data-orientation” aside, I have my doubts given the shape of Ada’s standard library which offers very little data-oriented functionality - sorts, finds, min, max, etc. are far from being sufficient for work with “big” data.
To make the thing worthwhile, it would have to be competitive in offering high-level abstractions lifted from functional programming languages because serious data processing cannot be done without them (~ the language expressing the data flow through functional transforms and saving users from writing raw loops).
For example, C++ has lately went full on ranges and views with operations such as applies, folds, filters, joins, concats, splits, zips, chunks, slides, strides, and so on, along with piping that together make it feel almost like programming in R’s Tidyverse.
It has generators and coroutines and a state-of-the-art random library.
It all works well with Stepanov’s original algorithm designs like rotations, etc.
It could absolutely be done in Ada and I expect the result would be much more elegant and beautiful, I have no doubt, but I cannot imagine Ada getting a fraction of this functionality.
1 Like
They definitely did, Java really is spaghetti code where you never know what object you’re using, it’s a mess really and I really think caused the modern hatred of oop.
Since when was Ada not high-performance??
I was speaking of perception only!
2 Likes
I was thinking of the performance aspect of Data Oriented Design.
For example, the AdaCore proposal of a Max size aspect for classwide type : Max_Size aspect RFC - HackMD
The Motivation chapter says “Being able to use classwide types where definite types are required in Ada, which in turns allows to either use tagged types where they couldn’t be used before”, and then discuss the benefit of removing dynamic allocation, and getting tagged types more used in embedded context.
From my point of view, the main benefit would be enable arrays of classwide instances of such types, without pointers, that is with a dramatic effect on locality and a potential huge gain in performances.
With only the “with Maxsize => x” aspect added to the declaration of the root tagged type (and maybe some other aspect to lock the class hierachy).
I dream I could just declare
Team : array (1 .. 10) of Player'Class;
No access type, no indefinite containers : not only the performances are much better, but the code is simpler than ever.
1 Like
Space performance would potentially be worse, but I can see a better speed increase. On the GNAT specific front they are adding a settable aspect Class'Size => in GCC 15 that might facilitate the above. The normal problem is that the size of Player’Class is unknown at compile time (in the general case). That new aspects allows one to set an upper bound, which I would imagine makes array type declarations possible.
There is some argument that “big data” is more often than not “stupid data” — like using textual '1' and '0' to represent bits, for every bit in a byte, for every byte in a word. (Not entirely wrong: IIUC, the recent killer jump in AI came from dropping float-sizes; I expect it would have been even cheaper if they went to fixed-point.)
“The Industry” idiocy aside, you are right that there ought to be some development of a suite of algorithms and, I presume, data-structures… welcome to 1985. — It was always the idea that a Ada Programming Support Environment [APSE] would have such functionality; see:
- Adabase: a data base for Ada programs (1983)
- Workspaces and experimental databases: Automated support for software maintenance and evolution (1987)
- The importance of Ada programming support environments (1982)
- A Revised STONEMAN for Distributed Ada Support (1983)
But there’s a huge point of wisdom here that you may be missing: these capabilities were wisely kept from the Ada Programming Language Standard. — This isn’t to say that we shouldn’t have good, well-built libraries, but that there shouldn’t be a standard library that includes everything-and-the-kitchen-sink. (Which is perhaps the other “we went too far” of Java.)
2 Likes
I agree, I made this exact point… implicitly, and really there is just too much that can be put behind “data-driven” or “data-oriented” for a meaningful discussion without numerous preconditions.
If Ada users want more performance à la @LionelDraghi just above, then I’m all for it, but it won’t enable what I understand as “data-oriented” programming.
There is also a chasm between offering performance and people making use of it.
More wrt the Plan for next version of International Ada Standard
Looking at the JavaOne video - the language is getting functional imports like algebraic data types and pattern matching and syntax sugars. Working with data requires an ergonomic DSL and they seem to think these features will serve as such. It may work for them, but Ada seems to me in need of shaving and polishing more than inflation.
So, polishing what’s there - yes, opening new fronts - no.
I’m saying this as an FP appreciatior. Until recently I thought it would be nice for Ada to also import some of the functional features, but after some more thought, I’m thinking that wouldn’t work. It would further complicate an already complicated language.
Ideas I like:
- unicode
- cleanup & annex J
- libraries
- searchable documentation
Unicode and language cleanup should be solved on the language-stdlib level.
In a perfect world, simplifying the language by removing obsolecent or duplicated features would be the utmost priority. “Stop adding stuff, start removing it.”
Ideas I dislike (Github):
- allowing instantiation at the point of use, and with more parameters inferred - against Ada design
- safe use of pointers, potentially including support for pointer ownership - I’d rather be reading about banning pointers and null, and in any case, you won’t out-Rust Rust, so why bother
- standard packages for XML and JSON
The last point really makes you think… I’m unaware of any algorithms libraries in Ada, but there’s a proposal to include XML in the standard library. The standard library offers no tools for high-level data structure transforms beyond the most pedestrian operations like find, and it’s not being discussed - but it could soon have XML.
That’s interesting and seems to confirm the emergent consensus (what @Lucretia said in the Github discussion) that Ada is a language for embedded development.
Adding a modern profile where other pointer facilities are the default, like nullable (easier to add?) or optional (requires fp afaik) instead of access types.
1 Like
I think if you eliminated access types entirely, then with the current Ada it would be shooting yourself in the foot. There’s very little language support in managing collections of limited objects. Right now you have to rely on access types or global variable declarations if you want to do complex stuff with limited types. Also there’s definitely middle ground between Rust level semantics and where we are now. I think anything that removes the need for access types or at least makes them safer to use in common situations is a good thing to consider.
I do think that the standard library and the language should increase the ability to avoid pointers in more situations (it already covers a lot of area in this aspect, but still there are outliers, and some of the existing solutions are not great / readable / maintainable).
I agree here about removing things (I don’t think we stop adding stuff if we need it), but I will say based on my experience reading the ARG discussions, it seems very unlikely. A lot of folks on the committee are worried about breaking older versions of the language, which for me makes little sense, since people using older versions of the language can use the compilers they always used without the new features, or restrict themselves to an older version of the language via compiler switches/pragmas. I feel like compiler vendors can make the business decision based on their users if they want to maintain / update those older versions or just move forward (or do both).
1 Like
We do move things into Annex J, the Obsolescent Features annex, when we believe we have replaced them with something clearly better. This can make the description of the language simpler (presuming you ignore Annex J!), without necessarily breaking old code.
At some point if a feature has been in the Obsolescent Features Annex for several language versions, I suspect some compiler implementors might stop supporting it, though if they have customers using old versions, they might more likely just presume that customers who care can use the Restriction No_Obsolescent_Features (see RM 13.12.1(4/3)).
1 Like
Of course, I am just being grumpy about the sudden need for smart pointers or borrowing in a 40-yo language. Perhaps this is politics, idk.
I’m mostly worried about the language playing catch-up with Rust at the cost of more and more additions. Even then, if more is better, I’d prefer additions to be higher-level than memory management facilities.
1 Like
I too think more effort should be placed on improving the existing parts of the language and less on major language additions that would take longer to get implemented (if ever, which depends on what AdaCore does). More standard libraries would be good too. I also don’t want more proliferation of anonymous access types (yuck!). I absolutely do not want GNAT’s new “class” type extension (ie the one that is similar to C++ classes) become standard either.
3 Likes
I think many members of the ARG agree with you.
3 Likes
I certainly don’t want it: it adds no significant value for additional complexity.
The bizarre thing, though is the Why!? — If you wanted to do something much more usable with the effort, implement an updated Lamb-Nestor IDL (which DIANA was an instance of). bringing its capabilities (and possibly syntax) more in-line with Ada/SPARK, with an eye toward producing Ada/SPARK & ASN.1, then you have something far more usable, and which could be used both to generate your classes, with SPARK-annotations, and to enable robust heterogenous-system comms/interchange.