It happens that I measure expressiveness by the amount of the time the author takes to express an idea and/or the amount of the time the reviewer takes to comprehend an idea. That, unfortunately, is very subjective.
APL programmers write very short programs, but they express it at one character a minute (or less) pace.
I've been writing haskell for only several months, yet I would say I'm already more expressive with it than other languages I have more experience with, like javascript or python, outside of domain specific languages like sql.
What we need realize is not all ideas are precise. In fact, most of our ideas are vague to certain extent. They are still OK as long as the vagueness does not matter to the problem of interest or it is already constrained or implied in the context. So to efficiently express an idea, both insufficiency or over specificness are negative to expressiveness. To disclaim, I don't claim any language is the best to that regard. I believe language should be suited to the problem (as well as the experience of the team).
Since you particullarly mentioned type, I would suggest that not always a particular type is important in a idea. For example, sorting, the types of the items are not intrinsic in the idea. Having to specify the type contributes negatively to the expressiveness. However, when performance is concerned ragarding to certain specific sorting problem, types (as narrowly specific as we can) are of importance. However, we should recognize that is a different idea from the original idea of sorting. So even though in the program eventually it expresses both the algorithm for sorting as well as the types, being forced to mix ideas are negative toward expressiveness.
Haskell, its types and pureness, for example, are not always essential in a programming idea. Having to take care of these language requirement while it is non-essential, makes it less expressive (in those problem domain).
Not saying haskell is some kind of panacea, doesn't run in as many environments as javascript, and can't handle programs that require very high performance at very low latencies due to garbage collection.
For web dev, the library situation seems very mature to me.
How do you know you're not just a Blub programmer?
The second evidence is an indirect evidence. If average APL programmers can write and read programs at the same speed (character count/minute) as average programmers for other languages, Java for instance, then APL programmer will possess significant advantage in finishing similar programming tasks, given that the typical code size is often a few orders smaller. Why such advantage is not embraced and see APL programmers everywhere? My hypothesis is avg APL prgrammers program at much slower speed.
Like any science, I cannot say my hypothesis is conclusive. I am open (eager) to hear and examine any other evidences (and change my hypothesis if necessary).
there are multiple reasons for this, kind've tied together. Whitespace is function application (no parenthesis to keep track of like lisp, or even e.g. c, java, or javascript, when programming in a functional style). Immutability forces you to compartmentalize and compose everything. when everything is a function, function and variable names serve as VERY powerful documentation, especially when combined with haskell's also VERY powerful type system (which e.g. has sum types where most languages do not, which allows for example, defining most error states of program as a data type (which can then derive from any typeclass)).
one of the primary benefits of laziness is to make function composition possible under a wider variety of situations (which also increases expressiveness, at the cost of occasional though not difficult to avoid space leaks)
one joke I've heard is that the ideal haskell program is 20 lines of imports and one line of perl.