Interestingly Co-Pilot gets it wrong and states Ada was designed by committees instead of being multiple competitive processes. How misunderstood Ada is.
There’s more detail about the language proposals and their merits here: (very large PDF) https://apps.dtic.mil/sti/trecms/pdf/ADB950587.pdf
Heh.
"We did not have enough time to do a thorough analysis. The languages arrived at WHMI on February 21 and were on my desk on February 22. To insure the analysis is on your desk by March 13, we have to mail our report on March 8. That gives us fourteen days (counting weekends) to read the languages and work on the analysis. Figure two days to read and understand a language. We have used eight days. Another three days are used to write a report and solicit comments, and one day is lost typing. That leaves two days to analyze the four languages. Even if we had a thousand computer scientists doing the analysis, we could have only scratched the surface of these designs. Two hundred and seventy women can not have a baby in a day."
How funny, I was just talking about and researching Ada at work this afternoon, while discussing what the best language for safety critical embedded systems would be
If i may, what was the outcome? ADA?
It rated highly. But lack of community & ability to hire devs would be it's biggest problems. Rust isn't really mature enough in the embedded space just yet. So we'll be sticking with C/C++ for now D-:
On embedded systems with enough power budget to run statically-partitioned virtualized guest VMs, one could use different languages in different VMs, e.g. separated by maturity and talent availability for specific use cases. Or code that runs on a special-purpose processor.
> lack of community & ability to hire devs would be it's biggest problems
In some contexts, this might be a competitive advantage, e.g. Nvidia uses Ada to secure RoT firmware that protects their industry-leading margins. But they have the luxury of deep pockets and a full hiring pipeline, "Nvidia Security Team: “What if we just stopped using C?”, https://news.ycombinator.com/item?id=42998383
SPARK is a formally defined computer programming language based on the Ada programming language, intended for the development of high integrity software used in systems where predictable and highly reliable operation is essential. It facilitates the development of applications that demand safety, security, or business integrity.Useful, as the site seems overloaded, but that link only says "Welcome to nginx".
Some biting critiques from Edsger Dijkstra:
Red: “the proposal is both advanced and backward in such an incongruous manner that I am baffled”
Green: “technical incompetence, probably enhanced by dishonesty”
Blue: “the blue language is unacceptably complex” … “these documents are an inextricable mixture of technical documentation and salestalk”
Yellow: “an unsalvageable mess”
https://craftofcoding.wordpress.com/2014/04/16/dijkstra-on-a...
Discussion, https://news.ycombinator.com/item?id=44057731
errbody from that era hates Ada --it was an edict that died once the promises of OOP began to be realized.
"dead things should stay dead" - Pet Cemetery, Steven King
If you want to have some fun from 1979, I highly recommend FORTH. It's really good and would have taken over the universe (lowercase u) had K&R C not dropped as part of the slow motion train wreck known as Unix (not to be confused with Linux). https://hackaday.io/project/170826/logs?sort=oldest
PS: Charles "Chuck" Moore (who developed FORTH) last made a release called etherForth at https://etherforth.org/ It runs on a chip he designed called the GA144 (which is also programmed in arrayForth3) available at https://www.greenarraychips.com/home/products/index.php Again, this is for devs that want to have some fun. Between ZeptoForth and etherForth, you're covered.
FORTH is amazing for bootstrapping on a small system. But actually writing code with it is an acquired taste at best.
[dead]
I believe it was both:
https://en.m.wikipedia.org/wiki/High_Order_Language_Working_...
The High Order Language Working Group came up with the requirements.
True but it was far more open than a committee. The STRAWMAN requirements were circulated widely for comment to industry, military, federal and academic communities and to select experts such as Dijkstra and Hoare. Then WOODENMAN circulated for comment after incorporating changes based on STRAWMANS responses.
I wish I knew who were the anonymous authors of DoD "IRONMAN" (January 1977), especially who has written the paragraph "7.2.F. (7F.) FORMAL PARAMETER CLASSES".
"IRONMAN" has introduced a very important innovation in programming languages, which has been inherited by Ada and by its derivatives, e.g. VHDL (the innovation is that formal parameters may have 3 kinds of behaviors, "in", "out" and "in out", and that the parameter behavior must be specified, but not its implementation mechanism, like in older programming languages).
Unfortunately this innovation has remained largely unknown for the authors of most more recent programming languages, which are defective because of that.
If Bjarne Stroustrup had bothered to read carefully the Ada specification before conceiving "C with Classes", he might have understood the implication of the "IRONMAN" parameter classes for languages with constructors and destructors, like C++, which could have avoided many decades of pain for the C++ users. In a language with the "IRONMAN" parameter classes, constructors can be ordinary functions and there is no need for many features that complicate C++, like distinct copy constructors and assignment operators, or "move" semantics. Moreover, the performance problems that have plagued C++ before 2011, due to the creation of unnecessary temporaries, would have been avoided since the beginning.
It is likely that the authors of "IRONMAN" did not fully understand the consequences of their innovation, but they had proposed it only in order to make the new DoD language more similar to Jovial, which was a programming language used in several DoD projects at that time. Jovial had such formal parameter classes, but their meaning was slightly different than in "IRONMAN" and in the later Ada, enough to make them much less useful.
Before "IRONMAN", the earlier DoD requirements were to be able to specify whether the parameters are passed by value or by reference, which is an extremely wrong requirement. It is the same mistake made by C and by its derivatives, including recent derivatives, like Rust.
How the parameters are passed must be decided by the compiler, not by the programmer. For the programmer it does not matter whether a parameter is passed by value or by reference, when the passing of the parameters is implemented correctly (e.g. an in-out parameter that is passed by value is copied from the caller to the function and then back when the function returns, if that is necessary; frequently this is not necessary, e.g. if the parameter is located in a register; if the in-out parameter is so big that copying would be slow, the compiler decides to pass it by reference; in C and its derivatives, both out and in-out parameters must be passed by reference, even when that is the wrong choice; moreover, the compiler cannot flag as an error the reading of an out parameter prior to its first writing).
Yes this is one of my favorite Ada features (combined with named paramètres at call-site) it always felt clearer reading or writing Ada. The intent ('what') is more important (to me, reading heaps and heaps of code) than the 'how' that I can infer quickly and is less useful in data-flow reading mode.
Parameter aliasing creates problems for "out" parameters and for "in out" parameters in any language, regardless whether they are passed by value or by reference, and regardless whether there exists a distinction between "out" and "in out".
In C/C++, where such parameters are passed only by reference, the chances of wrong behavior in the presence of aliasing are greater than in a language like Ada, where they may be passed by value and in lucky cases that may happen to produce the right result.
In general, the documentation of any function should specify whether the aliasing of such parameters is allowed. By default any good compiler, for any language, should give at least a warning whenever parameters that can be modified by a function are aliased, because without analyzing how they are used inside the invoked function it is unknown whether the function will produce the expected results.
The distinction between "out" and "in out" parameters that exists in Ada can only make easier the detection of suspect function invocations. It can never be worse than in C, C++ and similar languages.
On the other hand, the distinction between "out" and "in out" would have greatly simplified C++, because for an "out" parameter the compiler can use raw memory, instead of memory for which a constructor must have been invoked, like for an "in out" parameter. There would have been no constructors as a special category that must be handled differently, any function with an "out" parameter of a certain type could have been used to initialize a value of that type.
The distinction between "out" and "in out" and not specifying whether the parameters are passed by value or by reference are great in real life, because they enable the compiler to make optimizations that are otherwise impossible, as proven by the fact that nobody has succeeded to make such a compiler for the pre-2011 C++. C++ from 2011 and later has solved some of the performance issues, but only by introducing tedious and error-prone annotations for ensuring the desired behavior, i.e. the "move" semantics.
Moreover, not having to specify how the parameters are passed eliminates a huge amount of "&" and of "*" or of their equivalents from a program, also eliminating the risk of errors caused by their misuse. In my opinion, this is a great advantage in real life.
I have not encountered yet a programming language where it is unspecified whether the evaluation of expressions is lazy or eager.
This choice has too many consequences and it is pretty much impossible to understand how a program will behave, unless you know whether the evaluation is lazy, like in Haskell and the like, or eager, like in ML, LISP and in most other programming languages.
In a programming language with lazy evaluation, the programmer also does not specify how parameters are passed. Whoever implements a translator for the language will choose a parameter passing method, which for most parameters will be neither by value nor by reference, but it would be something similar to the ALGOL 60 parameter passing by name.