> I don't agree that dense code is easier to understand at all.
I think we just have a different definition of dense code. Here is an example that shows my view on it.
Dense:
adult_users = users.filter(it.isAdult)
Not dense:
adult_users = list.empty
for(i = 0; i < users.length; i ++) {
maybe_adult_user = users.get(i)
if(maybe_adult_user.isAdult) adult_users += maybe_adult_user
}
The first example is not only just "less" code in the sense that the filter function was also defined somewhere before and then just used. No, it is more dense code because it reduces subjective complexity by shifting some of the complexity to existing code _with which the developer hopefully is familiar with_. If the developer is not familiar with it, then the code is actually _more complicated_.
The same thing happens to language features, not only to code reuse. Some languages have generics, some don't. Without understanding and familiarity with generics, they will make everything more difficult. Once they are understood, the developer has a productivity advantage (assuming that generics are helpful).
However, gaining this initial knowledge and familiarity is very hard, hence not so many people use Haskell or similar languages and many more people use javascript and python and php, so you see more large-scale apps written in them. But we also see that all big companies eventually struggle with the not-dense-enough code and build on top of these languages. Facebook with php->hack, stripe with their own version of Ruby, ...