Thoughts on Ada so Far I came across a quote about Ada lately which amused me, from the respectable designer Niklaus Wirth: ``There is too much falling out on the programmer. I don't think that, having studied a third of Ada, it is possible to work normally. If you don't master all the details of the language, then in the future you may stumble on them, and this will lead to unpleasant consequences.'' This amuses me from its truth, as I recently learned. I was mulling over the use of my trie library Less_Trivial_Trie and noticed controlled types are needed to avoid resource leaks when handling more complex values of Stored_Type, the parameter indicating that type which the trie holds in each node. I read sections of the Annotated Ada Reference Manual (AARM) often, but have mostly only skimmed the section detailing controlled types; nevertheless, I was familiar with many of the pitfalls and other rules which I must observe when using them; I'd however forgotten a rather basic rule concerning the finalization of controlled types, such as Ada.Strings.Unbounded.Unbounded_String when I reviewed its implementation in GNU, namely how Finalize is called before Adjust, solving every little problem I'd thought myself to have noticed with the implementation, in my noticed confusion. I was able to drop or lack this knowledge for so long, for I don't use controlled types, only limited controlled types. I must admit it's deeply unpleasant in some ways to use a language I only mostly understand. I need to sit down and read the entire AARM, beginning-to-end, at some point, as I've done with both Common Lisp and APL; I've long had the correct impression that Ada's rules are easier to understand than to specify, meaning they're meant for man over machine, but that's still no reason not to learn them in time. The Ada I've written is easy to review, and it's still worthwhile to review correct code too, for I don't expect to find further flaws in the simple code I've carefully written over these years. In comparison to Common Lisp and APL, I find Ada to be much nicer in some ways; it's common in those two languages to use implicit behaviour which simply so happens to suit the particular program, like the ``fill elements'' of APL used to adjust an array, or the array specializations guaranteed by the Common Lisp standard which make certain kinds of type checking easier, but only in some cases. Ada, in contrast, cuts down implicit behaviour and has very specific restrictions very easy to implement. It's much more difficult to implement very concise mechanisms in Ada, but every nicety has its cost. None of the languages I use are perfect, and I don't believe the ``languages'' to be the finality of computer programming, but the languages I choose to use are certainly that floor on which I walk. I deign not to use anything worse than my chosen languages; they are the floor to which all others are to be compared. The many worse languages are hardly worthy even of the disgust and scorn I provide. I believe no languages currently existing will last another century, or I'd rather that not be so in any way, but Ada's most certainly a language built to last and is better than many other candidates.