Abstract
Every coder thinks they know functions. Neat little packages of code for hiding away all that ugly implementation detail we only want to write once and would prefer no one else ever saw. In fact we take them so much for granted that when academics wax lyrical about their amazing potential we tend to assume they’re talking about the very same thing and wonder what all the fuss is about. Especially when presented with languages like Haskell which read more like a maths textbook and come with that knowing smile our parents had when telling us to eat our green vegetables: this is better for you. They’re essentially saying our functions aren’t proper functions. That we’ve embellished them with junk we don’t need and that by using a pure functional language we’ll build healthier programs. But what if I were to tell you that for all it’s practical engineering bias Go has a pretty robust concept of what a function is and how it can be used that means we can steal insights from the academic world? That we can choose to be functional programmers when we want to and - heresy of heresies - use other paradigms when they make more sense to us? Join me at this ridiculously early hour to explore functions in Go and as a mathematical abstraction. There will be a couple of simple problems to illustrate the ideas we’ll be covering, plenty of code you can study later, and a few thought-provoking examples which may permanently change the way you think about Go.
