Hacker News Reader

Comment by haggy | Hacker News Reader

> On the contrary, high verbosity means less information per token, making it easier in my opinion to read

See I think this is actually backwards thinking. The more boilerplate you have to sift through, the more you're trying to retain before getting to what the program is actually doing.

> A good example is the anonymous class. They are portly and wasteful of vertical space, often costing 5 lines when one would due. But, the amount thinking per line is greatly reduced

Same applies for this statement. You're trying to absorb so much more code before knowing what is actually happening.

View on HN

Yeah but the boilerplate is basically invisible to anyone with experience in the language

I think that's the issue though. One should not need to have much experience in any particular language to read and understand what a particular piece of code is doing. It should be relatively intuitive. The more boilerplate a language has, the larger the cognitive load. This holds true regardless of whether or not it is invisible to anyone, it's just that much more annoying. I'm not doing a good job of expressing my thoughts here, but I absolutely "feel" this way when working with Java vs something like Python.

That being said, I'm a big of Java and the eco-system.

"One should not need to have much experience in any particular language to read and understand what a particular piece of code is doing."

I'm not sure I agree with this. I think every effort should be made to keep your code readable to others with similar knowledge. However, I don't think you need to make everything readable by a junior level coder.

Maybe a decent analogy is that not all books target a 4th grade reading level. The varience of information density isn't just about saving time for those that understand it, but also for keeping you interested (or disinterested if you aren't ready for it yet). For example, reading young adult fiction in your 30s usually wouldn't keep you engrossed.

The older and more experienced you get, the harder it is to assume others who will have to deal with the code will have "similar knowledge".

"However, I don't think you need to make everything readable by a junior level coder." I may not be a junior-level coder, but I may still be 'jr' with your particular language or framework, but have been assigned your code because you've moved on to something else.

I've never written a nontrivial Java program but generally speaking I find it pretty easy to read Java code.

True, but it does have impacts, like you can see less of the overall program on the screen at a time, so to scan through requires more of a look->scroll->look->scroll.

Sure, but excessively dense code has its own drawbacks. Does anyone like reading regexes?

Compared to the equivalent handwritten state machine, yes.

I don't think dense code has drawbacks; people measure in lines of code because they implicitly assume all lines are equal, but that's completely wrong. Reading the same logic when it's 20 lines is much, much easier than reading the same logic when it's 100 lines, because whether you can fit it on a single screen or not makes a huge difference to whether you can comprehend it.

Never worked in Perl, I take it

I've worked in/with Perl. Perl is unpleasant because it's inconsistent, not because it's dense - if you want the extreme examples, compare Perl with something like APL.

This phenomenon is a genuine quality problem.

Small bugs in the implementation of boilerplate code have a tendency to sail through code reviews and go without notice until they become production issues, because experienced developers develop a habit of glossing over boilerplate without reading it too carefully.

Exactly which is why no one is going to look at all those getters and setters you added not realizing that one of the setters actually does something other than setting the field or a getter causes some side effect before returning the value.

To be fair, most people use IDEs that generate them based on the fields so this would be unlikely.

Unlikely, but to be sure, you have to read all the boilerplate, attentively.

If your language generates them behind the scenes, so that nobody can modify them, that doesn’t happen.

Also, if a developer overrides one particular example, it stands out in the source, as it (ideally) is the only code visible in the source.

Unlikely edge cases are the biggest source of bugs. One of the worst production bugs I've seen happened because someone refactored some code assuming a getter just got the field, like 99.9% of getters do, but this particular getter didn't.

I think you miss my point. Most people DO generate them via an IDE so they don't get looked at closely. But imagine someone then editing one of the generated methods to do something different than expected. Happens all the time.

Even if that were true, it still wastes a lot of space and can make reading the whole body of code more difficult. Just think about how easy it would be if Java had 2 or 5 times the boilerplate code it has now. According to you it'd be "invisible," but it'd still be a lot worse.

Reply on news.ycombinator.com