Podcast: Dig into functional programming with Venkat

Functional Programming Podcast

Functional Programming lambdaWe’re joined this week by Venkat Subramaniam digging into functional programming, why it’s exciting and how you can begin to see the benefits.

Want more Venkat (or more functional programming)? We’ve created an entire Venkat track at the 2016 UberConf. UberConf is the ultimate tech event for the serious software practitioner. With 11 concurrent tracks, days that begin at 8:30AM and end at 10:00PM it’s definitely not for the faint of heart.

Full Transcript

[background music]

Announcer:

You’re listening to the “No Fluff Just Stuff” podcast, the JVM conference series. With dozens of dates around the country, there’ll be one near you. Check out our tour dates at nofluffjuststuff.com.

Michael Carducci:

We’re here at Art Conf West in San Diego, and I’ve managed to track down the legendary Dr. Venkat. How are you?

Venkat Subramaniam:

Good. Pleasure being here. It’s fun and beautiful, San Diego.

Michael:

San Diego’s very nice. We’re actually recording this up in one of the rooms overlooking all of La Jolla. It’s a great view. If you’re not here, you’re missing out. We’ll be doing it again here soon, in Florida, in December which will be great.

It really is a challenge to track you down. You’re certainly one of the most impressive speakers and also the busiest. In UberConf, how many sessions are you doing?

Venkat:

I don’t even know. I think 17 or so.

Michael:

17.

Venkat:

Yeah.

Michael:

That’s about 26, 27 hours of speaking over three or four days?

Venkat:

It’s a lot easier when we don’t count.

[laughter]

Michael:

There are legends about Venkat, if you’ve never met him, that he sleeps three hours a day. Is that true?

Venkat:

Close to four, four and a half hours.

Michael:

You’re slowing down, because you’re getting older.

[laughter]

Michael:

I understand that on an international plane ride, you’re able to write about two-thirds of a book? On a flight from Denver to London, is that…?

Venkat:

[laughs] I’ve written quite a books on flights, yes. I have productive time on flights, so I’m fortunate for that.

Michael:

I’m fortunate that I can sleep on flights, but now I’m starting to second guess that as a really valuable use of my time. It’s actually very good that we can sit down and talk like this, because it gives me a chance, all of the legends that I’ve heard about Venkat.

If you’ve never seen him speak, I would encourage you to do that, to see him at UberConf. You’re at Angular Summit as well? Being able to see Venkat speak is an experience in itself. You’re brilliant, you’re entertaining, and you’re doing all of these things while live coding.

Venkat:

I’m humbled. Thank you, though.

[laughter]

Michael:

I got to watch one of your Angular talks at the Angular Summit, and it was just incredible that you were able to all these things.

There’s a joke. A lot of the speakers on the NFJS tour, we talk about this idea of just one day, for fun, we’d put all of our slide decks on thumb drives, put them in a hat, and we all draw one at random and try to give the talk. Everybody’s afraid they would get Venkat’s, because they would basically get an empty text file.

Anyway, one of the things I want to talk to you about, you’re certainly a gifted engineer. You’re a brilliant educator. One of the things I see you speaking more and more about right now is functional programming, that it’s become this really hot topic.

A few weeks ago, we talked with Daniel Hinojosa about Scala. I want to take a step back and just ask, why has this suddenly been reemerging as a trend? Functional programming seemed to be the red-headed stepchild, as it were, for a long time, that it was OO-way or no way.

Venkat:

That’s actually interesting, because if you really think about it, one of the things we do as programmers, day in and day out, is deal with complexity. I’m going to say, imperative style of programming is more complex than functional programming.

One of the things, the two types of complexities we deal with, one is inherent complexity, and the other is the accidental complexity. When it comes to using imperative style, which we have all used for decades as mainstream programming, imperative programming is inherently more complex than functional programming.

The reason for that is in the imperative style of programming, we communicate not only what we want to do, but you have to take the time and effort to communicate how to do it. In a functional style, we use more of a declarative style. We focus more on saying what to do, and the underlying libraries take care of how to do it.

In a way, an analogy I use is imperative style is like talking to a toddler. You not only tell the toddler what you want, but you repeat every step of what to do. The next day, you get to do this all over again, and again, and again, for the next 18 years. That’s called parenting. That’s kind of like programming in imperative style.

With functional style, you simply say, “Could I have a cup of water, please?” You don’t have to get into this argument about what makes the water, or whether something’s a water or not, like you would to a teenager.

Michael:

Tea, Earl Gray, hot.

Venkat:

[laughs] Yeah. As a result, you get water when you want water, and the rest of the details are taken care of. That’s one of the nice things about functional programming.

Why is it so important and relevant right now? The reason for that is we are getting to the point where complexity has grown so much over the past few decades. Object-oriented programming did that for us. The main thing about OO was to raise the level of abstraction so that we can deal with complexity, and it’s done that.

I want to emphasize, I don’t think we want to get into this battle of OO versus functional. I merely want to see this as a battle of the imperative versus functional. As a result, we can mix object-oriented and functional style of programming in a very healthy measure, because what we are about to kill and fight is accidental complexity, not the good parts of OO.

It’s the imperative parts that come into OO programming that hurt us. With emerging complexity, with big data, with more concurrency, with a process as multi-core processes available, the demand on our programming skills has increased tremendously.

Programming ability has not kept up with it, but thankfully, what has been created 50, 60, 70 years ago, these guys were geniuses. They created this, and they said, “We’ll wait for you kids. For you to grow up one day and make use of this.”

To me, what excites me about functional programming is our ability to drop this accidental complexity, and focus on the essence of the problem. It’s the essence versus ceremony.

Imperative programming has been a lot of ceremony. Functional programming gives us the essence of it, so we can go off to handle these complexities with the inherent complexity on our hand, rather than the accidental complexities.

Michael:

You mentioned about taking the best parts of OO and the best parts of functional programming and using them as appropriate. I’ve done a lot of my development in the Microsoft world and in .NET, and I’ve seen more and more of that in C#, more and more of these elements being introduced in the C#.

There’s a tremendous ability to do exactly that, that there are so many places where Lambdas work really well, or some of the task threading libraries in .NET 4.5 are tremendously useful, the way you’re defining these kind of worker actions.

Are we going to see the same sort of thing on the JVM? I know we’re seeing some of that in with Java 8, in introducing Lambdas, and we’ve seen a lot of that with closures in Groovy.

Are we going to get more towards this, some technologies that allow us to do that, or do you think there’s going to be more of a parting of the ways in terms of functional go closure, and OO go Java?

Venkat:

I would argue, as much as I like C# — it’s a great language, but one of the biggest gripes I have about C# is they got into functional programming and Lambda expressions through the back door. They first introduced Link, and that’s one of the reasons why, if you look at all the functional-related APIs in C#, they are so different from what the rest of the world uses.

Part of the reason for that is they introduced Link in C# first, then they introduced Lambdas, whereas F# and Java, and a lot of other languages, really focused on Lambdas as the first one, and then came along the other things.

In a way, I would argue, it’s a baggage that C# is going to carry for a long time, that Java and other JVM languages don’t have to.

Michael:

Java has a lot of its own baggage.

Venkat:

Of course, but not that particular baggage. [laughs]

Michael:

That’s true. That’s changing, too. In looking at some of the things that are happening with Java now…

I don’t want to get too off topic, so a question that I really want to ask you, though, as an engineer, as an educator, if I’m inspired to start working functional programming into what I’m doing, how do I do this without introducing more accidental complexity? Let me put it differently, how can I do this without alienating my team?

Venkat:

One of the things is to inspire the team where they feel that this is actually something better for them rather than a task that they get dragged into.

A good way to do that is to…it’s like little sugar candies. You write a piece of code which is very expressive. Don’t thrust it on them, but just bring it up along the way, and they’re like, “Well, that’s different. That’s weird, but what does it do?”

“Well, here’s the reason why it’s better,” and we can start doing code reviews, and along the way, suggest, “Hey, this is great, but if you would like to, here’s a different way to write the same thing.”

They may ignore it the first few times. They may disregard it the first few times, but the more and more they begin to see this, “Hey, can I try this?”, and they themselves begin to try it for themselves, and they’re sold.

The best way to convince one’s self is for them to realize this is better for them, rather than being told that it is. I’ve seen this already with my own students.

For example, when they write an imperative style, I would show them something in functional style, and then they would try the next few things. I would see the code the third time they write, and they have gone on to write the code themselves, seeing these examples. That’s when you know, they are beginning to really adopt on their own, rather than being forced down to do it.

Michael:

You definitely want to build enthusiasm. Neal Ford is very fond of saying, “Demonstration trumps explanation, every time.”

Venkat:

Absolutely.

Michael:

Whenever I’m trying to sell something to a team, the three questions that I try to convey, “What is it? What does it do? And why should I care?”

The team should be able to know the answers to those questions, why they, as the team, should care. Doing exactly that, a demonstration, exciting people about these capabilities, because if you’re doing it right, it is truly solving a problem that you or the team has been grappling with.

Venkat:

One of the problems with functional programming is people are very unfamiliar with it, so they become very intimidated looking at it, right?

Michael:

Yes.

Venkat:

On the other hand, when they begin to see that the code is concise, the code is expressive, the code is actually easier to understand once they start becoming familiar. Then they adapt on their own.

That is one of the exciting things about it is it is a technology where there’s going to be resistance in the beginning, but they get convinced very rapidly once they know they are not in a threat. They’re not under force to change it, and then once they play with it a little bit, then they’re like, “Wow, this is actually better than what I thought it was,” [snaps fingers] and the adoption becomes a lot faster after that.

Michael:

I know you’re a very busy man. Can you leave us with one thing, that if this is something that we want to start to explore, what’s one suggestion that we go away and do?

Venkat:

My recommendation is I’m a huge fan of this thing called “Make it work, make it better.” Don’t try to force yourself to do functional programming. Write it in imperative style. “Hey, I’ve got the code working.”

Have automated tests for it. Now that I have the test in place, the code is working, I’m going to take both steps to change this code into functional style. You might succeed at the first try, but you may fail, even in the fifth try, but bring it out to somebody and say, “I’ve got this code. What do you think?”

As you begin to explain to them, you may get better ideas, or they may give you better ideas, and about the seventh time, you nailed it. This takes a few months to really get better, but the more and more and more we try, we are not going to code in functional style without actually thinking in functional style.

That is the most important thing, is to start changing this way of thinking, and the more we practice, practice, practice, we get better at it.

Michael:

Of course. Thank you so much. I really appreciate you taking the time to join us today.

Venkat:

Pleasure, thank you.

Michael:

I’m looking forward to seeing you at Angular and at UberConf as well.

[background music]

Venkat:

Thank you, for sure.

Michael:

Real pleasure. Thanks again.

Michael:

At No Fluff Just Stuff, we bring the best technologist to you on a road show format. Early bird discounts are available for the 2016 season. Check out the entire show lineup and tour dates at nofluffjuststuff.com.

I’m your host, Michael Carducci. Thanks for listening and stay subscribed.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*