Was there some kind of big breach in 2017? My account wasn't even pro! I just logged into my account after a couple months and someone else was using it!
Higher kinded types create a context arlu d the types(and ultimately the values) they wrap. This can type classes which implement a the same function in different ways for the same value wrapped in a different higher kinded type, for example. So if your domain deals with values in two contexts, and you want to manipulate them using a common language, higher kinded types are a pretty great way to achieve that. They also enable parametric polymorphism, and that creates a LOT of predictable behaviours for free, which in turn allows you to automatically derive typeclasses, interfaces, and theorem proofs in certain situations.
So function languages are excellent and taking very little work to model a clean abstraction. This is mainly due to the behaviour of a lamda function.
The result is that you can easily model a procedure as a series of discreet steps and abstract away clutter. Mutated state and implicit arguments (this) are also typically not used in FP (except where required by the language or for performance reasons)
Upsides to this is that code is explicit, terse, and doesn't get bogged down in the specifics of how the hardware might need to assign pointers to values, etc.
The downside to this is that some people find the mounting abstractions and endless new terms difficult to parse, since FP spends very little time working with primitive values, and since it often is so different from traditional OO languages.
Javascript in particular can be very terse because there's very little boilerplate necessary due to the type system, and because it places no restriction on side-effects, allowing very easy methods of getting things done (but also creating a lot of brittle, bug-prone behaviour)
Haskell and purescript have much more verbosity devoted to types and type manipulation, but produce much more stable/predictable behaviours.
So I think, just reading this thread, there there are a lot of misconceptions of FP's capabilities. Things like statelessness - Haskell, Purescript, et al have ways of representing state, and for optimizing recursive behaviour into constant space/time (they even have great abstractions and data structures that can compete with C)
The number one reason is that ultimately it feels too different, and Functional programmers tend to be terrible educators. So it all feels very esoteric. To learn a pure functional language is almost to start learning programming from scratch.
The secondary reason is the package ecosystem. Generally speaking these languages have a rough go at dependancy mgmt/build tooling (stack vs cabal and the lack of good, simple guides for their usage, and the same for bower(deprecated) psc-package and spago. The problem is that once the tools improve - the docs and guides are all outdated. Good reliable information takes more digging in these languages.
BUT it is achievable. These are perfectly serviceable languages that can provide robust, provable behaviors. And in the case of purescript, a strongly typed environment on the web.
The development processes are out there and there are folks writing full stack FP. (myself included). But as a whole, pure FP needs a lot more educational material in order to grow.
>To learn a pure functional language is almost to start learning programming from scratch.
I think this is exactly it. When I decided to try Elixir, I figured it'd be just a bit more effort than trying out any other OO language. It hasn't been. It's been a matter of reconsidering just about every concept I had to solving a problem with code.
