"Use succinct languages" is somewhat at odds with "Write rereadable code." There's a point beyond which making your code more succinct makes it more difficult for a human to parse. This can be somewhat mitigated by comments but I'd rather just read more readable code than more succinct code.
I completely disagree.
It's possible to write code so succinct that making it more verbose would make it more understandable.
But overly verbose code is far, far more common. And having a naturally succinct language does not stop you from keeping your code verbose. Just gives you more ways to make your code succinct that aren't possible in non-succinct languages.
(Not this is orthogonal to weaker or stronger compile time type systems. Type systems that catch more errors at compile time are very useful. But some strongly compile-time typed languages are still quite succinct.)
I think this is addressed in the link under that section
https://paulgraham.com/power.html
> I think that the main reason we take the trouble to develop high-level languages is to get leverage, so that we can say (and more importantly, think) in 10 lines of a high-level language what would require 1000 lines of machine language.
...
> 5. Write rereadable code. All programmers know it's good to write readable code. [...] If you're writing for other people, you may not want to make code too dense. Some parts of a program may be easiest to read if you spread things out [...] Whereas if you're writing code to make it easy to reload into your head, it may be best to go for brevity.
Sure, but it's all so vacuously ambiguous that it doesn't really matter. I hate advice lists like this because it can essentially be summarized by saying "write good code" and you'd be left with almost exactly as much wisdom.
What does "succinct" mean? Well, it means terse but not too terse. What does "readable" mean? It means I can easily understand it.
How is this helpful?