Good succinctness is, to me, not having to deal with things irrelevant the context of whatever you're trying to accomplish. For example

    for (Iterator<Thing> it = items.iterator(); iterator.next(); !iterator.done()) { Thing t = it.current(); ... }

is worse code than

    for (Thing t : items) { ... }

in most cases (though there are exceptions such as if you need to call `it.remove()` or something like that in the loop occasionally).

Bad succinctness is when, for the sake of shorter code, you have to introduce rather than remove concepts that are not directly related to the goal you're trying to accomplish and that cause extra mental load next time someone's trying to work with that code. To avoid saying anything too controversial, I'm sure everyone can think of their own examples here.

I like to say that the best solutions tend to "look like" the problems they are solving. Solutions can't be succinct if the problem isn't succinct. But they can limit any new concepts to a minimum, reusing the concepts of the problem space as much as possible, and thus being succinct in that way. A great example of this is OOP (admittedly out of fashion today), which reuses the natural concept of "object" and its traits, making it easy to map the problem space to the code that provides a solution.

I've long long wanted a code-mod that can go add explicit typing to a file, and another that can turn it off.

Yeah you can go poke around at your IDE and hover over things to see implicit types, but being able just read on the screen what everything is can be super helpful to newcomers or someone returning after a long weekend. It's also wonderful seeing the ripple of changes across the codebase as functions start returning different things, seeing explicit types update.

Ideally we could write & get the succinct form, but be saving in code in explicit form. IMHO.

Succinctness is useful except when it is simply a form of text compression that forces the reader/programmer to uncompress the semantics in their head.

"When, if ever, is a language too succinct for its own good?"

I'm pretty sure that K would be an answer.

For writing standard IT apps... likely. For doing data analysis on trades? I think it makes a lot of sense. It isn't a DSL for analytics, but is pretty close in a lot of ways.

Regarding Python, I find it a pretty darn good combination of readability and succinctness. Every time I tried to move away from Python to something I was told was better...I ended up back at Python as both the language and ecosystem were convenient. That includes lisp where when I went through several books...I kept thinking how much easier something was in Python. Obviously lisp's homoiconicity makes it more powerful, but that's a power I've never needed.

Edit: I do largely write scripts though and few programs are 10,000 lines or longer. I imagine I might struggle more with bookkeeping with an extremely large codebase. Maybe not, but I wanted to acknowledge my use may be atypical here.

What I ultimately care about in a language is productivity and joy (but there's a strong correlation between them, so let's simplify to just one criterion, productivity)

I feel most productive in Swift and Julia (more so than in Common Lisp or Clojure) and some kind of a mix of those would be my ideal language.

One of the keys to productivity is how much mental effort does it take to understand the code doing some thing (for example arithmetic expressions in Lisp).

It seems to me that power is really 'what are you able to do', and I guess a part of that is how long it takes to do it.

But another factor is how much skill/knowledge you must have and how much effort you must expend to do the thing.

In that light, succinct languages are often not so powerful, at least for most people, and even in expert hands power is often quite focused.

Then this blog post isn't very powerful.