Podcast: Scala, functional programming and being multi-lingual

Today we’re joined by Daniel Hinojosa. We’re discussing the how and why of functional programming, the benefits of being multi-lingual and how to make the mental shift to functional programming.

 
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 our tour dates at nofluffjuststuff.com.

Michael Carducci:

Hi, we’re at the No Fluff Just Stuff Great Lakes Software Symposium here in Chicago, and I’m joined with Dano.

Daniel Hinojosa:

Hi, how’s it going.

Michael:

Daniel Hinojosa. I’m going to be honest with you, Dan. I have never coded a lick of functional code. One of your areas of expertise is Scala, which, as I understand it, is under the functional paradigm.

Daniel:

Sure is.

Michael:

If I were a Java, a Groovy, or a miscellaneous OO person, what is the difference, and why should I care about functional programming? More specifically, why should I care about Scala?

Daniel:

Let’s take the first one first. I guess that means in order. [laughs] Functional programming changes the way you think about code. It gets rid of a lot of extraneous code. You can get right to the point. You can be really concise. You now have a way to model your verbs.

So far, we’ve done nothing but nouns in our code. Everything is a being. Everything represents a thing. But now, we can represent a verb. If you think about that and how that drastically changes the way you program, you can program addition. You could program the way you calculate a certain tax. You can program all these particular verbs.

Now, you could just treat this as a separate entity or a separate object when you bring things together. No longer do you have to cage up these verbs inside of a method. You can reuse them. You can compose them. This is going to change the game and the way you design your code. Again, you’re going to get rid of a lot of code by doing this.

Michael:

We’re going to lose the lasagna code?

Daniel:

Yeah, I think so — all the different layers, all the different things, all the biolerplate that you were used to before. All of a sudden, the conciseness comes into being. You feel good about your code. It is cleaner looking code. Overall, you’ll appreciate your design that you have a the end.

As far as Scala… [laughs] Scala’s my bet as far as the programming language. I have a talk for No Fluff Just Stuff.

Michael:

And you just completed a training series.

Daniel:

Yeah, I completed a video series on O’Reilly that ought to be out probably in the next month. Makes a great Christmas gift. [laughs]

Michael:

So some time November.

Daniel:

I think so. It’ll probably some time November, maybe early December, hopefully. We still have some editing to do. Title remains unknown. We have to come up with good title. It’s a Scala series. I’ve been teaching Scala for a long time now.

The recipe is really good. I take it easy, but at the end, I really hit on some of the harder topics. I try not to introduce anything that is going to overwhelm the listener. I take it one bit at a time, one concept at a time. That’ll be coming out on O’Reilly Publishing.

Michael:

Back to the original point. Why Scala versus Clojure, F#, or anything like that?

Daniel:

I’m very interested in learning F#, but back to the question. My answer that I was starting off with is I have a presentation that I truly enjoyed making called "Learning Five JVM languages in the Next Five Years." My bet on this is that it is Java 8, Groovy, Scala, Clojure, and JRuby. We’re learning all those languages.

I want everyone to learn each of those languages, and for you to discover — or whoever’s listening — what their preferred language is going to be. My bet is it may not even be Java anymore. There are a lot of great languages on the JVM. I would like to endorse either one of those five. You’ll truly appreciate what’s out there.

When I said Java, I said Java 8. Java 8 is fundamentally different than any of the other Javas. You’ll have a certain gratitude for what the other languages are offering. My winners, and what I think your winners will be, as well, are both Scala and Clojure. For myself, I enjoy Scala because I still enjoy the object-oriented code.

I still enjoy the Javaness of being able to create objects, wire objects together, and do whatever I want, and, at the same time, having some functional programming. Clojure’s going to be different in that it’s pure functional all the time. There are some ways where you can instantiate objects, but as far as creating your own classes, don’t count on it. That’s not what Clojure is about.

There are different philosophies when it comes to these languages. That’s a reason I like Scala, but I think you’re going to fall in love with either one of those. I’m strong advocate of learning as much as you can. I usually use the word "Language bigot." iIt’s probably too strong, but I think a lot of us are sometimes language bigots.

"No, that’s my language. My language is the most preferred. That’s all I’m going to stick with." If you explore your options, you’re going to find out that you learn a lot about yourself, you learn a lot about programming. You learn about things that are deficient in something like Java, and you’ll learn a lot of things that are advantageous with Java. Over time, you end up becoming a better developer.

Michael:

One of the things that I’ve learned over the years, trying to be multi-lingual, is absolutely that. You get a whole new perspective. Ultimately, the more you learn, the more you can learn. I’ve found that there is no limit. Every single thing you learn paves the way for learning something else.

Daniel:

Right, and this has nothing to do just with programming languages. It works with linguistics. You learn a Latin language, and you already build upon that with another Latin language. If you learn French, Spanish is going to be dramatically easier. Same way with programming languages.

You know Java, so you have a pretty good heads-up on other object-oriented programming languages. Once you start learning lambdas in Java 8, you’re going to have a fairly better time with Scala. Once you learn Scala, you’re going to have a better time learning languages like Haskell. You’re going to actually have a better time learn Clojure, as well.

Or, if you want to take to Clojure, start with that first, and then head over to Scala. You have a basis with everything. You have a plateau after a while. You gain this plateau of knowledge, and then you start making more reasonable choices. Even if you ever go back to Java, you make more reasonable choices when you go back to your language of choice.

Michael:

That’s actually the really exciting thing. It just seems like, for as long as I remember in fact, that it was OO or nothing. Every single line of code that was ever reviewed by a peer, it had to pass the solid test. It had to be purest OO, even though that wasn’t always the right tool for the job.

The JVM is flourishing with all the new languages. I say "New," but all the languages, they’re finally reaching maturity and reaching that critical mass that we can sit an look at thing objectively and make the right choice.

Daniel:

Right. This happened during the Scala presentation. Someone was asking about databases and functional programming. It’s a tough call there, and it was still a tough answer. I’m still trying to find the best answer, because functional programmings are hand in hand with immutability.

When you think about things like Hibernate and all the ORMs that you’re used to, that needs mutability, so you need to have the ability to setters. But, when you’re doing functional programming with immutability, all of a sudden, things get a little bit harder.

In the Scala sphere, there are things like Slick, which is a functional relational mapper. It’s not an object-to-relational mapper. It’s very interesting. In your usability, it works out very well, because you can use your map filters or what have you. In effect, what that’s going to do is it’s going to go out to the database and perform operations. That’s cool.

What’s not cool is the setup, and that setup is going to be a little bit rough, especially once you start building relationships and things like that. They’re trying — I’m not bashing that particular program — to meet a need. But if you thought OO-to-relational database mapping was hard, there’s functional-to-relational database mapping, and that’s even more difficult.

Michael:

That’s why I think it’s interesting what Datomic has done. They’ve found the right mesh of some of the things that are great in relational databases, some of the things that are great in object databases, and they also introduced this concept of immutability. You have this third dimension of time. Each record, essentially, is immutable, and you just have versions of it.

Daniel:

It always seemed disgusting to delete data from a database. You always felt that something was wrong. Even though you updated a row on a database, you always felt afterwards, "There’s something wrong with this. We should be able to cache this, over time," and, "Who changed what, and when?"

Michael:

Then you end up doing really hacky workarounds with triggers and audit tables.

Daniel:

Yeah, and it’s just an absolute mess. It should just be part of the data, and it should be time stamped. I think they’re right on with this. If the data’s immutable, then your language is immutable, and I think it may be a good fit. I would love to see how Datomic’s going to fit in here in the future.

Michael:

Yeah, I’d love to see it get a little more traction. It’s kind of underrated right now, is my opinion.

Daniel:

Yeah. I think you’d probably have to do a good push on marketing. Perhaps. I don’t know.

Michael:

If I’m going into functional programming from an OO background, I’m very comfortable with the design patterns around OO. I’m very comfortable with the thought process. How does that change? What’s the broad strokes of the philosophy?

Daniel:

Your design patterns are still going to be the same. There isn’t anything different about it. If you want to start off with the frame of mind that the only thing a function is, is think of a function as an object, if that helps you out. Just think of a function as an object that performs one role, and that’s one verb. Just think about a reference that points to it, and now you just plug in that verb wherever you want.

The point is, after that, then you have syntactiture that helps you out to do whatever you need. That’s just going to be the frame of mind that you have to choose. But again, I guarantee that once you get that frame of mind, your code going to look a lot better. You’ll be able to understand things in a better way off your code.

Michael:

Right on. Bring it home for us. Wrap it up. What’s the elevator pitch for Scala?

Daniel:

Elevator pitch for Scala, let’s take from what Java has. You have the functions. You don’t have to declare your types all over the place. In other words, you don’t have to have all these generic brackets all over the place. You have type inferencing. You have pattern matching. You have implicits.

Implicits are like the way we do wiring without using Spring. Implicit’s also our way for us to add methods to classes that don’t exist. If I want to add a method called isOdd to Integer, I could do so. Everything melds well together, but we have the full, functional programming suite. You could do maps, flat maps, everything.

Here’s the thing. Part of my sale for Scala, and I do this in all my trainings and my talks, is I don’t mind telling people that Scala’s hard. Then people are like [gasps] , [laughs] "Did he just say that? What’s wrong with you?" Then I usually give them the spiel that a crane is hard, too.

Whenever you have to operate a crane, you have to learn about the mechanics. You have learn about wind. You have to learn about safety. You have to learn about weight. You have to learn about all these different things when it comes to operating a crane, and it takes a long time.

But, in the midst of that learning, after you do learn all of this, all of a sudden, you can start moving bricks up to the top of buildings at greater speed than if you just lifted these bricks on your shoulders and lifted them up by one, by one.

That is Scala. That’s why I don’t mind saying it’s hard, but I think it’s very well worth the investment. Once you bring that investment in, the rest is greater efficiency on your part.

Michael:

Right on. Sounds like it’s a net benefit. Not only that, again, I am a huge fan of being multi-lingual, and I will chastise myself for being a little slow to get onto the functional bandwagon, but I’m sold.

Daniel:

Yeah, you were a .NET guy, weren’t you?

Michael:

I was. I looked at F# very briefly, but I never had a use case for it.

Daniel:

Someone was just showing me today about C# and all the lambdas with C#. That was really impressive, as well. If you’re spying on us JVMers right now on this podcast, [laughs] definitely, C# has a lot of lambdas as well. I encourage you to learn those. Definitely F#, I wouldn’t say it’s the equivalent, but I guess that is the functional programming on the CLR as Scala is to ours on the JVM.

Michael:

Just on the side, I am actually a big fan of what they’ve done with C#. Absolutely, in the early days, you could tell that they just ground the serial numbers off of Java.

Daniel:

Right, but that’s flipped.

Michael:

That’s flipped, yeah. When I started sitting in with some of the talks on what’s new in Java 8 and everybody was really excited about lambdas, I was sitting next to somebody who’s a Groovy programmer, and I’ve spent some time with Groovy. I was thinking, "Oh, OK, well this isn’t that new to the JVM, but it’s new to Java?"

I know things have changed, but I would have thought Java would have been pushing the JVM, but it’s really kind of trailing.

Daniel:

Oh, definitely.

Michael:

Java 8 compared to .NET 4.5.

Daniel:

We were just looking up the history on my TDE talk, because this point came up. We were looking at the history behind it. When we were basking in the glow in JDK 6, C# already had lambdas.

[laughter]

Daniel:

Yeah, so that’s a long time ago. I asked someone who was talking on my TDE talk, "How pervasive is it?" He was saying that, right now, C# programmers use lambdas all the time, and Java programmers, "I really don’t know. I don’t know if they’re going to get used to this functional sort of thing or not."

Michael:

The language and the structures in C#, over the last few years, have just become so elegant. I’ve probably worked professionally in maybe half a dozen languages now, but none of them functional.

Daniel:

If you’re interested, I have a GitHub project. It’s at github.com/dhinojosa, [inaudible 16:56] at the end there. It’s called language-matrix. I haven’t done anything within the last three or four months, but what it is are the 10 languages that I claim to know. [laughs] What I have is samples of code for each one.

I have a Hello World sample code for each one of those 10 languages. I even forgot what they are, but I think I have C, C++, JavaScript, Ruby, Python, Java, Scala, Clojure, and two more — Haskell and Lisp. That’s what I have on there. Those are the 10 languages. It’s a project that I’ve been working on [laughs] for the last couple of years, and probably going to work on for the next 10, as well. It’s just a hobby of mine.

I really like the idea of just knowing multiple languages, because here’s the thing. I can pick up on other languages really quickly. I was reading the documentation for Rust. I don’t know if you’ve heard that language.

Michael:

No.

Daniel:

There’s a Rust programming language. It’s a functional language, but it looks a lot like some of the other languages. I can tell you, just the thrill of looking at documentation for another language, and then just using certain words that you just pick up. You either learned it because of Lisp or because you know Scala or any one of those. Picking up languages is now just a matter of pick up a manual, "I understand it. Let’s go."

Like a seasoned car mechanic gets a new car in his or her shop, takes a look at the manual and, "Oh, yeah, I got it." That’s the kind of feeling you want to have as a professional programmer.

Michael:

I think I only read Lisp at school.

Daniel:

Really? It was funny, at school, I was kicking and screaming. It was Scheme, not Lisp, that I learned. I was like, "No, you can’t do this to me. This is dumb. Why do I need this? The world is Microsoft right now. Just give me C++ and let me build some GUIs. That’s all I need to know to get through this life. What do you know, Professor? Why are you trying to shove this down my throat?"

Nope, wrong. Wrong, Dan, wrong, wrong. I took to Scheme and I’m like, "Wow, I love this." At first, I was just like, "I don’t get it. I don’t get it," but then I got it, and that was a big, huge deal. Lo and behold, years later when I’m trying to learn Clojure, it didn’t take me that long.

In fact, I did a Pomodoro Technique to learn my Clojure. If you’re not familiar, real quick, Pomodoro Technique is 25 minutes, going all out, whatever you want to do, learning, programming, whatever you want — playing guitar — and then take a five minute break and really just focus on it 25 minutes.

In 2014, January 1st to be specific, I said, "You know what? I’m going to put this into practice. I’m just going to do one Pomodoro a day and learn Clojure, and just see how far it would get. And I’m going to limit myself to that one Pomodoro."

Michael:

Twenty-five minutes, hyperfocused on Clojure, and you’re done.

Daniel:

Everyday, yeah. And I tell people, "Just treat it like your crossword puzzle, like you get up and have your coffee, and you do up a crossword puzzle. Your brains are really squishy in the morning, anyway, super absorbent. Get that coffee, get super absorbent, and just learn Clojure for those 30 minutes, stop."

For me, one, I had the background with Scheme and Lisp, but really, I would say from January 1st towards the 1st of April, I could legitimately say, "I know Clojure." It happened relatively fast. The more and more programming languages you have under your belt, the faster it’s going to be.

Michael:

It ultimately gets to a point where you’re just learning new syntax.

Daniel:

That’s right. That’s all it is, yeah. Absolutely.

Michael:

Thank you so much, Daniel.

Daniel:

Right on.

Michael:

If you get a chance, come out to one of the NFJF shows on the road, on the tour, and check out Daniel’s talks.

Daniel:

And check out the video series, whenever it comes out, on O’Reilly. Though I love this podcast as well, I’m part of another podcast called "The Java Enterprise Newscast," with Kito Mann and Ian Hlavat. Check that out as well.

Michael:

Thanks so much, and we’ll see you on the road.

Daniel:

Yep.

[background music]

Announcer:

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 line up and tour date at nofluffjuststuff.com. I’m your host Michael Carducci. Thanks for listening, and stay [inaudible 21:51]

Leave a Reply

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

*