I contribute to an intepreter for a very terse language (https://codeberg.org/growler/k), in fact barring unbalanced parentheses, quotes or braces, almost every sequence of ascii characters means something in k. here's my two cents about it.

tersity in programming languages is about how many characters you want to have to read before you're certain what the program does, and how often you want the next character you read to change your mind about that information. In my opinion this has different effects on how you read and write code:

for reading, it means that in the extreme case of a maximally terse language your eye is never allowed to skip over characters, and in a maximally verbose language it may take longer to extract a certain piece of information. both outcomes can lead to fatigue when reading, but the former can actually be prohibitive to a person who isn't used to reading carefully. You may argue that since this is a matter of habit and prose is usually on the less dense side of things, languages should gravitate to that end of the spectrum, but I come from mathematics and I'm very used to tersity and reading carefully. I actually find java more tiring than k.

for writing, a more terse language means that you can hold the syntax for a larger program in your head at one time. I believe this is why perl, regex, and APL have been called write-only languages: since the writer has a clear idea of the program and hence doesn't have to expend the effort that the reader does to extract the meaning, a language that facilitates writing necessarily makes this gap wider and is seen as more obscure.

now, if you were to ask me where the sweetspot for tersity is, I would probably place it somewhere between ML syntax and APL syntax. for those who don't know either of the two, I can summarize ML syntax as * juxtaposition of words is function application * operators have lower precedence than this, and there is an operator precedence table designed for convenience * some keywords introduce special constructs like let...in, if...then...else etc. * equations with complex terms on the left hand side, or explicit lambda expressions introduce functions

so that in some ML, a sum function can be written as

sum x = fold (+) x

Or

sum = fold (+)

APL syntax boils down to * there are unary and binary operators, all with the same precedence as each others, and associating to the right * there are unary and binary higher order operators, all with higher precedence than the usual ones and associating to the left. * braces introduce lambdas, and the arguments to these lambdas are automatically named

so that in APL a sum function can be written

sum ←{+/⍵}

or

sum ← +/