81–90 of 112 posts
Earlier quoted context omitted.
Giving descriptive names just harms intuition building in the long run. I've been writing Haskell for over 5 years and to this day when I see , , >>= in my code I don't substitute English words for them.
> Giving descriptive names just harms intuition building in the long run. Citation needed
Earlier quoted context omitted.
> We've "abstracted (the function map) over the type constructor (of the data structure being mapped over)". Then why didn't they just call those types "Mappables"?
I think this is a great question because it tends to come up a lot. What do you call the following common operations? - 1 + 0 - 1 * 1 - "string" ++ "" - [1, 2, 3] ++ [] As far as I know there is no term for this grouping of operations outside of functional programming languages which use category theory. We call it a "monoid" based on the following precise definition: > In abstract algebra, a branch of mathematics, a…
Earlier quoted context omitted.
I think this is a great question because it tends to come up a lot. What do you call the following common operations? - 1 + 0 - 1 * 1 - "string" ++ "" - [1, 2, 3] ++ [] As far as I know there is no term for this grouping of operations outside of functional programming languages which use category theory. We call it a "monoid" based on the following precise definition: > In abstract algebra, a branch of mathematics, a…
concat?
I think the point GP was making is that a monoid has something to do with a function f that takes two arguments a and b where there is a single value for b such that f(a, special_value) == a. I think.
As someone who doesn't really understand FP concepts I would probably call those functions "functions that can sensibly be used in a call to array.reduce"
Earlier quoted context omitted.
> We've "abstracted (the function map) over the type constructor (of the data structure being mapped over)". Then why didn't they just call those types "Mappables"?
I think this is a great question because it tends to come up a lot. What do you call the following common operations? - 1 + 0 - 1 * 1 - "string" ++ "" - [1, 2, 3] ++ [] As far as I know there is no term for this grouping of operations outside of functional programming languages which use category theory. We call it a "monoid" based on the following precise definition: > In abstract algebra, a branch of mathematics, a…
Earlier quoted context omitted.
I think this is a great question because it tends to come up a lot. What do you call the following common operations? - 1 + 0 - 1 * 1 - "string" ++ "" - [1, 2, 3] ++ [] As far as I know there is no term for this grouping of operations outside of functional programming languages which use category theory. We call it a "monoid" based on the following precise definition: > In abstract algebra, a branch of mathematics, a…
"binary operators with an identity value"
Earlier quoted context omitted.
Giving descriptive names just harms intuition building in the long run. I've been writing Haskell for over 5 years and to this day when I see , , >>= in my code I don't substitute English words for them.
Was about to complain you can't google them, but I tried it and it worked. Huh. I guess you can google symbols now, even traditionally escapey-ones. News to me. mentalModel.update(). The query `python @` fails pretty hard though.
Try a textbook? e.g. Types and Programming Languages by Benjamin C. Pierce.
https://bartoszmilewski.com/2014/10/28/category-theory-for-p...
https://www.youtube.com/watch?v=I8LbkfSSR58&list=PLbgaMIhjbm...
https://www.youtube.com/playlist?list=PLbgaMIhjbmElia1eCEZNv...
https://www.youtube.com/playlist?list=PLbgaMIhjbmEn64WVX4B08...
Earlier quoted context omitted.
concat?
I can't think of any way for 1 * 1 to be concatenation. I think the point GP was making is that a monoid has something to do with a function f that takes two arguments a and b where there is a single value for b such that f(a, special_value) == a. I think. As someone who doesn't really understand FP concepts I would probably call those functions "functions that can sensibly be used in a call to array.reduce"
+: concat marbles sequence
* : concat prime factors sequence
++: concat box sequence
For * , it can also be reduced to + via logarithms. I just don't have a good metaphor for '+ over reals' this morning.
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
interface class A {
}
class A1 implements A {
X x;
Y y;
}
class A2 implements B {
Z z;
}
union A {
struct A1 {
X x;
Y y;
} a1;
struct A1 {
Z;
} a2;
}
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".