Am I missing something or does this implementation only work with integer functions. If you have to write your own mapreduce for every type, that kind of defeats the point.
That’s common to all typed languages and is the motivation behind generics/templates which allow you to write once and provide specialisation where necessary. In older C and Fortran libraries it wasn’t unusual to have to compile a library multiple times to support different input types - FFTW does this for example. Often there’s some macro magic with a variable injected at build time to determine the type.
It isn't. Haskell, for example, has a type system expressive enough to encode concepts such as "a function which takes an array of elements of any type (fixed at compile time) and another function which operates on elements of the type that array is composed of and returns an array of elements of that unnamed type" and it has a type system with fewer holes than any Algol-derived language's (Ada, C, Pascal) type system has.
"Expressive Type System" without context is just a buzzword. In this particular context, it simply means that Haskell allows for types to be parameterised, which is a different way of saying it allows for generic types.
> Algol 60’s type system has fewer holes than most Algol-derived languages.
And this can be a mixed blessing. If an inexpressive type system has few or no holes, it becomes a straitjacket where you can't write the kinds of perfectly well-defined functions you need because the type system can't express them. The classic pathological example is how Standard Pascal couldn't express the concept of a function which took an arbitrary-size array, but the example so common it's typically overlooked is how it's impossible in many Algol-derived languages to write one function to compare two numbers instead of having to write four or five such functions, especially if you're unwilling to let the type system hole of automatic integral and floating-point size promotion potentially introduce odd bugs.
Haskell's type system is strong and fairly expressive, with language extensions to make it more expressive.
(This does not change the fact type systems typically express the wrong things, but this post is long enough already.)
The more I read about Fortran the more fascinated I become with it. Its treatment of arrays is similar to Pandas/Numpy. The performance is close to C without any optimizations. Without the pointer laden complexity and gotchas that come with C/C++.
Modern Fortran has a number of attractive features. Parallel programming (Co-arrays) is another gem of recent Fortran versions. Concise syntax conforming with traditional numerics makes it still a good domain specific language of choice.
In my opinion, Julia is a good successor of Fortran. In my opinion it behaves as a child of Python/Numpy and Fortran ;-)
String parsing is a bit rough, but otherwise Fortran is much better than Matlab -- and Matlab was written in the 1990s to be "Fortran for the 90s". Numpy enabled scientific computing folks to leave Matlab (and some, Fortran) to adopt Python.
I took a coin flip in grad school to decide whether to focus on Python and Fortran. Python won the flip, but I've always loved Fortran generally.
Actually, it is the other way around. Pandas/NumPy were inspired by the Fortran syntax. Fortran's treatment of optional arguments are also great. Arbitrary array indexing (0-based, 1-based, negative-based) is a bliss.
Modern Fortran is a really nice language, I have a lot of fun with it. Wish that map filter reduce were more standard parts of the compilers, but I guess it wouldn't be Fortran if new standards didn't take a decade to get good compiler support.
