They are not. The power of rich and succinct specification languages (like TLA+) comes from the ability to succinctly express things that cannot be efficiently computed, or at all. That is because a description of what a program does is necessarily at a higher level of abstraction than the program (i.e. there are many possible programs or even magical oracles that can do what a program does).
To give a contrived example, let's say you want to state that a particular computation terminates. To do it in a clear and concise manner, you want to express the property of termination (and prove that the computation satisfies it), but that property is not, itself, computable. There are some ways around it, but as a rule, a specification language is more convenient when it can describe things that cannot be executed.
When when you have a problem that perfectly fits the bill, they are very good at it.
The problem is they are terrible at everything else. I/O, data validation, manipulation strings, parsing, complex logic trees...
So I feel like just like regexes, there should be an array language parser embedded in most languages, that you opt in locally for just this little nudge.
In Python, it would be nice to be able to "import j" like you "import re" in the sdlib.
The entire J code base, including utility scripts, a console, a stdlib and a regex engine, is 3mb.
I think Iverson had a good idea growing language from math notation. Math operations often use one or few letters - log, sin, square, sign of sum or integral. Math is pretty generic, and I believe APL is generic as well.
and every new hire got taken to the whiteboard to learn about sort algorithm performance: bubblesort is O(n) in the best case.
and in our codebase, the data being sorted fit that best case (the data was already sorted or almost sorted).
I've been posting the manifesto to friends and colleagues every tau day for the past ten years. Let's keep chipping away at it and eventually we won't obfuscate radians for our kids anymore.
Friends don't let friends use pi!
Usually, when we're interested in termination proofs, what we're really interested in is a proof that the algorithm makes constant progress that converges on a solution.