Thoughts on Functional Programming Podcast

Lisps have traditionally been highly interactive. This allowed AI researchers and language developers to iterate quickly and learn about what works and what doesn’t. How can you tap into this in your workflow?

I use this pattern all the time when I’m programming, and I don’t know if it has a name. It involves lifting a value into a new space, solving a problem with it, then lowering it back down.

Can you do Functional Programming in any language? More importantly, can you learn FP in any language? What does it mean to call a language “functional”?

In Functional Programming, everything needs to be first class? But what does that mean? And why is it important? I discuss the idea of composing Actions and Calculations dynamically.

We have so much memory now, compared to the 1970s, that it often seems like we have memory to burn. I misspoke in a previous episode where I made it seem like I’m in favor of wasting memory. But what did I mean instead?

As I develop and expound this theory, it may seem to be too complicated. Isn’t functional programming just programming with pure functions? Why make this more complicated than that? We talk about my reasons and my goals for the theory.

If I write a straightforward solution to a problem in Clojure, it might take me a thousand lines of code to solve it. To handle all the corner cases and everything, I got a thousand lines of code. However, if I take this other approach where it’s much more indirect, or instead of solving the problem that I have in front of me, I write a language–a DSL. The DSL could take me 500 lines of code to write. That’s a fairly large DSL. Usually they’re much smaller, but it takes me 500 lines of code. Actually, writing the solution in it only takes 10 lines of code.

In school, we learn about a few algebraic properties. These apply very well in functional programming because their expression is so simple, their definitions are so simple and they really focus on how things compose.

I think the real trick to all of that is always think about the data as being forever. One thing that we often do when we’re programming is we want things to be a little bit more concrete.