Clarity of Expression

For software programs, there are three conflicting goals.

First, the programmer has to express their understanding of the problems they are trying to solve.

Next, the computer has to understand the programmer’s instructions and do the right thing.

Third, other programmers will have to read the code and figure out what was intended to verify, change, or extend it. Code is never finished.

Some languages add all sorts of syntactic sugar and implicit mechanics in order to make it faster for a programmers to express themselves.

Those features can trick the original programmer into not fully understanding why specific behaviors are occurring. Things seem to work, they don’t really know why.

It can lead to ambiguities in the way the code executes.

But more importantly, it convolutes the code so that other programmers can’t easily understand what was intended.

It moves the language closer to what is known as ‘write once, read never’ code. Where it is impossible to see the full scope of expression, so you pretty much have to just run it to see what it does then decide if you like that based on very limited experience.

As languages mature, people often add more and more syntactic sugar or magical implicit handling. They believe that are helping the programmers write code faster, but really they're just making it all too complicated and unreadable. They are negative value.

For a really simple language, it is often important to utilize all aspects of it.

For a mature language, the opposite is true, you just want to pick a reasonable subset that best expresses your intent. Overusing all of the later language features just impairs readability. It’s a balance, you need to use just enough to make your expression crystal clear.The thing you are doing is not trying to save your own time, but rather get the meaning and intent to shine through. Code that is never read tends to get replaced quickly.