4 ms·
That's a very confusing table, but an interesting comparison. I think you reveal different things comparing line count and character count, and both miss what
by Dove 14y ago
That's a very confusing table, but an interesting comparison.
I think you reveal different things comparing line count and character count, and both miss what I'm looking for in a terse language: scanability.
A lot of the verbosity that annoys me with Java isn't really about number of lines -- it's bad, not particularly worse than any of the other languages descended from ALGOL. No, what makes Java worse than its cousins is the propensity to use English words, and often really long ones, in places where symbols would be easier to scan. "public class Foo extends Bar" is a lot of English text, and I have to read it all to separate out the tokens. "@interface Foo : Bar" makes it easier for me to see at a glance what's going on.
And don't get me started on wading through rotation.multiply(other_rotation).multiply(velocity).add(rotation.multiply(other_velocity)). That's technically one line, but that doesn't make it easy to read.
So winning on line count doesn't capture everything.
On the other hand, measuring characters biases you toward symbol heavy languages like perl or APL, and '$\="\n"' takes some picking apart, too.
I did think APL would win an outright terseness competition, though, by either metric. It's a shame it isn't on the list.
- russell 14y agoI've seen metrics done on the basis of symbol counts, not characters or lines. In theory this normalize differences in coding styles, such as verbose identifiers, or positioning of braces, or liberal use of whitespace. I agree with you about Java. I have a line on my screen that has 6 identifiers and is 99 characters long and it's not even a constructor call. One of many problems is long identifiers with similar names.
- reeses 14y ago"public class Foo extends Bar" is a lot of English text, and I have to read it all to separate out the tokens. "@interface Foo : Bar" makes it easier for me to see at a glance what's going on. I know it's a "throwaway" example in a comment, but the first example makes it quite clear what is requested. The second example, less so. Never mind the @interface declaration. If you're going to be writing or maintaining objc, you have to understand that. However, the x : y notation often leads to confusion. Does x extend y? Does y extend x? It's probably not a big deal for someone who lives in one or two languages, as the knowledge is refreshed frequently. However, when you swing between, say, Haskell, Python, Ruby, C++, Java, or whatever, and maybe only touch objc when you need to update your iOS app to match your web app, then there's a cognitive hurdle because ':' doesn't have a clear interpretation. Given its Smalltalk heritage and model of message passing, "@interface y subclass: x" (or "@interface x subclasses: y") would carry less of a cognitive load while perhaps being less verbose. Again, this is only a superficial example, but choice of names or symbols is important in the language UI.