Sadly I don’t know any of such place. I mostly find solution through the search engine, bot more than often i find solutions which are simply not thought through and have flaws that the original author forgot to mention 
What about something like this wiki:
1 Like
Liking the discussion so far, especially the points made by @bbense and @gregvaughn.
I think the main problem is cultural, stemming from the lack of familiarity of languages other than C# and Java in general and of functional programming languages in particular. Even at the graduate level, functional programming is often only taught in a “Programming Languages” survey class (correct me if I am wrong - I consider @NobbZ’s university program an outlier). Because the center of the bell curve of enterprise developers lie in group (2), they are unlikely to put forth the effort required to shift their programming paradigm, much less foster an enterprise-wide adoption campaign. The rest of it is historical (“legacy”) reasons since imperative languages seem to have won in popularity over the past half-century.
And while we don’t need reams of textbooks describing design patterns in Elixir, it’s not particularly helpful that we lack decades of books solving common software architecture problems in the functional programming paradigm. However, modern web architectures now making use of reactive programming, the actor concurrency model, and fault-tolerant / resilient web services — which are far easier to employ with a functional language — give us more and more books in this direction.
Enterprise-level paid support is more important for the library/application than the language itself, i.e. Phoenix over Elixir. And there is probably a perceptual consideration when evaluating a language or framework: it has to match their mental model of an enterprise necessitating tons and tons of books, documentation, and official conferences and training materials. In that sense, it may only be a matter of time before an Elixir-focused enterprise similar to Oracle arises to take CTOs golfing.
3 Likes
I don’t think functional programming languages will ever be anything but a niche for enthusiasts and startups because I don’t think most programmers have the chops to do functional programming. It’s more cognitively demanding and has a higher degree of abstraction. In return you get more maintainable modular code, but it’s not a tradeoff that many firms will be capable of making.
Edit: I’ve been thinking about this more because functional programming is getting more popular. I think the mainstream will eventually go back to procedural programming with an emphasis on pure functions and minimizing globals. The next big language probably won’t be functional but will have the compiler enforce pure functions by default and have something like a ‘notconstexpr’ keyword for dirty functions.
I’m not going to say you’re wrong but I’ve actually found functional programming easier than OOP/imperative/mutative.
In my mind, there are two kinds of FP: “practical” like Erlang and Elixir, which just have higher-order functions, no mutation, but let you do side effects with no problem. A subset of JavaScript with a few libraries also fits this molds as so do other languages.
Then there’s “non-practical” FP: Haskell and its many algebraic data types and lack of side effects. Not sure where OCaml fits into this, maybe @OvermindDL1 can tell us.
(Note that these categories are made up by me so take the with a grain of salt.)
I think “practical” FP is on the rise and while it may not be as mainstream as Java-like OOP it’ll be a valid choice. The problem is most universities teach Java or C++ and OOP now so it’s a difficult shift for new programmers.
Anyway, at the end of the day I have to agree with your second paragraph. I see this all the time in JavaScript-land: people proclaiming FP is the best thing ever… but they’re just using pure functions and minimizing mutation. Don’t get me wrong, that’s good and is part of FP, but it’s mixed with a bunch of imperative and mutative code.
1 Like
About 10 years ago Joe Armstrong wrote a highly informative paper:
The History of Erlang
http://webcem01.cem.itesm.mx:8005/erlang/cd/downloads/hopl_erlang.pdf
In it, there are parts where he discusses how “strict” of a FP language
they intended Erlang to be (or not). There are large passages devoted to
this discussion. As a sample, I found the below material to indicate they
definitely favored a more pragmatic orientation:
“Erlang is not a strict side-effect-free functional language but a concurrent
language where what happens inside a process is described by a simple
functional language.
…
Although the functional community was always happy to point
to Erlang as a good example of a functional language, the status
of Erlang as a fully fledged member of the functional family is
dubious. Erlang programs are not referentially transparent and there
is no system for static type analysis of Erlang programs. Nor is it a
relational language. Sequential Erlang has a pure functional subset,
but nobody can force the programmer to use this subset; indeed,
there are often good reasons for not using it."
OCaml is strongly typed like Haskell yes, however you can break that encapsulation if you need and force things around kind of like with Rusts’s unsafe keyword, magic in OCaml, among other very nice things like being able to define something as mutable via the ref keyword, everything is immutable otherwise. OCaml is what Haskell would be if it had the pragmatism of Erlang is how I would describe it.
Especially once OCaml gets two coming features, implicit modules (automatic module matching based on types whoo!, think typeclasses but more powerful and significantly faster to compile), and the concurrency primitives (you can even make your own scheduler, you could write OTP style Actor’s in it then), then it will be both more simple to use and can then be used for about anything.
Trolling’s not allowed on the forum 
Well, if the subject has drifted to become “developers who don’t want to learn anything new”, then I’m pretty sure Elixir does not (and indeed should never) care about them!
1 Like
