That's nonsense frankly. I've worked with an excellent team of Haskellers before I don't think we'd have been anywhere near as good without the type system. I'd agree that having an awesome team gives you a lot of other advantages, and actually FP is a huge opportunity to build that team for start ups. FP tends to attract the kind of people who make up a great team. It's for this reason that I think the conclusions of the flub paradox article are wrong http://steved-imaginaryreal.blogspot.co.uk/2015/06/the-flub-...
Thanks for the downvotes, I was referring to things beyond FP. The type system is a set of early restrictions (as opposing to late restrictions or runtime or late bound).
But now you mention it, I'm curious about if you think the type checker allowed you and your team to reach the goals of the project faster or not.
Aside from that in Haskell the type system isn't usually a restriction. Experts in Haskell tend to use the type system to guide them towards a correct solution.
I'm not sure it possible to say that we couldn't have built something quicker in another language or stack. What I will say was that the underlying abstraction that we built our system on (streams of events) is very well suited to a Haskell implementation, and I can say with some certainty that building a solution that is as "correct" as the one we built would have been extremely challenging. The code also held together for longer than has been my experience in some other languages and communities.
I had a system in C, with a goal of extremely low latency. This involved a small collection of threads, each serving a different role. Project goals would periodically change, and I would find myself needing to move some functionality from one thread to another. With some creativity, I was able to enlist the help of the type checker in assuring that a particular function ran only on a particular thread. This sped me up tremendously, as my tooling would point me to inconsistencies rather than having to reason them out myself.
I'd agree that having an awesome team gives you a lot of other advantages, and actually FP is a huge opportunity to build that team for start ups. FP tends to attract the kind of people who make up a great team.
Yes, absolutely. It's amazing how overlooked this fact seems to be, by many. Languages aren't that hard to learn, so excluding the really awful ones (e.g. Java for anything other than code that has to be on the JVM and has to be fast) the "familiarity" aspect is minuscule. Programmers learn new languages quickly. What does matter is the community and the quality of programmer you'll attract based on the tools you use and the signals that your tools send about who makes decisions.
You can't pass a static method as an argument to another static method. You can't write a static method that returns a static method. You can't partially apply a static method. Static methods are not functions.
I think Kyllo was referring more to first-class/higher-order functions. I believe Java 8 added support for lambda expressions, but it's nowhere near the same thing.
That's the lack of higher order functions and the lack of first class functions. Anyway I think higher order functions and method references have been added to Java 8 as well as Lambda functions.
