As is often the case, a compromise needs to be found: In general, programs should be as fast as possible. Complexity can be a major obstacle if no one can understand it anymore. So if speed isn’t really important, it can make sense to write slightly slower, but easy-to-understand program code.
3. Code-Mode
Some developers have a strong preference for things like the new operators in JavaScript (such as ellipsis) because, in their eyes, the resulting code is more concise and therefore better. But it is doubtful whether this is easier to understand in any case. This requires you to first become familiar with these operators. So instead of being able to quickly and thoroughly skim through the code, it becomes an annoying, absorbing chore.
There is also historical evidence that more concise code is not necessarily popular. It’s not for nothing that languages like APL, which were supposed to be particularly efficient and concise thanks to custom symbology, have essentially disappeared. Languages such as Python, which do not use curly brackets at all, are becoming increasingly popular.
4. Abstractions
Clever abstractions that solve specific problems more quickly are commonplace in many programming languages. Some languages are so overloaded with abstractions that their manuals end up filling more than a thousand pages. Using these features whenever possible is the law in the eyes of some. The problem in practice, however, is that too many functions can quickly cause confusion. And there are now so many syntactic tricks that no developer in the world can master them all. And why should you? How many ways do we need to test for null values or enable inheritance in multiple dimensions?
However, there are also countermovements: The creators of Go have set themselves the goal of developing a language that can be learned particularly quickly. The basic requirement for this: everyone in the team had to be able to read and understand all of the code.
5. DIY-Code
Efficiency experts like to recommend not reinventing the wheel, but instead relying on proven libraries and legacy code. However, in some cases a new approach may make sense. After all, standard libraries are usually made for everyday use cases. For specific use cases in which these libraries tend to represent a bottleneck, just a few individual lines of code or replacement functions can ensure that everything runs much faster.
