Clutter. In language-design.

Let's talk JUST about computer programming languages. ( Let's NOT talk about how many ways there are to say the same thing in regular languages like English. ( What's "formal English" to one person, is just "some informal natural language" to another. ) )

• 1. Too many ways to write a loop. There should be only one.
• 2. Too many ways to address a dictionary/ map. TSBOO
• 3. Too many ways to define a block/ function/ subroutine/ scope. ( All "objects" in OOP, are mere managed scopes. ) TSBOO
• 4. Too many ways to address blocks ( et tu, "modules" ) and to mark dependencies upon each other. FORTUNATELY this is usually terse, but perhaps it could be improved further. 
• 5. Too many ways for blocks to interop. FORTUNATELY the pattern of errors as values is getting more popular.
• 6. There are four kinds of brackety-looking-things in ASCII. Maybe they should all mean the same thing.
• 7. Maybe compilers should have some sort of DRY/tsboo error code.
• 8. And because there are so many languages as a result, we don't have a single SIRII ... a standard intermediate representation for information interchange. ( XKCD#927 )

But if we had only one, then all language designers could just target that, for academic purposes, while still doing whatever else they wanted outside of academia.

Discussion :

• My general intuition is that there are multiple equivalent notations, which can capture the performances of any working programming language. Turing equivalence seems related.
• 2025-05-30 : Differentiating between the class of Data Types and the class of Data Structures is stupid. All data types are esteemed as a particular data structure in a/the symbol table, without which they would simply be bits and bytes. 
• Environments are just symbol tables, and can be first-class entities.
• Blocks are often first-class entities, and if all blocks are treated as expressions, then every block has a type, also ... commonly this is the final sub-expression within the block.
• Statements (imperative, verb-al) and declarations (descriptive, adjective-al) can be unified under the class of expressions; statements are just presently-instantiated declarations, declarations are broadly-applied statements, and any of these evaluates to a return value.
• ( so far this is pretty close to a Lisp, in that every (con(s)truct), is a block, and an expression ... with potential imperative, and descriptive, exports ... closed under the context of an environment; just that in Lisp the environment is implicit, and in this language design we'd we'd want to make the environment a first-class object, just like the (con(s)truct) )
• Anyhow, maybe we can also say there are no other first-class entities ... if every primitive can only be returned in boxed/ blocked/ containerised form.
• Allow : [ [ inabox1], [inabox2], [inabox3] ] => [ inabox1, inabox2, inabox3 ]
• Require : !inabox => [inabox]
• Require : nullish => []
• What are the unboxing conventions? : [[inabox]] => [inabox] ?
• Require the first Allow above, as a convention?
• TODO
• Where does block application / evaluation fit in?
• Implicit quotes : [ unevaluated&stable ] and therefore explicit eval [ eval, unevaluated&abouttobeevaluated ] or
• Explicit quotes : [ quote, unevaluated&table ] and therefore implicit eval [ unevaluated&abouttobeevaluted] etc.?
• Are boxes 1y-linked, or 2y-linked lists?
• [ quote, inabox1, inabox2 ], or [ quote, [ inabox1, inabox2 ] ], or [ quote, [ inabox1, [ inabox2 ] ] ] ?
• [ what is a struct equivalent? ], are those then simply modified to become classes "[ class, etc. ]" and objects? seems so, if we want first-class objects, which are used to implement environmental symbol tables