[philliphaydon]

Nope. Less code is not always better. Collapsing a loop into a single line lambda with single char variables doing 5 times is not elegant or better. It’s orders of magnitude worse.

Less code is more readable. But absolute minimal amount of code can be unreadable.

[jxf]

"Less" doesn't mean "fewer bytes", it means "less complexity". If two ASTs do exactly the same thing, but one is easier to understand and has less structure, that one is probably better.

[kamaal]

Less complex in lots of situations means being explicit, not being too template'y, not being too generic, abstract and writing code that is supposed to be a kind of meta that takes in a config and does several things for several inputs.

Writing less complex code in lots of situations just means writing lots of code. Which is diametrically opposite to the original statement of less code being better.

[jacob019]

Being kind of meta, taking config, and doing several things for several inputs are good examples of ways to reduce the amount of code--when used appropriately. Being explicit reduces code too. Over abstracting and premature optimization can result in bloated spaghetti code.

[jacob019]

By less code I mean less logic, not less characters. Less code generally means less work for the CPU (faster), less surface area for attacks, a smaller codebase that is easier to pick up and work on. When working with sets of numerical data, there are often two or more ways to come up with the desired result. A dumb imperative way, that may involve several loops and stages, or a simple and intelligent way that requires a deeper understanding of the math to implement properly. I've seen pages of slow code reduced to a few simple lines that are performant and easy to grok.