You are missing an important distinction.
when you say "less code means less bugs", we're already assuming no spelling errors that the compiler can catch, right?
This implies that what you really mean is less unique operations, or less symbols is better.
I seriously doubt you're saying that x=x+5 is better than increaseOutputBy(STD_INCREASE_RATE).
What you're really saying is my oldest programming mantra--fully factored code is the only REAL measure of good code (if it does "the job" that is)
Honestly I don't even care if it has errors, and is poorly documented if it's fully factored, I can fix them easily. If it's cut and past garbage that is fully documented and error-free (as though..), a small upgrade can take weeks of hair-pulling.
The new version of my little mantra is "DRY", Don't Repeat Yourself.
But get rid of the idea that a language is better because it has 30 ways to save a keystroke, it's not keystrokes that are the problem by any stretch of the imagination.
Having the choice between:
is simply a lack of consistency, it doesn't save a thing except 2 keystrokes--and as we've already seen, keystrokes aren't a measure of anything.
s="Bill was $(where)"
s="Bill was "+where
not a single bloody advantage (in fact, in some cases, it's an EXTRA keystroke) but it clutters the language and adds to a significantly screwed up escaping system.
I'm also dealing with horrible code patterns like this now:
@user.attributes = valid_user_attributes.except :last_name
Really cute concept, make the tests look readable. The problem is if the language hadn't tempted them with the ability to leave off parens and override operators, it could have looked like this:
spec("set user attributes to valid user attributes except last name",
"user should not be valid")
Neat, no random underline/dot patterns to get wrong and the code is even clearer. Simply because the library decided not to be tricky.
Your plug-in could even syntax check the above strings--or even use a new file type just for creating the tests. Everything would be easier, everything more straight-forward.
Wow, much easier. Data NEEDS to be data. Letting your language be so flexible that it tempts programmers to show of is just an invitation for disaster.
So stay away from "Brief" and start using "DRY", because brief without DRY is far worse than DRY without brief.
Hell, in fact I would venture to wager (a LOT) that the optimum solution (out of a set of decent program samples that all accomplish the same thing in the same language) is actually going to be the MOST verbose solution that is still DRY.