If cutting out boilerplate to sharpen focus on the actual code doesn't help make it easier to understand, then something is seriously wrong.
Part of writing good code, whether two pages of brilliance or twenty of gradual brilliance, is conveying intent in the human-readable parts. The parser doesn't care if all the functions have names like doTheNextThing() or french_onion_soup, but it would be a slap in the face to any future maintainers.
Choosing informative names and separating a program along clear conceptual boundaries can be a greater aid to understanding than any syntactic redundancies. Well-placed comments help smooth things over, particularly notes on why a particular approach was chosen. The names themselves should be able to convey what is going on in most cases.
The biggest thing I learned from Forth is that if I'm about to add a comment inside a function because something needs clarification, I should probably try breaking it out and thinking up a descriptive name instead.
Part of writing good code, whether two pages of brilliance or twenty of gradual brilliance, is conveying intent in the human-readable parts. The parser doesn't care if all the functions have names like doTheNextThing() or french_onion_soup, but it would be a slap in the face to any future maintainers.
Choosing informative names and separating a program along clear conceptual boundaries can be a greater aid to understanding than any syntactic redundancies. Well-placed comments help smooth things over, particularly notes on why a particular approach was chosen. The names themselves should be able to convey what is going on in most cases.
(For distilled wisdom along those lines, see _Thinking Forth_ by Leo Brodie, also online at http://thinking-forth.sourceforge.net/.)