Can you do Functional Programming in any language?

Can you do functional programming in any language? Is it possible to do functional programming in C, in Java, in assembly, in Ruby, or do you need a functional language? What is a functional language anyway?

Transcript

Can you do functional programming in any language? Is it possible to do functional programming in C, in Java, in assembly, in Ruby, or do you need a functional language? What is a functional language anyway?

My name is Eric Normand, and these are my thoughts on functional programming. The short answer is yes, you can do functional programming in any language.

Functional programming is a paradigm. It's all in your mind. It's how you break down problems. It's how you see things. It's how you think about the problem, and how you structure solutions.

https://twitter.com/ericnormand/status/1070407923589881858

If you're thinking about the thing in terms of actions, calculations, and data, then yes. You can do functional programming in any language. Just like you can do object-oriented programming in any language.

Object-oriented programming is also a mindset. It's a paradigm. You could figure out how to make an object system with messages passing around in C.

https://twitter.com/ericnormand/status/1056561656610914306?ref_src=twsrc%5Etfw

In fact, I've done that before. What I found though, and what I think a lot of people find when they do something like that, when they create a little object-oriented system in a language like C, is that so much relies on the discipline of the programmer because you could always slip out of that object-oriented programming. You can sneak behind the nice veneer you put on, and just mess with pointers, and do all the C stuff that C allows you to do.

If you're doing functional programming in C, you would have all of those same possibilities. They would tempt you. People who are really good at functional programming, who are used to it, who are well versed in how to solve problems with it, they tend to...and they like functional programming, too. They're choosing to do functional programming.

They're going to have a better time because they're choosing to use functional programming. It is a choice that they are imposing on the language on the program that they're writing. Even if the language doesn't provide something, they will write it themselves.

https://twitter.com/ericnormand/status/1024671124867768320?ref_src=twsrc%5Etfw

They have this discipline. That is what allows them to do functional programming, even when the language is not really helping them. That's my short answer. A short answer is yes, you can do functional programming in any language.

The long answer is you probably don't want to. One reason is that relying on discipline might work if you're writing a small program or you're writing a program by yourself or on a very small team, you can handle the discipline of it.

You can handle the copy on right discipline or the append only semantics or the lack of any help figuring out what is an action and what is the computation. It's all discipline. You have to know this thing is an action. I shouldn't call it from a computation or a calculation.

[background sounds only]

Eric: The other thing, the other part of the question is, if you're going to...yes, you can do functional programming in, let's say JavaScript. If you don't know functional programming, you're not going to learn it in JavaScript. It's like trying to learn to speak a natural language, like trying to learn.

Let's say you don't speak Spanish. You're going to try to learn Spanish just from people who also don't speak Spanish. Maybe just from a book. You have no help. Sure you can do it with tons of willpower. Or you could get on a plane. You can fly it to a Hispanic country, a country that speaks only Spanish. You can start picking up this and that.

You have people to ask for help. All the signs are in Spanish. It's just immersion in Spanish. You're going to pick it up. You're going to feel like this need to learn it. Even if you still learn it from a book, there's a lot of stuff pushing you in that direction.

That's been my experience with functional programming in other languages that you can do it. If you don't already know functional programming, you're going to feel it's not right. You're not going to learn it. You're never going to get over that hump because you can always just revert back to whatever the language is, whatever is natural for that language.

https://twitter.com/ericnormand/status/1021772107053719553?ref_src=twsrc%5Etfw

That's what I find, is people who say, "Oh, I know functional programming. Sorry, I'm learning functional programming. I've heard I can do it in JavaScript." You're going to learn this much functional programming and not really get the meat of it. There's a lot of people who...it's all cool. They don't get very deep into functional programming.

That's cool if that's how deep they want to go. There's deeper stuff that they're going to miss because they're not forced to find functional solutions by their language.

[background sounds only]

Eric: Just like you can learn to say "gracias" and that kind of thing. Just from picking it up. You're not going to learn it. You're not going to learn all the Spanish by doing that. Even conversational Spanish.

Yes, you can do functional programming in any language. It's going to take discipline.

You're not going to be able to learn functional programming and three is, it's going to be a pain. That discipline could be a real pain. It could feel unnatural. It could feel like it doesn't really work in that language. It could feel like it's not the language's fault, it's functional programming's fault.

Functional programming is totally impractical. It could feel like that. I don't recommend people try if they're not already well-versed in functional programming.

https://twitter.com/ericnormand/status/1050038445836554240?ref_src=twsrc%5Etfw

I do not recommend they try doing something like functional Java, functional JavaScript as an introduction to functional programming. It's going to feel like, "Why am I jumping through all these hoops? Why am I copying everything? Why can't I just modify this variable?" It doesn't make sense because they're right.

My language is letting me do that. It's the simplest solution. Why should I do this other thing? Of course, the answer is, until you do all functional programming everywhere, immutable everywhere, you don't realize the benefits.

https://twitter.com/ericnormand/status/1012048216790007810?ref_src=twsrc%5Etfw

That brings us to what is a functional language. Of course, it's one of those controversial topics where you can say, there's no real answer. Anytime someone actually tries to define it they're missing stuff. It opens up the doors for argumentation and flame wars.

I don't want to go there and say, "Here's the definitive answer. Here's the definitive way of defining what a functional programming language is, what it takes to be a functional language."

I actually don't think it's that meaningful. When I use the term, what I mean is a language that helps you do functional programming. A language that helps you do functional programming in whatever way that the language chooses. In Haskell, it helps you do functional programming because everything is immutable by default.

https://twitter.com/ericnormand/status/1051488340837654528?ref_src=twsrc%5Etfw

You have functions which are pure. You can do calculations. You have an IO type for doing your actions. The language helps you. The type system helps you by separating those things out, the calculations from the actions. I also think that Clojure is a good functional language. It's functional because it has immutable data structures by default.

It doesn't help you separate out the calculations from the actions very much. It does encourage you to separate them out. They have been separated out in much of the core library, for instance.

https://twitter.com/ericnormand/status/1058011319180410880?ref_src=twsrc%5Etfw

It also helps you do that stuff I've talked about before, about reasoning, about the actions, reducing, collapsing the states of the actions into a smaller set so that things become more manageable. Because it does all that, I say that it's a functional language.

JavaScript has functions, has higher-order functions. It doesn't have the immutable data structures. It doesn't encourage immutability in any way. It's much less so. If you want, you can call it a continuum. It also encourages this other style where you're using mutable objects and have these methods. It has the class syntax.

https://twitter.com/ericnormand/status/1035545261857300486?ref_src=twsrc%5Etfw

It's actually not so functional when you look at it as a whole. There is a nice functional subset in there which would make it really nice for doing functional programming if you could restrict everything to that subset. I would say that that's a pretty good functional language.

It's a mutable functional language. You can work around that with a little discipline. Anyway, that's how I think about it. It's a spectrum. I think language subsetting is an interesting idea.

Like JavaScript, "Aw, it's this thing that everyone in the world is going to use." You can find a little slice of JavaScript that works for you. You can set up some linters and have a reasonable functional language there. Is that too windy in the microphone? It's pretty windy from my perspective.

All right. For those of you who have stayed till the end, you have something special. There's something I want to say that's related to this immersion in the functional language to help you learn functional programming. I worked in Haskell for over two years, almost three. What I mean is I was immersed in Haskell.

I was immersed in a language that was definitely functional. There was almost no other style possible in Haskell. I had already done a lot of Clojure on the side on my own projects and used it at small things at jobs and stuff that wasn't going to go into production.

An immersion in Haskell really taught me to appreciate the separation between calculations and actions. Just in a way that I find that a lot of Clojure programmers don't appreciate the immersion in it, and the type discipline, too.

The type discipline of...this is probably a topic for another episode. Just like in actions where anything is possible really, you want to restrict that. You want to collapse down the possible states into a fewer number. If you have something where the order matters maybe you can make the order not matter.

The two states where you have A comes first or B comes first, now you can make it doesn't matter. It's the same. You get the same answer. You collapse the two states down into one state. Just in that same way, I feel the type discipline that Haskell's type inference engine enforces, collapses states.

A Clojure programmer might say, "I'm going to return a number or a string or nil." That's really three possible states. You're going to have to check those later. Whatever consumes that return value. You're going to have to. You're going to have to check. You're going to have to branch. You're going to have to do something based on what you got there.

Whereas in Haskell you can only return one thing. If you do want to return multiple different things, you have to be very explicit and encode that in a type. You're making that choice, "This is important enough. I'm going to use all these cases later, so I'm going to make a type for this."

In Clojure, we're much more loosey-goosey. That opens up the possible states. States are multiplicative. They compose by multiplying each other.

https://twitter.com/ericnormand/status/1004377507624300544?ref_src=twsrc%5Etfw

All right. That's going to be another episode, so stay tuned. Subscribe to the podcast. Subscribe to the YouTube channel.

This has been Eric Normand. I'll see you later. Bye.