Yes, you're always paying the character: each character increases mental load on the developer - either through code complexity (https://github.com/scalaz/scalaz) or just the sheer amount of code (would you want to code everything in assembly?).
Leaky abstractions, as you mentioned, result in unclear code.
On the other hand, well-designed and easily understood abstractions reduce complexity.
Take for example, the atrocious lambda 'hacks' needed before Java 8 - create an anonymous class, then override a method. Compare that with something like words.map { _.size }
People think in terms of hierarchy and concepts, not individual components. For example, cars with more internal components are not actually more difficult to DRIVE than simpler cars (eg: carburetor vs fuel injection).
Likewise, people don't pay by the character. They pay by the word. They also pay by the concept, so having N different ways to do something simple can be a higher cognitive burden than just 1 way. (hence python vs perl).
Now, I believe that clear code, "well designed" code (despite the fact that its patently obvious that no one agrees on what well designed actually MEANS) are better. Good abstractions.
But these are a function of the programmer from which they come from. The programming language makes a difference but I'm starting to suspect beyond a certain point of feature completeness, you are hitting diminishing returns then negative returns. Yes Java8 has Lambdas, that helps a lot. But would Java9 benefit from implicit parameters? Or from nearly any punctuation being an operator that can be overridden? I argue these 2 features of scala, which people love for their ability to build concise, hard to read, harder to write, DSLs are part of the problem.
Ok enough ranting. My parting shot is I write a 25,000 lines of scala into a production system. We had to rewrite ALL the for loops into while loops. In the end, I'd say Scala was generally helpful but not so much that I'd do it again.
It's unarguably shorter than anything you could write in most other languages, but is it more readable?
My point is that, while too many characters are bad, too few are bad as well. And that possibly the "just right" verbosity varies from person to person. And also that readability is completely unresearched topic without any established facts we could argue about... Anyway, the key takeaway: we're all wrong on the issue of readability and we don't even know how much wrong.
Comments
Yes, you're always paying the character: each character increases mental load on the developer - either through code complexity (https://github.com/scalaz/scalaz) or just the sheer amount of code (would you want to code everything in assembly?).
Leaky abstractions, as you mentioned, result in unclear code. On the other hand, well-designed and easily understood abstractions reduce complexity.
Take for example, the atrocious lambda 'hacks' needed before Java 8 - create an anonymous class, then override a method. Compare that with something like words.map { _.size }
People think in terms of hierarchy and concepts, not individual components. For example, cars with more internal components are not actually more difficult to DRIVE than simpler cars (eg: carburetor vs fuel injection).
Likewise, people don't pay by the character. They pay by the word. They also pay by the concept, so having N different ways to do something simple can be a higher cognitive burden than just 1 way. (hence python vs perl).
Now, I believe that clear code, "well designed" code (despite the fact that its patently obvious that no one agrees on what well designed actually MEANS) are better. Good abstractions.
But these are a function of the programmer from which they come from. The programming language makes a difference but I'm starting to suspect beyond a certain point of feature completeness, you are hitting diminishing returns then negative returns. Yes Java8 has Lambdas, that helps a lot. But would Java9 benefit from implicit parameters? Or from nearly any punctuation being an operator that can be overridden? I argue these 2 features of scala, which people love for their ability to build concise, hard to read, harder to write, DSLs are part of the problem.
Ok enough ranting. My parting shot is I write a 25,000 lines of scala into a production system. We had to rewrite ALL the for loops into while loops. In the end, I'd say Scala was generally helpful but not so much that I'd do it again.
Not so. A quicksort in J is one absolutely lovely counter-example:
It's unarguably shorter than anything you could write in most other languages, but is it more readable?My point is that, while too many characters are bad, too few are bad as well. And that possibly the "just right" verbosity varies from person to person. And also that readability is completely unresearched topic without any established facts we could argue about... Anyway, the key takeaway: we're all wrong on the issue of readability and we don't even know how much wrong.