Summary After Four Months with Ada
pyjarrett.github.io
pyjarrett.github.io
- language designer have a document where they explain their choices, the Ada Rationale: http://www.ada-auth.org/standards/rationale12.html
- there is an annotated version of the standard, and it's freely available as the standard: http://www.ada-auth.org/arm.html
- A language test suite was developped at the same time of the language: https://en.wikipedia.org/wiki/Ada_Conformity_Assessment_Test...
The last point was also in retrospect not sot good for the language ecosystem: buyers wanted a 100% on this test suite before considering your Ada compiler, which means dev had hundreds of compiler bugs to fix and no paying customers.
From what I understand, a principal rationale of Ada, was to have a “100% reliable” toolchain, and compile-time assurance. So this is actually a reasonable posture.
It seems that Ada can be challenging. In the 1980s, there was a project to rewrite the nation’s air traffic control system, in Ada (I knew a couple of engineers, working on it).
I don’t think it ended well.
https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html would suggest otherwise
The European one, however, worked.
Another poster put up links ([0], [1]).
[0] https://web.archive.org/web/20160601100527/http://www.bloomb... (Unpaywalled)
[1] https://www.skybrary.aero/index.php/Central_Flow_Management_...
It wasn't a ding at Ada. However, big projects (regardless of the toolset) need to be well-managed.
It appeared that mismanagement and misprioritization of the huge ATC wish list and a failure of system engineering to factor limited system resources … then to its priority list.
A different US contractor (that I can’t recall) apparently did ATC better and faster but for a set of different customers (also in Ada).
It must have been when “you don’t get fire for hiring IBM” was a mantra then.
I’d guess the 80s political climate and more general incompetence at the agency and political level was a bigger issue than the vendors and integrators.
The FAA also had issues managing it because it was so large. It was a multi-billion program with millions of SLOC in the early 90s. Simply put, this was a not a cat video website. The tool suite was on AIX 3.2.5 running on RS/6000s using CMVC for source code management.
This was all designed in the mid-80s with implementation starting in the late 80s through the mid 90s. AAS was originally designed after the mass firings of the ATC specialists and the shutdown of PATCO, the original ATC union. AAS was actually a entire suite of programs. AAS was overall program and funding vehicle. IBM Federal deployed a few of the sub-programs like ISSS, TCCC, and others successfully to the FAA.
It was originally developed by IBM Federal Systems and deployed on then-new RS/6000s. AAS failed because of mission creep and the fact it was entirely too large. The program ended after IBM Federal Systems was sold off to Loral and then merged into Lockheed Martin. The head of the ATC group at the time, Bob Stevens, discovered that LM would make more money if FAA cancelled the project and split it up into much smaller programs. Bob called up the FAA Administrator and made the deal to cancel the program since the scope creep was too much. FAA had already sent out a couple of cure letters to get things back on track, but this time the FAA agreed that it was time to cut bait on it.
Initially, what was the en-route portion of AAS was re-done as the Display System Replacement (DSR), which replaced the radar and data positions in the en-route facilities. The concepts of AAS were then rolled into NextGen, which is the FAA's family of programs to modernize its ATC systems.
Ada was used (originally OC Systems's Ada83 and Ada95 PowerAda compilers) for everything in AAS. An Ada-based middleware called FlightDeck was developed to implement all the underlying libraries and subsystems that you need for highly available applications for AAS, including clustering, failover, heartbeats, monotonic time, and multiple levels of redundancy. That middleware is still being today for the systems that IBM Federal, Lockheed Martin, and now Leidos are maintaining and developing like ERAM. After LM bought out what was IBM Federal, they sold it off in 2015 to Leidos because LM wanted to focus more on hardware.
(Source: I work on the later programs that Ada is used on and listened to all stories that were told me by the people who worked on AAS).
Flying In Place: The FAA's Air Control Fiasco https://www.bloomberg.com/news/articles/1993-04-25/flying-in...
Meanwhile in Europe, Eurocontrol's CFMU (Central Flow Management Unit) is written in Ada and successfully routes thousands of flights a day.
Was this a new system, or a replacement of old code? If the latter, could that have been a complicating factor?
> The Ada language is one of the factors which has helped to build, maintain and enhance the CFMU mission critical sophisticated applications.
If non-C-family isn't a dealbreaker I would seriously consider Ada for a large project. Very strong typing and modularity that are very suited for large-scale development, a wide range of available toolchains, but without the kitchen sink. (But I'm not qualified to make such decisions.)
Besides, something like implementation language is almost never why a very large software project fails. (Though if you're already failing, then e.g. implementing your cloud service in COBOL is probably not helping.) It's usually from mismanagement, or a failure to define or understand the problem appropriately.
You mean, they couldn't sell a half-finished product while claiming "100% conformity"? Awesome.
All compilers have bugs and releases happen (at least for GCC which I know a bit more than others) with plenty of known open bugs.
Having a testsuite is of course a good thing, however if you take the top 20 programming languages in use, how many of them do have an accepted wide coverage publically available language test suite?
You said "half-finished product" but what about compiler for every other language than Ada of which most of them don't have a testsuite? How do buyer decide to use Intel C Compiler for example?
Remember all of this was in early 1980.
Having this testsuite was well ahead of its time as many things with Ada, what I'm trying to say is that it didn't play well at the time to help the language ecosystem grow.
> Every user level aspect of the language will be formally specified. None will be left to the translator implementer, operating system or object machine.
> There will be a traceable operational and/or technological requirement for each primitive data, operation and control structure in the language.
> The language will not reveal minor differrences in computer architecture.
> Machine dependent code cannot appear interspersed in-line in source language programs.
> The semantics of the language will be determinable from the description.
> Constructs of the language will have only one reasonable interpretation (i.e., physcologically unambiguous).
> There will be an axiomatic definition of the language. It will be mathematically complete in the Turing sense.
> The language will not sacrifice clarity for efficiency.
> The language will not contain special features for rare cases.
> All defaults in a program will be specifically provided in the language specification or in the program.
> There will be a minimal number of defaults.
… > Any translator for the language must implement the entire language (NO subsets).
> Any translator for the language must implement only the language as specified (translator implementer may not expand the language specification).
> Translator does not have to run on all object machines. Self-hosting is not required.
These are the requirements Ada was designed to fulfill. If not passing the test suite is OK with you, you probably have no use for Ada and would be better served by another language.
This is the best you can hope for in sensitive applications like aviation. I would feel better knowing the software flying me was extensively validated.
> In the 1970s the US Department of Defense (DoD) became concerned by the number of different programming languages being used for its embedded computer system projects, many of which were obsolete or hardware-dependent, and none of which supported safe modular programming. In 1975, a working group, the High Order Language Working Group (HOLWG), was formed with the intent to reduce this number by finding or creating a programming language generally suitable for the department's and the UK Ministry of Defence's requirements. After many iterations beginning with an original Straw man proposal the eventual programming language was named Ada. The total number of high-level programming languages in use for such projects fell from over 450 in 1983 to 37 by 1996.
> The HOLWG working group crafted the Steelman language requirements, a series of documents stating the requirements they felt a programming language should satisfy. Many existing languages were formally reviewed, but the team concluded in 1977 that no existing language met the specifications.
https://en.m.wikipedia.org/wiki/Ada_(programming_language)
(I admit being a little tired to examine a primary source this Sunday. )
There was a gap for a modern, safety & reliability oriented language - and which could be used to unify the mess that existed before.
There are companies that offer paid support, but that's different.
I'm also designing a language, and I have the rationale sort of written, but scattered amongst many design documents. I should put it all in one place like you.
Edit: I guess another way to put this is, "Can a non-trivial project be developed in modern Ada without using Unchecked_Dealloation?" Because I don't see how I can consider a library safe if it is allowed to call Unchecked_Deallocation.
- Lexically scoped access types have storage pools that are destroyed when the type goes out of scope. This is similar to region-based memory management as in Cyclone[0].
- Limited controlled types are a lot like linear types and prevent unwanted aliasing and ensure deallocation happens correctly, as described in this paper[1].
[0]: https://en.m.wikipedia.org/wiki/Cyclone_(programming_languag...
But what about cases in large projects with many developers where a library/package allocates an object on the heap and passes it back to a caller? Sometimes it is not clear who is responsible for deallocating the object. This is the challenge we ran into building large projects in C, C++, and Ada. These days, I use Java, C#, Rust, or Go, because I know there will be no dangling pointers.
Limited controlled types handle this case.
Limited types prevent assignment (i.e. aliasing). Controlled types introduce destructors so everything is closed even when an exception is thrown.
I think the Ada answer would be to keep everything that has a lifetime, anything that's a resource, in its own module behind a strict limited controlled interface. But that's a very vague answer.
Much like "spaghetti code" is not only considered poor style but isn't even supported by modern languages, "spaghetti data" should also be considered a bad pattern, which more advanced languages force you to avoid.
-- Forward declaration.
Type Element(<>);
-- Assuming there's a Graph.Pool implementation of the base Storage_Pool object.
Type Pointer is access Element
with Storage_Pool => Graph.Pool;
Subtype Handle is not null Pointer;
Type Children is array(Positive range <>) of Handle;
Type Element(Parent : Handle; Child_Count: Natural) is record
Data : Integer; -- Or whatever your actual data would be.
Link : Children( 1..Child_Count );
end record;Author here. I've actually not had to do any heavy direct memory management yet. There's an RAII-based (i.e. Controlled Type) reference-counted pointer implementation in GNAT I've used and the container libraries is mature enough to avoid the issue by just using built-in data structures.
A few other smart pointer implementations exists floating around in various libraries in Alire, I suspect there will be a default one will appear in Alire at some point which parallels Rust's Arc, Rc and Box, or C++'s std::shared_ptr, std::weak_ptr (for breaking cycles) and std::unique_ptr. I have a partial implementation myself, but I've been working on other things.
The Ada folks sometimes seem a bit quiet on memory-management questions, a bit like the way Forth folks rarely talk about the real-world performance of Forth interpreters. On the plus side, borrower-checking is coming to SPARK. [1][2]
[0] https://news.ycombinator.com/item?id=24361992
[1] https://www.adacore.com/papers/safe-dynamic-memory-managemen...
https://docs.adacore.com/live/wave/gtkada/html/gtkada_ug/mem...
Septum uses a lot of dynamically allocated memory, but it's all hidden by smart pointers or Unbounded_String (built-in reference-counted COW strings). I use it routinely to search codebases in the tens of millions of lines and it's fast enough right now (single second search times) due to task parallelism I did in Ada that I haven't even bothering to tune it or do any fancy indexing yet.
To implement the Actor Model in Ada one puts all variables in the body of the tasks that are in the application. It makes them not visible from other tasks. So what you need to keep in mind when developing is for a task to never send an access-to-object type variable to another task. If there is a need to do that you need to use Ada/SPARK or Rust to get the proper ownership checking done. Btw, Codepeer (static code analysis tool for Ada) finds race-conditions, has deadlock detection, and warns if there are variables that may be read or written to by more than one task.
If one sticks to vanilla Ada (not SPARK) one could develop an application based on libadalang that parses all the Ada source code and checks that all task entries have input arguments that do not contain any access-to-object types (to find instances where a developer has sent an access-to-object variable to another task by mistake). Such a tool does not exist but libadalang exists to allow the creation of custom rules checking on one's Ada code.
That is more likely due to the type system than manual memory management. People after all say the same thing about Haskell, which also has powerful types, but is garbage collected.
There are two kinds of code errors to worry about: wrong answers (2+2=5), and divergence (a fancy name for crashing, i.e. 2+2=segmentation fault). In a jet engine controller, wrong answers and segfaults both potentially cause fatalities, so you better not use GC. Ada is made for that.
In (say) a compiler, bugs leading to wrong answers (incorrect code emitted) might cause potential fatalities, but if the compiler segfaults from running out of memory, that's only annoying (the developer must find a workaround, use a bigger computer, or whatever). So it is fine to write a compiler in a GC'd language even if its memory footprint and timing characteristics are hard to verify. If you wrote a compiler in Ada you'd spend a bunch of time with manual memory management, for little benefit.
In fact the most serious formally verified compiler (compcert.inria.fr) is written in Coq, which you can think of as an ultra precise dialect of OCaml and which is GC'd (Coq in this case generates OCaml code that uses the OCaml runtime. It can also generate Haskell etc.).
For example, Ada makes it easy to structure one's code in a strict tree hierarchy (whenever you with a package put pragma Elaborate_All (..) on it, which works well with any Ada compiler I've tried it with and is in the Ada standard since 1995). It makes monolith creation by mistake impossible.
Strange you had memory management problems in an Ada application. With all the focus on safety and security within the Ada community, it makes me wonder how the software engineers were using the language in that project?
Also note that one can run into memory leak problems using automatic garbage collected languages. I've personally needed to track down memory leaks in both C# and Javascript applications. Thankfully this rarely happens. It indicates that even when working in an automatic garbage collected language a developer needs to be aware of potential memory issues and think carefully about architecture.
Glad to hear you were successful in the project (with 100s of developers)!
Unchecked_Deallocation has more in it than just returning storage to the system, it also triggers Finalization:
http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-11-2...
"when X is not equal to null first performs finalization of the object designated by X (and any coextensions of the object ...)"
So even if your compiler target has automatic memory management (eg: JVM) you will still use Unchecked_Deallocation if you want to control when Finalization occurs.
1. Your project is static enough that it doesn't need dynamic memory allocation. The control system for a modern passenger jet is a pretty complex project, but you can allocate an object per engine, an object per flap, a struct per landing gear, an object per pilot display, etc. at design time. Even the navigational computers on these aircraft, which take in unbounded structured data about airports and navigational points, often have hard-coded limits. Quoting https://www.mitre.org/sites/default/files/pdf/12_1324.pdf :
> one widely used FMC [flight management computer] model ... has issues at airports with over 100 arrival and departure procedures. Some airport examples where 100 arrival and departure procedures are exceeded include Cairo, Amsterdam, Madrid, Paris (Le Bourget, Orly and Charles de Gaulle), Mumbai, New Delhi and Beijing. A FMC service bulletin issued states that the aircraft may lose FMC applications in flight with over 100 procedures and flight plan up-linking. Further, another manufacturer has a FMC model with a limit of 99 total procedures and a limit of 8 waypoints per procedure. A third FMC manufacturer has a model with a limit on the amount of arrivals, departure and approaches as shown below: Early models – limit of 70 departures, 70 arrivals, and 29 approaches at an airport. Later models – limit of 130 departures, 130 arrivals, and 39 approaches at an airport.
Counterintutitively, this is culturally acceptable for such "high assurance" applications, but WhatsApp gets confusion from the press when it increases the maximum number of participants in a group chat to the "oddly specific number" of 256 (https://i.redd.it/gk7dicv6hsvy.jpg).
2. You use a third-party GC/refcounting library that calls Unchecked_Deallocation internally.
3. There's a 2018 proposal (linked in another reply) for "ownership types", which specifically references Rust's lifetime model as an inspiration.
Or, in other words, if your goal is to write a (say) safe implementation of the DOM that can render real-world web pages while efficiently using memory on a general-purpose computer, Ada is probably the wrong tool for the job. Which is fine! It's a great tool for other jobs.
Author here. Ada is actually perfect for the use case you listed. As a C++ programmer focusing on performance, the applicability of Ada to "modern problems" was one of the reasons I was playing around with it. Between customizable "storage pools" (Ada's allocators), the easy of interfacing with C, control of type alignment and layout, compiler intrinsics, built-in concurrency types (protected objects for coordinating access, and tasks for splitting work) and a bunch of other things, I have all the tools I need to do this. It's pretty close to the C++ feature set with the face of Pascal, and C++ programmers should feel comfortable working in Ada after only a few months.
To use storage pools in Ada I would recommend Deepend (https://sourceforge.net/projects/deepend/). Deepend is a storage pool with subpool capabilities for Ada 2012, Ada 2005, and Ada 95. Memory allocations can be associated with subpools and subpools can be deallocated as a whole which provides a safer alternative than managing deletions of individual objects. It also is likely to be more deterministic and efficient than garbage collection.
1- Don't use pointers. Or use not-null pointers. But preferably don't use them. With in/out semantics you don't need passing pointers or references around, and the addition of official data structures in Ada 2005 make most uses of pointers obsolete. 2- use controlled types when you're allocating to free soon. Limited_Controlled_Type are even safer if you're prepared to deal with a limited type :-) 3- recently, use SPARK, with safe-memory semantics. Hard work, but so is pleasing the borrow-checker... edit Of course one of the impetuses (impetii) of manual memory management is having functions return objects of unknown size (at call site). In Ada this isn't a necessity, at least with GNAT's secondary stack.edit-end
I've programmed Ada almost every day of the work week for 13 years now, I can count on one hand the problems related to memory management, and opening the code you knew you were in for a treat. 'Smells like tiny cache syndrome' just remove those 90's blotches from our humongous codebases when we face them. I'm almost willing to make access types forbidden except in pools (so, not null he), with an open door policy 'explain to me so I can update our coding rules with that case if we find it worth the risk'. Forced software design review by linter.
Yes, there are very few times I've had to manually deallocate; there's a really good video on memory-management with Ada: http://video.fosdem.org/2016/aw1124/memory-management-with-a...
Well anyway, I found it to be very easy to pick up just by reading, hard to make semantic errors, and easy to modify without breaking things. The pace of learning for the entire cohort, mostly non-CS students, was, I think, much faster than e.g. C++ and possibly more complete than e.g. Python. It’s pedantic and exact, but it uses real english language keywords and modifiers.
I went to a different school later where I did the same thing but it was taught in C++. It seemed like many students would get by purely by repeating patterns that they didn’t understand. And I started to catch myself in that trap as well, realizing that I had a lot to learn.
But I wasn’t going to be a programmer; I was going to be a theoretical physicist cogitating on the deep mysteries of the universe. Fast forward…. D’ohhhh.
I see I have enraged the C programmers.
My apologies for being terrible at C memory management, though in my defense I am sufficiently self aware of this to realise that means it's safer for me to stick to perl as a weapon of choice.
The thinking is that over their lifetime, such systems will be read more than written, by rotating teams of programmers who need to get up to speed with a complex codebase, repeatedly. In maintenance mode, modifications will be less frequent than reads.
Ada was not my first language, and I was a little dubious about the keywords at first, but I quickly changed my mind. Now I wish every language did it (obviously, not literally every). It's really nice for a couple reasons.
One is just googling. You pretty much have a built-in shared lexicon, so there's no trying to remember the right name for the problematic symbol, or figuring out the best way to describe it.
There's also no trying to remember what symbol does the thing you want, which is really nice even when just coming back to a language feature you haven't used recently enough to be fresh on.
I have no idea how much these things would matter in a more structured environment. I pick up words way faster than symbols and my memory isn't so great, so I think it would have helped me even there. But I don't know how universal that is.
Though given the number of times I had to help the actual CS majors with basic syntax stuff, even after the 101 course... I can't help but suspect it would be useful.
But that talks about learning the language. What about once you're proficient?
I vaguely remember reading about a study that concluded more terse symbol-based syntax is better because the programmer can use visual organisation of the code to greater extent because the syntax occupies less of the screen. But I could also be making it up because I can't find it now.
There's also the interesting (but slightly irrelevant) result that abbreviated identifier names may be just as effective as ones spelled out![2]
[1]: https://dl.acm.org/doi/abs/10.1145/2534973
[2]: https://link.springer.com/article/10.1007/s11334-007-0031-2
A couple things D took from Ada were the in, out, and inout parameters, and embedding _ in numeric literals like 1_000_000.
The latter is so simple and so useful.
I still have my copy of MIL-STD-1815 on the shelf. No, you can't have it.
C is still holding out :-)
Edit: That bot is far too easy to be curious with, and unless I got my testing wrong, perl 2 (from 1988) seems to have been where it was added: https://perl.bot/p/jzyi91
All assistance convincing the rest of the world they should also adopt the feature is very much welcome though :D
"Achieved what perl had managed in 1988 and D in 2000" is not honestly a point in favour of languages who worked it out somewhere in the past decade.
I know C++ added it 14 years after D :-) but I'm curious why you say ' is a better choice? I never read the papers proposing the feature, but the _ hasn't caused any problems for us, and I like it better myself.
Also, I'm glad and honoured to have a comment like yours in my history. Sorry for late reply.
The John Barnes book mentioned in the article covers some of the differences between the Ada language versions.
Expression functions were added in Ada 2012 and directly support preconditions, postconditions, and various aspects in SPARK 2014.
Having a terse little file where I can scan the interface of a module, rather than having to scroll through the implementation and see which declarations have `public` in front of them, is a great way to quickly refresh your mental model of a module's API.
And it allows you to have both interface docstrings and implementation docstrings, which a documentation generator could use to compile an API guide for clients and a developer's guide for people working on the internals.
There's also another structured approach to the interface/implementation distinction: leave it up to the IDE to offer an interface explorer. This is the approach used by, say, Java.
I'm not sure that either approach is outright better than the other; it's a trade-off.
This is because it lets me read code in extra-IDE settings: browing GitHub, or in a patch file, or on a book. Or I can write code on paper.
Another benefit is that you can design a program entirely by writing the module interface files, and typechecking them against each other without an actual module body file.
Then, as you start actually implementing the program, you can implement one module at a time, typechecking it against the module interfaces of its dependencies, without said dependencies having any actual code in them. So you can write the actual implementation in whatever order makes sense.
The compiler would parse both the module interface and module body files, merge them and check for consistency, and produce both an object code file for the code in that module and a binary module interface that contains an efficiently serialized form of the interface, the bodies of generic functions, and maybe the table of monomorphic instances for separate compilation.
Then the build system makes sure to import the relevant binary interface files when building a project.
You only need to export the public parts of the templates.
As for interface vs. implementation docs, nothing precludes having both in a single file either.
Then for more modern languages where there's no separation some IDE's can auto-generate the interface declarations along with the associated comments. E.g. Xcode does it for Swift and it's kind of OK.
In Lazarus you can have the IDE do the syncing for you (Ctrl+Shift+C). Modern Delphi might have something similar (if not exactly the same thing).
unit Foo;
interface
type Weekday = (Mon, Tue, Wed, Thu, Fri);
procedure DoThisAt(Day: Weekday);
implementation
procedure DoThisAt(Day: Weekday);
begin
// stuff
end;
end.
(FWIW this is an old feature taken from Turbo Pascal which itself took it from UCSD Pascal)
That information is trivial to extract, there is no reason to force the developer to maintain it and keep it in sync.
> And it allows you to have both interface docstrings and implementation docstrings, which a documentation generator could use to compile an API guide for clients and a developer's guide for people working on the internals.
You could call these "docstring" and "comment".
A good IDE can then fold/collapse the in-code documentation, and the programmer can have it up in a separate window along side.
This could be an interesting model for literate programming. Instead of it being "linear", like reading a novel, it would be like reading a translation of an ancient text, with the original source material on one side of the page and both the translation and detailed reference notes on the other side. And of course there would be a hypertext component to the documentation, which would allow you to build a "table of contents" and jump around the codebase.
It's unclear what you mean by "linear" here. Surely your "translation of an ancient text" is a linear read following the "ancient text" it translates even if it has forwards and backwards references?
Knuth's original conception of literate programming was non-linear in terms of code, you'd write some text, write some bits of code, possibly add a reference to an other snippet, write some more text, write some more bits of code, and tangle then stitches the source back together by following references.
More "modern" literate programming is non-linear in terms of narrative, making the "comments" / "docstrings" the main content but then having the code execute "normally" ignoring said comments.
Jeremy Ashkenas's tools (e.g. undescore, backbone, …) are all written and published in that style even though Javascript is hardly conducive to it, and shown in exactly the "original source material on one side and translation and detailed notes" you seem to talk about on the other. That is what Ashkenas called "annotated source": https://backbonejs.org/docs/backbone.html, https://underscorejs.org/docs/underscore-esm.html.
Recent revisions of underscore have been modularised and show individual segments you can look between instead: https://underscorejs.org/docs/modules/index-all.html maybe that's what you're thinking of when you talk about it being non-linear?
It's missing some of the bits e.g. the symbols themselves are not hyperlinked and there is no glossary, but because in the modularized version each function is the sole export of its module it's easy to jump between functions. Not that I'm convinced this makes for a great experience as it requires keeping a lot in memory, but there you go.
That is the definition of the word, it’s not actually helpful in understanding what you’re thinking about.
> I am envisioning a system where the programmer has code in one window and the explanation of the code in another. Like a book with text on the left and annotations on the right.
So… literally what i posted.
> That information is trivial to extract, there is no reason to force the developer to maintain it and keep it in sync.
That's true, in theory. In reality though, when is that information extracted? What do you use to extract it? Where is it saved once extracted? How easy is it to review it? Do you need to use an IDE to do that?
Any less than satisfactory answer to these questions will make this worse in practice than having the developer maintain it.
> That's true, in theory. In reality though, when is that information extracted? What do you use to extract it? Where is it saved once extracted? How easy is it to review it? Do you need to use an IDE to do that?
I don't write Ada, but I have looked into it. I strongly dislike having to write an entire separate type/interface file that repeats the type definitions from the implementation.
This information exists -- a tool should be able to extract the signatures and spit out the interface file automatically (IE a header for C/C++)!
In Ada, this tool is called "gnatchop"
https://learn.adacore.com/courses/GNAT_Toolchain_Intro/chapt...
Instead of writing an ".ads" and ".adb" file (like ".h" and ".c"), you just write an ".ada" file and feed it to "gnatchop", it creates the two files for you and you're ready to compile.
gnatchop example.ada # (example.adb + example.ads created)
gprbuild p_main # (builds from example.adb)
https://gcc.gnu.org/onlinedocs/gnat_ugn/Interfacing-with-C_0...
https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/i...
It can take C/C++ headers and auto-generate the interop code you need as well
$ g++ -c -fdump-ada-spec -C /usr/include/time.h
$ gcc -c *.ads
https://gcc.gnu.org/onlinedocs/gnat_ugn/Generating-Bindings-...
A big part of why I like Ada so much is the fact it lets me hold such a strong mental model of the program. I can specify quite a bit about how it should all work, and the compiler holds me to it.
Most or all of that sort of information is tied up in the .ads file. If I want to refer to the model, I can check the .ads file, even if my project doesn't compile yet. Everything I need to know is there, from the very first line of code.
Most importantly, if I'm working in the .ads file, I'm changing the model. Changes here are Important. If I unknowingly make a change here, I've lost my understanding of the model. I really don't want that to be possible.
Meanwhile the .adb is more the implementation. If I'm changing the .adb, I'm just altering the details, but the overall model stays the same. Maybe what I'm doing in the .adb tells me I really do need to change the .ads because the model has a problem, but that doesn't mean I should just go make the easiest little change to the model that makes the .adb work.
Frankly, I think that extra little bit of friction in having two files that need to be in sync makes it easier to write better programs. Something as huge as changing the model should have something that helps cue me in that I'm doing something Big.
You could use your build system to extract it to a website (eg. https://docs.rs/)
If you rely on extracting the interface from the implementation then you have to have another mechanism to compare two implementations to see if they provide the same interface. That's kind of an insane way to do things from the Ada perspective. You've made things harder for yourself and less certain for the users of that interface.
Put the public bits into a package specification file so that anyone can know as the user or the implementer what is expected. Swap out implementations as needed and have high confidence that (short of logic errors in the implementation) it will at least provide the same interface because, well, it wouldn't compile otherwise.
Also, the specification files are a bit like C or C++ headers. You can write a program predicated on their correctness without actually needing an implementation to verify against. The *.ads files tell you "These functions, procedures, and types exist. I promise, so you can go about your business even though an implementation may not be available yet.
"Wait F# does?"
Yeah, but you won't have seen it because almost nobody uses it to the point where some tooling even has trouble understanding what it is. :(
Then there's the other-way of doing it: imagine a language with a database/browser (e.g. smalltalk), where the implementation is just linked and can be accessed in the-same/an-other window.
This sort of system could also have documentation-comments attached to the interface (e.g. for usage), and the implementation (e.g. for maintenance logging, rationale, etc).
congratulations you have used the most obscure part of the ada specifications
> Unfortunately, the top tiers of [SPARK] analyses are paid only, but you can get data/information flow analyses, as well as guarantee of no runtime errors for free.
That's not right. Straight from AdaCore's Yannick Moy, a year ago: [0]
> SPARK as included in GNAT Community allows you to go up to platinum level, with the 3 provers included (Alt-Ergo, CVC4 and Z3)
[0] https://old.reddit.com/r/ada/comments/hwgbwa/survey_on_the_f...
A much closer comparison would be Pascal. Which is another awesome language (I was gutted when the home computing industry moved away from Pascal and towards C).
As was I, Object Pascal was for it's time one of my all time favourite languages - it was so effortlessly boring it just got out the way.
To be clear, I'm not advocating this over the traditional approach of programs running discrete queries and handling the logic themselves - just saying that the approach taken by PL/SQL has its merits.
I'm not suggesting PL/SQL should be a fully fledged scripting language either (neither Perl nor Python are systems languages by the way). I'm just saying the two paradigms PL/SQL aims to leverage don't combine well so the end result is always going to be ugly.
Which, incidentally, can be used as procedural languages in Postgres (as well as TCL) as part of the standard distribution.
And there are third-party extensions for javascript, ruby, scheme, r, java, lua, … (though some of them may not be maintained anymore, the pg13 documentation doesn't list scheme and ruby anymore).
There are certainly things it can't do, and things it can do but only poorly, but that's true of anything.
I did use it for the right purposes. I was writing applications for Oracle Middleware. You don't get any more "right purposes" than that. And no, it really isn't a joy. Almost everyone I've ever met or spoken to hated PL/SQL (you being literally the one exception). I get that enjoyment is subjective but in this case it really feels like you're the anomalous data point.
I've not use PL/pgSQL so can't comment on how similar it is to Oracle PL/SQL but PostgreSQL is a much nice RDBMS to manage and write SQL for than Oracle is. So it wouldn't surprise me if PL/pgSQL had some quality of life improvements.
Working with plsql packages is like programming in pascal/modula 2 but with first class SQL support built in. A bit like linq in c#.
For example, I don't see how for cursor loops in plsql like documented here: https://www.oracletutorial.com/plsql-tutorial/plsql-cursor-f... are less elegant than doing something similar with java or python.
Which is no longer allowed in Modern software development influenced by Silicon Valley.
1) They think the fundamental elements of code are classes and methods on classes, or
2) They think the fundamental elements of code are functions.
Sometimes either of these also know there's something called a module or package, but the idea is loosely understood.
I was one of these people. If you're happy to stay that way, stop reading my comment now.
Ada is extremely well designed. One of the reasons is that the language design cleanly separates concepts normally bunched together into ideas like "everything is a class".
In many languages, if you want implementation hiding you get a whole bunch of other things with it. You can't use just implementation hiding without automatically opting into all parts of class-based programming, like inheritance, subclassing, etc.
Then you go "wait, what? Isn't inheritance and subclassing sort of the same thing?"
Yeah, no. Not fundamentally. It's only the same thing in popular programming languages because everything is the same thing in popular languages. Everything is a class and if you need anything you get the whole class concept, whether or not you wanted it.
This is problematic especially for beginner programmers because they learn implementation hiding is good. So they use that. But that opens up a huge toolbox of additional tools, not all of which are appropriate. But beginners are like beginners are, and when they see all those tools they simply use them -- sometimes out of desperation. This leads to messy code.
Ada is different. In Ada, you can pull out just the concepts you need, and it won't automatically opt you in to everything else.
A beginner that uses implementation hiding in Ada won't suddenly have an open toolbox full of subclassing. Their toolbox still contains just implementation hiding and whatever else they intentionally put in it. That leads to better code.
Just for that experience, Ada is worth learning, in my opinion.
Here are some quotes from TFA that alludes to this.
> Packages are namespaces for functions and types, unlike other languages where types can “contain” functions and types.
Organising code into subcomponents with implementation hiding is separated in Ada from class-based programming. You can do both, but you can also choose to do only one of them.
> Function overloading acts as a key design element
You can have polymorphism without opting into inheritance. (Further, you can have inheritance without opting into class-based programming.)
> Everything in a package is related, there’s no syntactical split between “free function”, “class function”, or “member function” (method).
You can have methods on types without opting into class-based programming.
> What most C-family languages call “functions”, Ada calls “subprograms”. Ada distinguishes between those which return a value and are truly “functions” and those which do not return a value, and are “procedures.”
A procedure is fundamentally different from a function from a reasoning-about-the-code perspective. You can have either without automatically opting into the other (as is the case when everything is a method.)
> Examples are “accesses” (sort of like pointers), “accesibility” (similar to a scope for borrowing), “tagged types” (classes), “derived types” (unrelated to OOP), and “subprogram”.
Using different words for different concepts -- instead of bundling them into the same generic idea -- increases the richness of your mental vocabulary which also increases the nuance your thoughts are able to express.
----
If you read my comment all the way down here, you might be interested in the Rust beginner's tutorial adapted to Ada, one of my more popular articles (which tells you something about my popularity...) https://two-wrongs.com/guessing-game-ada-style.html
They really are not unless the langage puts specific limitations or features on one or the other.
And odds are the average “procedure” should not be one, because it only exists for its side effect but then provides no feedback about these side effects.
Maybe we can agree on that they should be different, but in languages where all code is a method it is dangerous to assume they are different?
Why would we? And how should they be different, and what useful properties would that provide?
> in languages where all code is a method it is dangerous to assume they are different?
Why would you assume undifferentiated functions are different in the first place, and what would the difference be?
Functions should be similar to mathematical functions and come with guarantees like purity, referential transparency, and totality.
Another reason they should be different is they've got different names! Might seem trite to say that, but what's the point in having the same concept with different titles?
Pure functions are very powerful concepts, especially when it comes to composition, if the consumer of a function can't rely on that, then the consumer must investigate the internals to know what it does. Once you're several layers deep into your composition that becomes exponentially harder to do.
So, there is value to having a concept (with a suitable name, like 'function') that indicates to the consumer what it is they're dealing with. Some languages, like Haskell, bake this in; others like JS really don't - making the whole process of dealing with 'functions' (really procedures) much harder once an application is more than a toy project.
Essentially none of that is embodied in Ada's distinction between functions and procedures though, despite that being "fundamentally different […] from a reasoning-about-the-code perspective" according to the comment I replied to.
The only thing Ada tells you is "this definitely has side-effects" because there's no other reason to have a function without a return value, but that's the least useful thing you can be made aware of.
> Another reason they should be different is they've got different names! Might seem trite to say that, but what's the point in having the same concept with different titles?
Because you're very confused and making a distinction between things which are not different?
> Pure functions are very powerful concepts
That's debatable, but even then it's not what function means in Ada.
> especially when it comes to composition, if the consumer of a function can't rely on that, then the consumer must investigate the internals to know what it does.
Knowing what a function does is probably a good idea either way. You can call `map` with the same parameters as `filter` but the result will be rather different.
The restriction has been lifted only much later, so what you say is correct for modern Ada, not for the original Ada.
While gcc and other C and C++ compilers have non-standard extensions to specify whether a function is pure or not, I assume that an Ada compiler can recognize a pure function just by the fact that all its parameters are "in", so no extra keyword is needed.
What is needed is that the pure functions must be easily recognized by compilers and other tools and also by programmers. Not only there is no need that the functions be restricted to pure functions, that is actually undesirable.
AFAIK, unlike in C/C++, where pointers can make this task quite complex, in modern Ada it is still easy to recognize the pure functions.
On the other hand the distinction between "pure functions" and other kinds of functions or procedures is quite important.
In many early programming languages, the "functions" had to be what now are called "pure functions".
Later many languages relaxed the restrictions for "functions" allowing them to have side effects, but then the more important distinction was lost.
Only relatively recently many languages began to provide again means to specify that a function is a pure function.
Same goes for im/mutability, i think val/var is more elegant than let/let mut but that is only my opinion on aesthetics. I like good design but still think function is more important than form.
That is the reason why this distinction matters. The distinction between mutable and immutable variables matters for the same reason.
Otherwise, the difference between a "procedure" and a "function" with side effects where you ignore the return value has no practical consequences.
There are contexts where you do not care about the optimizations that can be done by the compiler or about program verification, but there are also contexts where you care.
2. Functions can be expression functions which can be set in the code specification or used in expressions. Procedures can be written only in packages' bodies.
3. Procedures can be set to no-return state: that kind of procedure doesn't end in the normal way, but, for example, only by raising an exception.
4. Procedures can be null procedures, empty. That not the same as abstract subprograms from other programming languages.
Also, the difference is, in my opinion, more visible in the safe subset of Ada, SPARK, where still exists the rule which forbids side effects on functions.
Interesting history of how there was supposed to be a difference, but the idea was dropped and then later revived by SPARK.
Differentiating between pure and impure functions might be useful[0], but while not strictly orthogonal the presence of a return value doesn't tell you anything about that. Even ignoring the error signalling, read(2) has a return value (the data being read) and also has side-effects.
[0] though it's debatable that this distinction is really useful in and of itself
GP said it depends on what the language does with that concept, and then I linked some extra info about what Ada and SPARK do with the concept.
As for whether it's useful ... it's absolutely useful.
Side effects break basic blocks. The smaller the basic blocks, the less optimization can be done.
Side effects also require special handling when using theorem provers. If you can specify that something should be free of side-effects, it's less work to requalify the system after making changes.
The purpose of SPARK is to be formally proven, which is why it implements the feature.
No sorry, inserting a tab is the actual quirky behavior.
Because we also used Ada as our first language there.
One of the language designers was the department head for programming languages and compiler construction.
They did have to stream that intro course anyway, because irrespective of familiar syntax some people "get it" and some don't. I remember the bottom stream were named "Strugglers" but I don't remember what the stream for people it comes as second nature to is called, most people move up and down a bunch e.g. maybe they were fine right up until currying, and they go all the way from "Attend one lecture a week, complete the assigned work in ten minutes, hand in and we're done" to "I need both classes and the extra one-on-one tutorial to even understand the assignment, let alone try to do it" overnight.
Today I believe they teach Java, or possibly Python, bowing to industry pressure to churn out people who can cut code on day one, as if that's the purpose of a three year degree. Interestingly the same university's IT department just hired me based on the rationale that although I don't actually know most of the technologies they're using, I clearly can just acquire everything needed as I go. So they don't believe this bullshit, but many people hiring their graduates do, and 18 year olds pick institutions with the best hiring rates.
- in 4 months of learning the language they've completed 7 projects
- they've read a 700 page book in a month
- they've made a ebook on ada
That's a little ironic, given ADA was originally a US government project.
Unfortunately, I was too narrow-minded to understand that it was a really interesting langage and not just a useless academic hobby of my teachers.
At least I do now, but I’m sad I was not more attentive at this time.
It would be like someone choosing Rust and then making everything unsafe. Or Haskell (I saw this in a tutorial once, it was hilarious and disgusting at the same time) and using strings (data) for dispatch instead of translating them into types and actually exercising the type system.
All that is to say, thoughtless programmers outnumber thoughtful ones. The language can only take you so far.
Feel free to send an email if you want to catch up.