On a more serious note yes, but again that's a cultural thing. Languages like Erlang (and OCaml, and Haskell, and...), you spend more time thinking than typing. You don't (need to) write much code, and if you think of a better way you might completely overwrite yesterday's work. You might deliver a huge chunk of functionality in a couple of pages of code that took weeks of thought, but that looks like it was typed in a day (I have been in that situation). Functional languages don't fit big-company management comfortably. They don't look like "work" in the sense that most IT organizations are used to. Java will be with us for a long time.
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.
I think it's a lot easier to understand what some code does if you don't have to read a lot of language imposed cruft that surrounds the actual 'meat' of the algorithm.
Erlang really is easier than Java -- both to read and to write. I think people too often confuse "different" with "difficult".
For one thing, the pattern matching used in Erlang, ML, and Haskell can be quite easy to read.
For example, something like
let days_in_month m = match m with
| Jan | Mar | May | Jul | Aug | Oct | Dec -> 31
| Apr | Jun | Sept | Nov -> 30
| Feb -> if leap_year () then 29 else 28
It takes a small amount of context (all "| Val" sections without a -> ... side match together), but it's a pretty direct correspondence.
That's not much harder in C or Java, given appropriate enum declarations:
public int days_in_month(month) {
switch(month) {
case JAN:
case MAR:
case MAY:
case JUL:
case AUG:
case OCT:
case DEC:
return 31
case APR:
case JUN:
case SEPT:
case NOV:
return 30;
case FEB:
if(leap_year()) return 29; else return 28;
}
}
Pattern-matching really shines when you need to destructure the argument, then do something similar to the result regardless of which case resulted in the destructuring. For example, compare red-black trees written in Java:
On a more serious note yes, but again that's a cultural thing. Languages like Erlang (and OCaml, and Haskell, and...), you spend more time thinking than typing. You don't (need to) write much code, and if you think of a better way you might completely overwrite yesterday's work. You might deliver a huge chunk of functionality in a couple of pages of code that took weeks of thought, but that looks like it was typed in a day (I have been in that situation). Functional languages don't fit big-company management comfortably. They don't look like "work" in the sense that most IT organizations are used to. Java will be with us for a long time.