Ada is a language that had a lot of useful features much earlier than any of the languages that are popular today, and some of those features are still missing from the languages easily available today.
In the beginning Ada has been criticized mainly for 2 reasons, it was claimed that it is too complex and it was criticized for being too verbose.
Today, the criticism about complexity seems naive, because many later languages have become much more complex than Ada, in many cases because they have started as simpler languages to which extra features have been added later, and because the need for such features had not been anticipated during the initial language design, adding them later was difficult, increasing the complexity of the updated language.
The criticism about verbosity is correct, but it could easily be solved by preserving the abstract Ada syntax and just replacing many tokens with less verbose symbols. This can easily be done with a source preprocessor, but this is avoided in most places, because then the source programs have a non-standard appearance.
It would have been good if the Ada standard had been updated to specify a standardized abbreviated syntax besides the classic syntax. This would not have been unusual, because several old languages have specified abbreviated and non-abbreviated syntactic alternatives, including languages like IBM PL/I or ALGOL 68. Even the language C had a more verbose syntactic alternative (with trigraphs), which has almost never been used, but nonetheless all C compilers had to support both the standard syntax and its trigraph alternative.
However, the real defect of Ada has been neither complexity nor verbosity, but expensive compilers and software tools, which have ensured its replacement by the free C/C++.
The so-called complexity of Ada has always been mitigated by the fact that besides its reference specification document, Ada always had a design rationale document accompanying the language specification. The rationale explained the reasons for the choices made when designing the language.
Such a rationale document would have been extremely useful for many other programming languages, which frequently include some obscure features whose purpose is not obvious, or which look like mistakes, even if sometimes there are good reasons for their existence.
When Ada was introduced, it was marketed as a language similar to Pascal. The reason is that at that time Pascal had become the language most frequently used for teaching programming in universities.
Fortunately the resemblances between Ada and Pascal are only superficial. In reality the Ada syntax and semantics are much more similar to earlier languages like ALGOL 68 and Xerox Mesa, which were languages far superior to Pascal.
The parent article mentions that Ada includes in the language specification the handling of concurrent tasks, instead of delegating such things to a system library (task = term used by IBM since 1964 for what now is normally called "thread", a term first used in 1966 in some Multics documents and popularized much later by the Mach operating system).
However, I do not believe that this is a valuable feature of Ada. You can indeed build any concurrent applications around the Ada mechanism of task "rendez-vous", but I think that this concept is a little too high-level.
It incorporates 2 lower level actions, and for the highest efficiency in implementations sometimes it may be necessary to have access to the lowest level actions. This means that sometimes using a system library for implementing the communication between concurrent threads may provide higher performance than the built-in Ada concurrency primitives.
Verbosity is a feature not a bug. Programming is a human activity and thus should use human language and avoid encoded forms that require decoding to understand. The use of abbreviations should be avoided as it obsfucates the meaning and purpose of code from a reader.
The programming community is strongly divided between those who believe that verbosity is a feature and not a bug and those who believe that verbosity is a bug and not a feature.
A reconciliation between these 2 camps appears impossible. Therefore I think that the ideal programming language should admit 2 equivalent representations, to satisfy both kinds of people.
The pro-verbose camp argues that they cannot remember many different symbols, so they prefer long texts using keywords resembling a natural language.
The anti-verbose camp, to which I belong, argues that they can remember mathematical symbols and other such symbols, and that for them it is much more important to see on a screen an amount of program as big as possible, to avoid the need of moving back and forth through the source text.
Both camps claim that what they support is the way to make the easiest to read source programs, and this must indeed be true for themselves.
So it seems that it is impossible to choose rules that can ensure the best readability for all program readers or maintainers.
My opinion is that source programs must not be stored and edited as text, but as abstract syntax trees. The program source editors and viewers should implement multiple kinds of views for the same source program, according to the taste of the user.
It is not that I cannot remember the symbols - I don't want to; I want the language to plainly explain itself to me. Furthermore every language has it's own set of unique symbols. For new readers to a language you first have to familiarize yourself with the new symbols. I remember my first few times reading rust... It still makes my head spin. I had to keep looking up what everything did. If the plain keyword doesn't directly tell you what it's doing at least it hints at it.
To be clear Ada specifically talks about all this in the Ada reference manual in the Introduction. It was specifically designed for readers as opposed to writers for very good reasons and it explains why. It's exactly one of the features other languages will eventually learn they need and will independently "discover" some number of years in the future.
Rust has a complex semantics, not a complicated syntax. The syntax was explicitly chosen to be quite C/C++ like while streamlining some aspects of it (e.g. the terrible type-ascription syntax, replaced with `let name: type`).
I agree that the use of symbols becomes a problem when you use many programming languages and each of them uses different symbols.
This has never been solved, but it could have been solved if there would have been a standard about the use of symbols in programming languages and all languages would have followed it.
Nevertheless, for some symbols this problem does not arise, e.g. when traditional mathematical symbols are used, which are now available in Unicode.
Many such symbols have been used for centuries and I hate their replacements that had to be chosen due to the constraints of the ASCII character set.
Some of the APL symbols are straightforward extensions of the traditional mathematical notation, so their use also makes sense.
Besides the use of mathematical symbols in expressions, classic or Iverson, the part where I most intensely want symbols, not keywords, is for the various kind of statement brackets.
I consider the use of a single kind of statement brackets as being very wrong for program readability. This was introduced in ALGOL 60 (December 1958) as the pair "begin" and "end". Other languages have followed ALGOL 60. CPl has replaced the statement brackets with paragraph symbols (August 1963), and then the language B (the predecessor of C) has transitioned to ASCII so it has replaced the CPL symbols with curly braces, sometimes around 1970.
A better syntax was introduced by ALGOL 68, which is frequently referred to as "fully bracketed syntax".
In such a syntax different kinds of brackets are used for distinct kinds of program structures, e.g. for blocks, for loops and for conditional structures. This kind of syntax can avoid any ambiguities and it also leads to a total number of separators, parentheses, brackets and braces that is lower than in C and similar languages, despite being "fully bracketed". (For instance in C you must write "while (condition) {statements;}" with 6 syntactic tokens, while in a fully bracketed language you would write "while condition do statements done", with only 3 syntactic tokens)
If you use a fully bracketed syntax, the number of syntactic tokens is actually the smallest that ensures a non-ambiguous grammar, but if the tokens are keywords the language can still appear as too verbose.
The verbosity can be reduced a lot if you use different kinds of brackets provided by Unicode, instead of using bracket pairs like "if"/"end if", "loop"/"end loop" or the like.
For instance, one can use curly braces for blocks, angle brackets for conditional expressions or statements, double angle brackets for switch/case, bag delimiters for loops, and so on. One could choose to use different kinds of brackets for inner blocks and for function bodies, and also different kinds of brackets for type definitions.
In my opinion, the use of many different kinds of brackets is the main feature that can reduce program verbosity in comparison with something like Ada.
Moreover, the use of many kinds of brackets is pretty much self describing, like also in HTML or XML. When you see the opening bracket, you can usually recognize what kind of pattern starts, e.g. that it is a function body, a loop, a block, a conditional structure etc., and you also know how the corresponding closing bracket will look. Thus, when you see a closing bracket of the correct shape you can know what it ends, even when you had not known previously the assignment between different kinds of brackets and different kinds of program structures.
In languages like C, it is frequently annoying when you see many closing braces and you do not know what they terminate. Your editor will find the matching brace, but that wastes precious time. You can comment the closing braces, but that becomes much more verbose than even Ada.
So for me the better solution is to use graphically-distinct brackets. Unicode provides many suitable bracket pairs. There are programming fonts, like JetBrains Mono, which provide many Unicode mathematical symbols and bracket pairs.
When I program for myself, I use such symbols and I use a text preprocessor before passing the program to a compiler.
This opens a possibility for a middle ground. A language which is not-too-verbose, and doesn't have too many symbols would perhaps reconcile some of them.
As for storing sources as AST, that would effectively make them unreadable for most programmers. Or maybe it would basically turn every language into LISP.
I agree. I've never understood or accepted the claim that Ada is verbose. It's simply clear and expressive. If there were some alternative concise syntax for "Ada" then I would not want to use it (because it would not be Ada).
Because that is a joke, it proposes replacements only for a small set of Ada tokens and it is not clear how the proposal can be cleanly extended to the full set of Ada tokens.
Nevertheless in is possible to define a complete 1 to 1 mapping of all Ada syntactic tokens to a different set of tokens.
The resulting language will have exactly the same abstract syntax as Ada, so it is definitely exactly the same language, only with a different appearance.
For a seasoned Ada programmer, changing the appearance of the language may be repugnant, but for a newbie there may be no difference between two alternative sets of tokens, especially when the programmers are not native English speakers, so they do not feel any particular loyalty to words like "begin" and "loop", so they may not feel any advantage of using them instead of using some kind of brackets that would replace them.
I think there is a significant difference between choosing to use words (from some language) versus using brackets like {}, () and []. With nested brackets there are often debates over placement and it is usually less clear what scope is being ended by the closing bracket.
Indeed, the fact that is not clear what scope is being ended by the closing bracket is very serious.
This is why much more bracket pairs are needed in a programming language than the 3 pairs provided by ASCII.
Ada uses many pairs of brackets, but most of them are implemented with keywords, for instance if => end if, loop => end loop, and so on.
These long keyword-based brackets can be replaced with various Unicode bracket pairs that are graphically distinct.
Such brackets, for instance angle brackets instead of "if"/"end if", take much less space and they are also much more salient than keywords, which for me improves a lot the readability of the text.
Even if you do not know before that how the brackets are assigned, by reading the text you can discover very quickly the correspondence, because you can recognize what kind of structure is started by a certain kind of bracket, and then you know that when you will see a closing bracket of the same shape that is the end of the structure.
Verbosity is a feature for small self-contained programs, and a bug for everything else. As long as you're using recognizable mnemonics and not just ASCII line noise or weird unreadable runes (as with APL) terseness is no obstacle at all for a good programmer.
> Today, the criticism about complexity seems naive, because many later languages have become much more complex than Ada
I don’t think you really understand what you’re saying here. I have worked on an ada compiler for the best part of a decade. It’s one of the most complex languages there is, up there with C++ and C#, and probably rust
Mind you, that suggests that the sentence is at least half-true even if "much more complex" is a big overstatement, since Rust, "modern" C++ and the later evolutions of C# are all relatively recent. (What would have compared to Ada in complexity back in the day? Common Lisp, Algol 68?)
As a matter of general interest, what features or elements of Ada make it particularly hard to compile, or compile well? (And are there parts which look like they might be difficult to manage but aren't?)
You're right in your first part. Ada 83 is less complex than modern C++ or Rust. However Ada kept evolving, and a lot of complexity was added in later revisions, such as Ada 95, which added a kind of bastardized and very complex Java style object model layer.
Ada features that are hard to compile are very common in the language. It is generally a language that is hard to compile to efficient code, because rules were conceived in an abstract notion of what safety is. But in general Ada is an extremely over specified language, which leaves very little space to interpretation. You can check the Ada reference manual if you want, which is a use 1000 pages book (http://www.ada-auth.org/arm.html)
* Array types are very powerful and very complicated
* Tasking & threading are specified in the language, which seems good on paper, but the abstractions are not very efficient and of tremendous complexity to implement.
* Ada's generic model is very hard to compile efficiently. It was designed in a way that tried to make it possible to compile down both to a "shared implementation" approach, as well as down to a monomorphized approach. Mistakes were done down the line wrt the specification of generics which made compiling them to shared generics almost impossible, which is why some compiler vendors didn't support some features of the language at all.
* Ada scoping & module system is of immense complexity
* The type system is very vast. Ada's name & type resolution algorithm is extremely complex to implement. functions can be overloaded on both parameters & return types, and there is a enclosing context that determines which overloads will be used in the end. On top of that you have preferences rules for some functions & types, subtyping, derived types, etc ...
This is just what comes to mind on a late Friday evening :) I would say that the language is so complex that writing a new compiler is one of those herculean efforts that reach similar heights as writing a new C++ compiler.
That's just a fe
what do you mean under Ada's complexity?
E.g. C++ is really complex because of a lot of features which badly interoperate between themselves.
Is this true for the Ada lang/compiler? Or do you mean the whole complexity of ideas included in Ada - like proof of Poincaré conjecture complex for unprepared person.
Yes, Ada has a lot of the same kind of fractal complexity that C++ has, which derives from unforeseen interaction of some features with some other.
On top of that, as I said in another comment, features are extremely overspecified. The standard specifies what has to be done in every edge case, often with a specification that is not very practical to implement efficiently
In the beginning Ada has been criticized mainly for 2 reasons, it was claimed that it is too complex and it was criticized for being too verbose.
Today, the criticism about complexity seems naive, because many later languages have become much more complex than Ada, in many cases because they have started as simpler languages to which extra features have been added later, and because the need for such features had not been anticipated during the initial language design, adding them later was difficult, increasing the complexity of the updated language.
The criticism about verbosity is correct, but it could easily be solved by preserving the abstract Ada syntax and just replacing many tokens with less verbose symbols. This can easily be done with a source preprocessor, but this is avoided in most places, because then the source programs have a non-standard appearance.
It would have been good if the Ada standard had been updated to specify a standardized abbreviated syntax besides the classic syntax. This would not have been unusual, because several old languages have specified abbreviated and non-abbreviated syntactic alternatives, including languages like IBM PL/I or ALGOL 68. Even the language C had a more verbose syntactic alternative (with trigraphs), which has almost never been used, but nonetheless all C compilers had to support both the standard syntax and its trigraph alternative.
However, the real defect of Ada has been neither complexity nor verbosity, but expensive compilers and software tools, which have ensured its replacement by the free C/C++.
The so-called complexity of Ada has always been mitigated by the fact that besides its reference specification document, Ada always had a design rationale document accompanying the language specification. The rationale explained the reasons for the choices made when designing the language.
Such a rationale document would have been extremely useful for many other programming languages, which frequently include some obscure features whose purpose is not obvious, or which look like mistakes, even if sometimes there are good reasons for their existence.
When Ada was introduced, it was marketed as a language similar to Pascal. The reason is that at that time Pascal had become the language most frequently used for teaching programming in universities.
Fortunately the resemblances between Ada and Pascal are only superficial. In reality the Ada syntax and semantics are much more similar to earlier languages like ALGOL 68 and Xerox Mesa, which were languages far superior to Pascal.
The parent article mentions that Ada includes in the language specification the handling of concurrent tasks, instead of delegating such things to a system library (task = term used by IBM since 1964 for what now is normally called "thread", a term first used in 1966 in some Multics documents and popularized much later by the Mach operating system).
However, I do not believe that this is a valuable feature of Ada. You can indeed build any concurrent applications around the Ada mechanism of task "rendez-vous", but I think that this concept is a little too high-level.
It incorporates 2 lower level actions, and for the highest efficiency in implementations sometimes it may be necessary to have access to the lowest level actions. This means that sometimes using a system library for implementing the communication between concurrent threads may provide higher performance than the built-in Ada concurrency primitives.