The current theme of RITLug talks is programming languages. My specialty.
This talk was a little more impromptu, so no slide deck to link to. However, I went over a handful of functional programming techniques, mostly exemplified through Haskell.
This meeting was at the same time as the start of Datafest. So I kept it short, and attendance was low.
Functional programming has kinda blended with several popular, industry-standard languages. C++, Java, and Python all have lambda functions. Python makes use of map(), filter(), and sort(), all of which use higher-order functions.
There’s no definitive, category for what makes a language functional. However, a language is generally considered a functional language if it lends itself well to the functional style, notably:
- evaluating expressions instead of statements
- minimizing stateful elements
- using functions as data
Expressions return values of some sort, once evaluated. This is different than a C-style int a = 3; or the sort: this doesn’t really “return” anything, it just changes the world in a certain way. In our case, it changes the value a to 3. Fairly straightforward.
A more functional language wouldn’t have something like that: instead, something would be returned, to use in another expression. Like, 2 + 2, which is added to a list, such as [1,2,3].append(2+2), which itself would return [1,2,3,4].
For an OOP-style approach to modifying the world, you build an object from a class (or other outline), and pass that around to various functions, or call methods on the object to change its state. A chair my have legs as an attribute, it may lose legs with a removeLeg() method, et al.
Functional programming is more math-rooted: same input, same output, like a mathematical function. Passing in a chair with 4 legs to a removeLeg() function would return a new chair with 3 legs: instead of modifying the world in-place, you recreate it to avoid mutability.
Functions as data
This whole concept of passing functions as arguments is where a lot of power comes from. Functions can decide filtering, provide a path from a to b, explain what to do when an error occurs, etc.
This is amplified with closures. Not only are you passing around instructions, but values or a scope that comes with them. It’s nearly like objects, with data and functions! But instead of inheritance, you’re mostly using typing, and minimizing state changes.
FP has been fun to play with for the past couple years, and resulted in a couple creative solutions to appearing programming problems. It’s not perfect (speed and GC reliance are just a couple downsides), but it certainly has its place in a handful of domains.