This is why the fundamental operation in the land of the verbs is composition: do this then do that. It turns out that composition is such a useful idea that we want more of it, which is where categories, monads and arrows come in.
The most obvious type of composition for functions is, well, function composition. In math we define the composition of functions f and g as f(g(x)), usually written as f ∘ g. We can write this directly in Haskell pretty trivially:
f ∘ g = λ x → f (g x)
And, in fact, you will see this operator everywhere in Haskell, except most people are too boring for ∘ and use the ASCII . instead. (Weak.)
Also, a cool aside. I just realized that Haskell syntax is even more regular than I had assumed. In general, in Haskell, you can rewrite expressions like
f x = λ y → ...
as
f x y = ...
Turns out this even works for operators! So you could actually write the above composition as:
(f ∘ g) x = f (g x)
I think that's pretty cool, but maybe I'm just easily impressed.
The idea of a category just takes the ∘ operator and generalizes it to other types, letting you use it for things that aren't normal functions. As I mentioned above, these things could be arrows or functions involving monads, but they can really be anything at all. This is, coincidentally, one of the main reasons we care about category theory: at its very heart, category theory is the study of composition. (Okay, I'm probably really misrepresenting the mathematics here, but that's how it works out for programmers :).)
There are also other things you can do with functions. In particular, you can map functions to other functions. And this is, indeed, what the well-known map function does. Normally, you think of the map function as taking a function and a list and then mapping that function over the list. In Haskell, this has the following type:
map :: (α → β) → [α] → [β]
However, I posit that map actually does something rather different and more subtle--it takes normal functions and produces list functions. In fact, the type signature is better thought of this way:
map :: (α → β) → ([α] → [β])
(This is why currying is so great--both interpretations are equally valid!) So, in fact, we can think of the list type as a way of mapping existing types (like a) to new types (like [a]) and mapping existing functions (like (α → β)) to new functions (like ([α] → [β])).
This operation also turns out to be exceptionally useful. So useful, in fact, that it's the basis for one of the most fundamental concepts--the functor. In fact, a functor (in Haskell) is simply any type with a function analogous to the list type's map. For historical reasons, we call this function fmap and it has the following type:
fmap :: Functor f => (α → β) → (f α → f β)
All this says is that, given a functor type, we can map normal functions to functions over the functor. Another way of thinking about this is that a functor is roughly like a function at the type level.
Of course, we have other ways to transform functions as well; fmap is just the simplest. Similarly, we have other ways to compose functions, function composition is just the simplest.
So the most important idea is that we actually have a fairly wide variety of operations over functions. We can sling them around as easily as any other data type, really.
We move forward by combining functions rather than trying to modify them. Instead of starting with a composite piece and working inwards, we start with the basic building blocks (functions and types) and work outwards, combining them in different ways to get a composite program.
It's a difference in philosophy, and I think a rather important one.
I am happy with you with all that mathy stuff and I agree that it is cool - but it does not address my point which was that functions are black boxes. Once you have 'f' you can compose it whatever you want - but you cannot change its parts - ala universal design pattern (yet another too long Yegge rant: http://steve-yegge.blogspot.com/2008/10/universal-design-pat...).
Sure composing can somehow work for these case, just like a Turing Machine would work, after all it is all equivalent - but we really tend to think about reality in terms of prototypes - a pony is like a horse only small, a goose is like a duck only bigger and white, etc. - this is what makes this inheritance and overriding so convenient. And if you argue that it is not as clean as pure function composition, that it can quickly get into a tangled mass where pure functions are pure and easy to reason about (but it is all equivalent - so you can actually write the same tangled mess code in a pure functional language - by carrying the state around like the burlaks on Volga) - then yeah I agree - engineering is always about trade-offs. I am only trying to explain one of the sides of that trade off.
Why would you need to change its parts, it can be parameterized over the parts that change, by passing in other functions as arguments. It's also cheap conceptually and syntactically to create new ones, if an existing one doesn't fit the bill.
I don't really know - I've never extensively programmed in functional way (beside studies) - but the point about overriding is that you do it post-hoc you get a library class and you change it. The original author does not need to imagine all the ways you'd like to modify it - and yet by doing some basic structural design and putting stuff into methods he gives you the opportunity to override. Also I imagine that this level of parametrizing - that is if every function in a package is a parameter to another function in that package then it gets messy, but with subclassing/overriding you can change any method and it changes for all other methods.
The most obvious type of composition for functions is, well, function composition. In math we define the composition of functions f and g as f(g(x)), usually written as f ∘ g. We can write this directly in Haskell pretty trivially:
And, in fact, you will see this operator everywhere in Haskell, except most people are too boring for ∘ and use the ASCII . instead. (Weak.)Also, a cool aside. I just realized that Haskell syntax is even more regular than I had assumed. In general, in Haskell, you can rewrite expressions like
as Turns out this even works for operators! So you could actually write the above composition as: I think that's pretty cool, but maybe I'm just easily impressed.The idea of a category just takes the ∘ operator and generalizes it to other types, letting you use it for things that aren't normal functions. As I mentioned above, these things could be arrows or functions involving monads, but they can really be anything at all. This is, coincidentally, one of the main reasons we care about category theory: at its very heart, category theory is the study of composition. (Okay, I'm probably really misrepresenting the mathematics here, but that's how it works out for programmers :).)
There are also other things you can do with functions. In particular, you can map functions to other functions. And this is, indeed, what the well-known map function does. Normally, you think of the map function as taking a function and a list and then mapping that function over the list. In Haskell, this has the following type:
However, I posit that map actually does something rather different and more subtle--it takes normal functions and produces list functions. In fact, the type signature is better thought of this way: (This is why currying is so great--both interpretations are equally valid!) So, in fact, we can think of the list type as a way of mapping existing types (like a) to new types (like [a]) and mapping existing functions (like (α → β)) to new functions (like ([α] → [β])).This operation also turns out to be exceptionally useful. So useful, in fact, that it's the basis for one of the most fundamental concepts--the functor. In fact, a functor (in Haskell) is simply any type with a function analogous to the list type's map. For historical reasons, we call this function fmap and it has the following type:
All this says is that, given a functor type, we can map normal functions to functions over the functor. Another way of thinking about this is that a functor is roughly like a function at the type level.Of course, we have other ways to transform functions as well; fmap is just the simplest. Similarly, we have other ways to compose functions, function composition is just the simplest.
So the most important idea is that we actually have a fairly wide variety of operations over functions. We can sling them around as easily as any other data type, really.
We move forward by combining functions rather than trying to modify them. Instead of starting with a composite piece and working inwards, we start with the basic building blocks (functions and types) and work outwards, combining them in different ways to get a composite program.
It's a difference in philosophy, and I think a rather important one.