Tag Archives: lambda

thinking in functional programming

My internship this summer gives me the opportunity to get acquainted with and even use some XSLT – misleadingly the “stylesheets” of XML.

XSLT has been hard to wrap my head around, not least because “stylesheets” and “used to format XML” make me think of CSS, not – well, functional programming. It’s been a good many years since I got to play around in Lisp, let alone make something with it, and this has brought me back to those two great semesters of AI electives that introduced me to this way of thinking. It took a few weeks to get into it, but once I “got” how Lisp worked at a more intuitive level, I remember my impression: I am thinking in a different way. It wasn’t just about programming, it was about problem solving, and about a way of looking at the world.

Diving into a functional programming language again has got me thinking about that experience. Learning how XSLT works has of course made me remember a time when Lisp made sense, because XSLT is functional programming. If I had been introduced to it in that way at the outset, it would have clicked much sooner. Now it makes me yearn a little for the time when I didn’t just know that I was working in a different way, but when that way came to make sense and I was able to start going somewhere with it.

But when I learned Lisp in the context of an AI (artificial intelligence) class, I didn’t learn it as “functional programming” then either. I wasn’t introduced to it in the context of lambda calculus, which I came to find much later – last semester – in a natural language processing course. I knew it was different, but I didn’t know how on a bigger picture level.

Now that I have that bigger picture, I am appreciating this way of thinking more and more.

Why is functional programming “hard”? Why is it something that I had to get used to for a time before it clicked? I have an answer this time – because I have been doing imperative programming for so long, because that’s how I was introduced to programming (I didn’t attend MIT after all), and because that has become the natural and intuitive way for me to solve a problem. But imperative programming isn’t a more natural way of thinking about things. It’s a different way. Obviously, these two ways of approaching problems have different applications, but the elegant and concise ways of approaching problems that functional programming offers are perhaps even more appealing to me now.

Because I am not an expert, I write this not to make a profound statement about how to approach problem solving, but to share a great article about where functional programming came from, why it’s so appealing, and the things it makes possible. I give you,

“Functional Programming For the Rest of Us.”

Take the 10 minutes to read this and enjoy!