Number of tokens might be a more useful quantitative measure of concise code than number of characters. But there's no simple number that can substitute for good taste.
On Monday, April 14, 2014 4:19:49 AM UTC-5, Mike Innes wrote: > > People often talk about code concision as if it's a simple case of number > of characters or lines per idea / function / project / whatever. And sure, > SLOC is an indicator of how expressive a language is, but a fundamentally > flawed one because it conflates two distinct issues: (1), the number of > distinct concepts you need to express an idea, and (2), the number of > characters you need to express those concepts. > > map() isn't better than a for loop *because* it's short; it's better > because it lets you express the same idea with only three concepts > (functional + function + data). Shortness (in characters) is just a side > effect. > > You couldn't improve Java by making every method and class name shorter, > because then not only would you still need an insane number of concepts to > write a simple hello world, but those concepts would be needlessly > obfuscated. Take APL/J for contrast: these languages are concise both > because of implicit function composition (cool) and because every function > is one or two characters long (not so much). Julia hits the sweet spot > here, I think, because it's expressive enough to be succinct without > worrying about concision for its own sake. > > In the real world, typing is never the bottleneck – it might be if > function names were hundreds of characters, but for one, three, even ten, > choose clarity over concision every time. >
