Lots of people are and have been "productive" in Haskell, various Lisp dialects, O'Caml, and so on.

I worked at a startup whose Haskell backend was quite pleasant to work with and served them very well. This site itself is written in Arc, as you probably know, and Paul Graham has written several essays about the "productivity" he and his team achieved using Common Lisp.

People can work productively with software using all kinds of tools and languages. As you mention, a lot of it might come down to taste, likes and dislikes, habits, etc. Of course you're going to be more productive if you're familiar with your tools. So your experience with productivity isn't really an objective indicator for anyone else.

I didn't mean you can't be productive in functional languages. What I'm criticizing are the platforms and I don't see that as too much of a subjective matter.

For me as a user Haskell(the platform) is inferior to, say, Go, simply because I can manage external packages that much easier. Thus if I needed to get something done I'd rather use Go, not because I think it's a better language than Haskell, but because of the pain in dealing with package versions, building, etc.

Basically what I'm saying is that you don't see that much adoption, and thus data to endorse the productivity claims because of the platforms and not because the languages per se are bad.

Pg said people don't use lisp because it looked weird and it's not popular[0] and I think it applies to functional languages in general. I don't think you can/should solve the former, but by having friendlier/better platforms you could start solving the latter.

http://www.paulgraham.com/iflisp.html[0]

How do you personally do package management with versioning in Go? Last time I checked Haskell was better than Go here.

Go packages have no versions, if you make breaking changes you should make a new package so you don't need to specify a version in some metafile to stop the build process from breaking.

So basically use master or fork all your dependencies to freeze versions.

Why would you freeze it? I understand that even with the Go policy on versions it can happen that a change on some external package can cause problems, but that's unlikely to happen and as you have the packages as git repos you can just git reset it back to a commit when it was stable or even better: fix the problem and contribute back.

Why does Java have Maven, Haskell have Cabal, or Python have pip? So you can grab some old code written by someone no longer at a company, build it, fix bugs, and complete your task in a reasonable amount of time.

Without version constraints it's much harder to even say "I can build this program" much less "I can fix this bug".

> that's unlikely to happen and as you have the packages as git repos you can just git reset it back to a commit when it was stable

You seem to be assuming you are the one who wrote the code. I'm more speaking in cases where someone you don't know and can't contact wrote the code. Have you ever had to reverse engineer a very large dependency chain? It is absolutely no fun :/

To be honest, while I am empathic to the argument you're making I think it's orthogonal. There is a fundamental difference in the design of languages to consider and then, atop that, one about actual existing technologies and their platforms.

I agree that Go's workflow philosophy is great. I wish more languages adopted it. But that's the thing, it's easily mixed and matched. On the other hand, making something like Ruby genuinely type-theoretically typed, while an admirable and interesting goal, will probably never happen. Their worlds are just different.