> furthermore, while you may be able to more quickly "express an idea" in a dynamically typed language, your ability to precisely enumerate the idea will be less than a statically typed one.

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).

I agree to some extent, but haskell pureness for example , which I take to refer to monads and other concepts from category theory in haskell, is actually very very abstract; the "constraint" of pureness (IO monad) just leads to the design of more consistent and very general interfaces; once you become familiar with these interfaces you are quicker than you would otherwise be, also haskell's type inference help alot with expressiveness vs. dynamic languages. In fact, personally my road to really learning haskell was through converting shell scripts to haskell, a task typically left to dynamic languages but which haskell might actually be uniquely suited for contrary to convential wisdom due to aforementioned factors.

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.