Zen of Ada
This observation was first published in my old blog back in 2014.
When I got interested in the Ada language, I've inevitably learnt of the Steelman document—a set of requirements for the new programming language for mission critical applications. Ada was designed specifically to meet those requirements, and its designers did an excellent work.
When I started learning Ada, I already knew Python, and of course I also knew of the Zen of Python, which is available in the REPL as an easter egg (type ”import this”), and I noticed that many points from it seem to echo the Steelman requirements, at least in its part that defines general language design and not specific requirements for a compiled, systems level, realtime language.
I don't know if Zen of Python was directly influenced by the Steelman document, or it's a result of convergent evolution, but they bear a striking similarity in their spirit. Perhaps it's simply because they should be requirements for any well designed language!
For convenience I put the matching paragraphs side by side.
| Zen of Python | Steelman requirements |
|---|---|
| Explicit is better than implicit. | The language should encourage user documentation of programs. It shall require explicit specification of programmer decisions and shall provide defaults only for instances where the default is stated in the language definition, is always meaningful, reflects the most frequent usage in programs, and may be explicitly overridden. |
| Simple is better than complex. Complex is better than complicated. | The language should not contain unnecessary complexity. It should have a consistent semantic structure that minimizes the number of underlying concepts. |
| Readability counts. | The language should promote ease of program maintenance. It should emphasize program readability (i.e., clarity, understandability, and modifiability of programs). |
| Special cases aren’t special enough to break the rules. | It should have few special cases and should be composed from features that are individually simple in their semantics. |
| Errors should never pass silently. | The language shall be designed to avoid error prone features and to maximize automatic detection of programming errors. [...] There shall be an exception handling mechanism for responding to unplanned error situations detected in declarations and statements during execution. |
| Unless explicitly silenced. | It shall be possible during translation to suppress individually the execution time detection of exceptions within a given scope. |
| In the face of ambiguity, refuse the temptation to guess. | Translators shall produce explanatory diagnostic and warning messages, but shall not attempt to correct programming errors. |
| There should be one– and preferably only one –obvious way to do it. | The language should have uniform syntactic conventions and should not provide several notations for the same concept. |
| Namespaces are one honking great idea – let’s do more of those! | The language shall distinguish between open scopes (i.e., those that are automatically included in the scope of more globally declared variables) and closed scopes (i.e., those in which nonlocal variables must be explicitly Imported). Bodies of functions, procedures, and processes shall be closed scopes. Bodies of classical control structures shall be open scopes. |