Curiously I find myself disagreeing quite a bit with Larry.
> If a language is designed so that you can "learn as you go", then the expectation is that everyone is learning, and that's okay.
It's okay if we never reach understanding or agreement on what Faulkner intended by a particular sentence (we can still grasp most of the whole). For a programming language this is explicitly not okay! This goes for ambiguity as well.
> Multiple ways to say the same thing
> This one is more of an anthropological feature. People not only learn as they go, but come from different backgrounds, and will learn a different subset of the language first.
This increases cognative load with no particular benefit.
For the former, I think Larry does not imply a post-modernist “death of the author” position: there is still an objectively correct interpretation of the code as the author intended, but it may be understood differently by people of different experience levels. For example, a map with reference to a sub can be though of as a loop that calls the sub.
With perl, the objective truth is opcodes, which are well-understood by a small group. Everyone else bases their understanding on heuristics and analogies, and the goal is to write your code to trigger the same heuristics/etc. in the reader.
For the latter, you are declaring your opinion as fact. Every language allows redundancy and variation of expression; if it truly provided no benefit, why have we not seen a popular language that only allowed a single expressive style?
> For the latter, you are declaring your opinion as fact. Every language allows redundancy and variation of expression; if it truly provided no benefit, why have we not seen a popular language that only allowed a single expressive style?
It is indeed my opinion (as prefaced by 'I find myself disagreeing..') but the premise that a programming language benefits from resembling or mimicking features of natural languages is also an opinion.
Also I should note that your phrasing of the question isn't quite correct ("if it truly provided no benefit"), something that provides no benefit is unlikely to be excluded from a language (e.g. double negatives "there ain't nothing here to see!") unless there is a clear benefit to doing so, and in fact there are times that there is.
Particularly I would draw your attention to for example more limited lexicon sets (such as those used by dispatchers, rescue workers, climbers, EMT professionals etc.). Those explicitly exclude variation of expression, since that leads to an increased risk of being misinterpretation in often critical situations. It is my inclination that while interpretation of code isn't time critical, reducing variance (e.g. a common coding style does this as well) reduces cognitive load (makes comprehension more efficient).
> If a language is designed so that you can "learn as you go", then the expectation is that everyone is learning, and that's okay.
It's okay if we never reach understanding or agreement on what Faulkner intended by a particular sentence (we can still grasp most of the whole). For a programming language this is explicitly not okay! This goes for ambiguity as well.
> Multiple ways to say the same thing
> This one is more of an anthropological feature. People not only learn as they go, but come from different backgrounds, and will learn a different subset of the language first.
This increases cognative load with no particular benefit.