I'm curious to understand why there seems to be a scarcity of Finite Element Method (FEM) implementations in Haskell, or any functional language. Given Haskell's purely functional nature, I expected to find numerous implementations of numerical methods.
My quick search on GitHub and Google Scholar didn't yield many relevant references. I came across a Quora question regarding the application of Haskell in handling large matrices, but none of the responses mentioned sparse matrices or FEM. Has there been any specific discussion or reasons within the Haskell community regarding the absence of FEM implementations? I would appreciate insights or references on this matter.
Most of the reason is simply that the set of people working with numerical methods and the set of people interested in languages like Haskell are almost completely disjoint.
What the numerics community cares about is foremostly that their code run fast, and secondarily that it be "easy" to use for non-programmer engineers/scientists (with a rather disputable notion of easyness, à la Matlab). Apart from that there's an attitude that choice of programming language "doesn't really matter because everything is Turing-complete", and that anyway the code doesn't contain the interesting mathematical derivations which are carried out separately on paper. In other words, in their mindset the only aspect of the maths that computer is involved with are numbers.
Consequently, they tend to go with languages that have a track record of use for numerical applications and then perhaps add an interface in a dynamic language around that (not so much for any abstraction purposes but simply to allow for scripting).
The functional programming community has a completely different focus, which is all about bringing mathematical concepts into the code, but not overly interested in tuning numerical performance. GHC can actually generate pretty fast executables, particularly competitive for complex logic, but for dumb numerics it can't take it up with a compiler like ICC that does all kinds of vectorisation etc. microoptimisations for numerics. Now, it would be possible to address this performance gap by writing a Haskell wrapper around optimised low-level routines in C (or Cuda), but that's not very interesting to FP people, whereas numerics people just wouldn't see any point in it because to them Haskell is just a weird fringe language.
I personally think that Haskell would be excellent for numerics, but it's not enough to just think that... we'd actually need to put in a lot of work to make it happen.