4 ms·
> So how does a programmer from non-functional world become fluent in understanding sentence such as "abstraction over type constructors"? We already have very
by diegoperini 6y ago
> So how does a programmer from non-functional world become fluent in understanding sentence such as "abstraction over type constructors"?
We already have very primitive (and restrictive) imperative OO languages which are good at teaching the basics to new programmers. My observation is, FP lacks such gateway languages. Even the simplest FP-first language is intimidating.
So my answer to your question is, a good strategy to learn these can be carving out a relatively small portion from a language (i.e Haskell with only Algebraic Types and Pattern Matching) and working only on it for a period of time. Doing that doesn't teach terminology but exposes what Haskell is really obsessed about. For the curious, it is expressing type relationships as flexibly as numeric arithmetic we know from high-school.
Just like high-school arithmetic, several recurring patterns (often called formulas in Math classes) have their special names. Almost all programming languages are good at closely matching that syntax in their numeric expressions. It is unfortunately not the case for types though. In programming,
this functional type (pseudo code):
A = (X + Y) | Z
tend to be expressed as:
interface class A {
}
class A1 implements A {
X x;
Y y;
}
class A2 implements B {
Z z;
}
or as:
union A {
struct A1 {
X x;
Y y;
} a1;
struct A1 {
Z;
} a2;
}
In both examples, it is longer to write the same "meaning" in OOP than FP, especially when there are abstract methods involved.
This difference in verbosity (aesthetically subjective) bugs an FP programmer more and more as they get used to their language. When that happens, people start naming things. Having an abstract type of `Collection` is no longer enough because we realize `Collection`, `Mappable`, `Traversable`, `Generator`, `Optional`, `Atomic`, `Pair` and `Tuple` all share the similarity of:
* wrapping a type,
* having a way to access the wrapped value(s),
* and the wish to support all operations the wrapped value supports without an unwrap, composable out of the box.
We call this pattern a name, the infamous "Functor" (incorrectly but who cares), and axiomize those assumptions formally in the target language, so that it is longer reimplemented again and again. The word "Functor" itself otherwise has no meaning, it is letter salad.
To learn those names effectively, you must be comfortable enough with the basics so that you get annoyed by the repetition and start researching new names as you stumble upon with new patterns.
In Haskell, "abstraction over type constructors" usually means (in OO terms) "declare a new generic interface and implement that in the abstract type so that you don't have to reimplement it non-genericly in the concrete type".