Functional Programming for Business
Is functional programming right for your business? In this talk, I get past the hype and gives you the straight dope.
Recorded at BarCampNola 2016.
Slides
Transcript
**Eric Normand**: I already started the discussion. This is about functional programming and business.
Now, there's actually quite a lot of hype about functional programming right now. It's kind of exploding. Has anyone experienced the hype? What have you heard about functional programming?
**Audience Member**: Essentially, since [inaudible 0:36] is dead, we're going to move towards functional programming in order to continue speeding up and [inaudible 0:43] problems be broken up into pieces.
**Eric**: Thank you. Anybody else?
**Audience Member**: Amaze balls.
[laughter]
**Eric**: Amaze balls. There's pure hype, no content. Anything else? Yeah?
**Audience Member**: [inaudible 0:59] .
**Eric**: Parallelization.
**Audience Member**: You hear a lot about functional programming is more expressive than [inaudible 1:08] .
**Eric**: Yeah, I've heard that one too. It's more expressive, maybe more declarative. That might mean shorter programs to do the same thing. All of those things are true. I'm going to say that, including the content-free one — amaze balls — but right now I want to focus on business.
It's really cool to hack on something in your spare time and have fun with it, and it being amazing and amaze ball-sy, but there's a practical side to business where you've got to have a real reason to use it. That's what we're going to talk about.
Also, there are some things I'm going to say that I believe but I don't have a citation for it. I cannot point to something like, "This is where you learn that this is true." Most of this is from my personal experience instead of a paper or somebody else's experience that is maybe better documented.
I'm going to put this on just like you see on Wikipedia everywhere. We still believe Wikipedia, right? Even though it has citation [inaudible 2:25] .
This is another question for the audience. What is functional programming? You all are here. You must have some idea.
[laughter]
**Eric**: Anything. No wrong answers.
**Audience Member**: Side effect [inaudible 2:47] program with just setups with functions.
**Eric**: That's it?
**Audience Member**: [inaudible 2:56] .
**Eric**: Thank you.
**Audience Member**: Is it a fixed term?
**Eric**: Maybe it's not a fixed term.
**Audience Member**: [inaudible 3:02] ?
**Eric**: Oh, you're asking me? I'll answer it, but I want to hear the audience first.
**Audience Member**: Given the same input, you want to get the same output.
**Eric**: Cool, nice. Yeah?
**Audience Member**: I usually try to come up with some definition that mean pose-ability.
**Eric**: Pose-ability. Cool, nice. I'm going to...
[laughter]
**Eric**: I'm just going to oppose it to object-oriented. I'm not saying that that's the definition. I tuned this for business-y folks that might be like, "What is the difference?"
It's not object-oriented. As we had some great definitions, and these are all correct. I was hoping for one that was not correct, that I could be like, "You're wrong!"
[laughter]
**Eric**: I couldn't, so, boom. They're just loosely...There's some ideas in it that are kind of connected, that all go together, just by circumstance. There's no way that you could say, "Object-oriented is classes and methods. You're done." It's not so simple.
One thing that is common among functional programming languages is that is kind of math-y, math-oriented. You try to do stuff in terms of functions. Mathematical functions.
Use immutable data. This is common, but not universal. It means that you have a piece of data and it can never change. If you want to change it, or you want something modified, you have to make a copy of it. This is very common in functional programming.
We'll talk about the business implications after this.
Then, functions. Instead of using classes to abstract, you're going to be using functions. That's very common too. That's where the "functional" comes from. Enough about the technical side of what functional programming is.
Doing business. What's the purpose of functional programming in business? How can it give you an advantage? Should you even be thinking about it? Like, "Just cut it out of your life. We don't talk about functional in this company."
Who runs a company? Yes? I don't know your name. Let's hear you.
**Audience Member**: Bernard [inaudible 5:38] .
**Eric**: Bernard. What company? Is it software?
**Audience Member**: [inaudible 5:42] Strategy.
**Eric**: OK, and you do software?
**Audience Member**: We are. [inaudible 5:46] .
**Eric**: Somebody else? I saw a hand over this side. Yeah.
OK, so we have some businesses. That's great. That's really who this is targeted for — business people who have to try to make a decision.
Let's talk about hiring. This is a really hot topic in functional programming because there's this perception that you would...For instance, let's just use PHP because look how many PHP programmers there are. There must be a ton of great ones in this giant pool of 10 million people that know PHP.
Let's talk about the reality. This is not to scale but if you have this many object-oriented programmers in a group, you're going to have that many functional. A really small number in comparison. This isn't like the whole story. A lot of people talk about this but here's the real story.
There's this procedural, it's this other huge thing towering next to object-oriented. This is citation needed, but I bet that most programmers — even though they know how to use the dot syntax, and make a class, and stuff — they're not really object-oriented programmers. They're still doing procedural but they know how to call methods. They know how to organize stuff into a class.
Most people are in here, but we still hire people who we want them to be object-oriented programmers.
Is it harder to find functional programmers? Yes, it is. It really is hard but as a business that's not your main concern. Your main concern is is it harder to find good functional programmers? You don't want bad programmers. They're going to drag you down.
In green, we have the good programmers. If there's this many good programmers in the procedural, it's going to be hard to find the good ones because you're going to get a bunch of resumes. You're going to say, "Oh, we need some Python programmers." You're going to get a thousand resumes and only this many — I don't know, it's not to scale — but only a 100 of them are going to be good.
Out of a thousand, you're going to get a hundred good ones. I just covered the procedural so we could see.
This is another citation needed. The proportion of good programmers who do functional is high. I put it at about 50 percent. Here, this is about 20 percent. If you're hiring and you say you need Clojure experience, you need Haskell experience, those people are going to be better, on average, than your object-oriented programmer.
Even if they're not in the top 10 percent of functional, they're already in this group. This whole group would fit in here. One of the reasons is, for instance, with object-oriented, every university teaches Java or some object-oriented language. You just got this huge number of people who can claim to have a certificate that says, "I'm an object-oriented programmer."
Very few universities teach functional, so it usually turns out that this is their second or third language. They're already at that level where they're learning a third language. That's something to keep in mind when you're hiring for a programming job. Functional could be a good filter to find those good programmers.
Here's a question, though. Does all software need good programmers? Some stuff is becoming so easy nowadays, like setting up a WordPress blog and then tweaking some theme stuff. You might not need a great programmer for that. You might want to focus on something else like they're a good designer. That they have programming skills but they're not great, but they have great design skills.
This is something to consider. You want good programmers for hard problems. If you're not solving hard problems, you probably don't even care if it's a good programmer. You just want someone who can get the job done, if the job is not hard.
Another thing about hiring is functional programmers are a little bit more expensive on average, if you look at years of experience and stuff. I looked for some good data on this but it's mostly anecdotal.
It has to do with that good programmer thing, that someone who has gone to their third language and is putting themselves out there with extra skills, they're going to be a little bit more expensive.
Here's another thing that you need a citation for, you need fewer. I'm sorry, I forgot your name.
**Audience Member**: Chris.
**Eric**: Chris. Chris mentioned that it's more expressive, functional programming. Very often, you can do more with less. You're not dealing with the same number of bugs. You're able to write code faster, so you often need fewer people.
Code quality. This is another one of those hype things that functional code has fewer bugs, especially a language like Haskell that has a super awesome type system. It can catch so many bugs. You can encode away things so it's impossible. It won't even compile if it has bugs.
Let's talk about the reality. I don't have a citation but I'm sure there's one for this. The number of bugs is correlated with lines of code. The bigger the code base, the more bugs you have. It's pretty linear. It's a straight line. This is called the defect density.
Different companies have measured like, "Oh, well we have a defect density of 10 bugs per 1,000 lines of code." They look at their bug tickets and how big their code-base is at the time the bug was found, and that kind of thing. Microsoft has this, and another company has that...Oh, oh.
I'm going to go out on a limb and I'm going to say functional code is significantly smaller. Not like 10 percent, but we're talking one-tenth, maybe one-fifth. It's a small fraction of the size of an object-oriented or a procedural system.
This is from my personal experience and talking to other functional programmers, people who've done a rewrite. They say, " Wow, we rewrote this and we couldn't believe how small it was in a functional language."
This is factor one, functional code is significantly smaller. The number of bugs is correlated to the lines of code. Functional code is significantly smaller. Therefore, functional programs have fewer bugs, just because they're smaller. I'm going to assert that as like if you just multiply it out, you got this. It's significant because it's one-tenth the size.
We talked about hard problems. What are some of the problems where functional programming can use its strengths? We talked like a WordPress theme, you really don't need functional programming. You need more design shops, that's the important thing there.
What are some things in the business that you would need it for?
We talked about immutable data. Auditing is good for immutable data because you don't change anything, you can just record the old stuff. What are some businesses that use auditing?
**Audience Member**: Banking.
**Audience Member**: Insurance.
**Eric**: What did you say?
**Audience Member**: Auditors.
[laughter]
**Audience Member**: Health care.
**Eric**: Health care. Yeah. Anybody else? Something else? There's some that you know it, you just haven't thought of it. Accounting, banking, medical records, airplanes.
Airplanes record everything that happens on the plane so that if it crashes, they can blame somebody. Science. You want to record all your data as you're gathering it. All these things, they really benefit from functional programming for that aspect, for that immutable data aspect.
We talked about how it's mathematical, functional programming. What are some businesses that use a lot of math?
**Audience Member**: Oil and gas.
**Eric**: Oil and gas.
**Audience Member**: Banking. Statistics.
**Audience Member**: Data science.
**Audience Member**: Finance.
**Eric**: Engineering. Finance.
**Audience Member**: Utilities.
**Audience Member**: Insurance.
**Eric**: Insurance. A lot of these are the same. There's an overlap. Science. Advertising, now. Now it's like you're doing these real-time auctions and figuring out the statistics of which ad to show, Web analytics.
Another factor we talked about how it is distributed. You guys guessed everything I was going to say at the beginning.
[laughter]
**Eric**: I don't even know why I'm talking anymore. I should just stop.
[laughter]
**Eric**: Oh, I didn't make them appear one at a time. Oh well, here you go. Big data analytics, real-time analytics. You could always do it slowly on one machine, but you want to distribute it because it's got to be real-time. Communications.
**Audience Member**: Image processing.
**Eric**: What's that?
**Audience Member**: [inaudible 16:42] processing.
**Eric**: Oh, image processing, that's right. I promise to put it on next time.
Those are some of the business cases that functional programming has been applied to successfully.
This is one of those things that in bigger businesses, there are often these bug bear problems. Something that they've tried to solve multiple times. They've put a team together, they try to do it. Two years later, they're still working on it. It doesn't look like they're making any progress and they just cut the program.
Then, someone else will come in a couple of years later and try to rewrite this system so it's not such a mess.
Those kinds of systems, very often the problem is the methods that they're using are just not suited for it. If you come in with a new method, say functional programming method, you can actually make progress on it.
There's actually a talk about this man. Why I didn't write down his name? I can't remember his name. It's on YouTube. You can find it here at this link. He was working for a large insurance company and they had this XML test case system that it had tons of bugs. It was super costly to maintain but they couldn't get rid of it. They were just resigned to using it for the rest of eternity.
He said, "Look, just put me on it alone and it will be cheap because there's just one employee. I'm going to work on it but I'm going to use F#. I'm going to go through and use the mathematical methods that I know to analyze this to make sure I'm capturing everything properly."
I mean, it's a great talk because he explains all the cool stuff that he did because he was given carte blanche. He was given all this leeway. He could use all these methods that he learned in school or could read about in a paper and didn't have to convince your manager to do.
I feel like there's this opportunity inside of a business, especially a large enterprise where they can just let someone work on something like this to solve these big problems. He was very happy because he was using functional programming, and the business was happy because he had gotten rid of this terrible system that they had.
Another case where it's useful is in places where there are no preexisting solutions. There's a thing called the curse of Lisp. Has anyone heard of this curse of Lisp? OK, I'll explain it briefly. Lisp is a functional programming language, the oldest functional programming language and there's always been this curse.
It's a curse because it's one of those it's like mysterious but then it's brought on by itself, like a self-fulfilling curse. Anyway, you look at languages like Java and there's millions of libraries, open source libraries for doing all sorts of things.
Then you look at Lisp, which is considered by a lot of people to be way more powerful than Java, but where are all the libraries? It would be easier to create this library in Lisp and much better. It would be short and you wouldn't need so many people to work on it.
The curse is...The answer to this question is if the language is so powerful, a single person could solve their problem themselves and not need to collaborate. Because Java makes it so hard, people have to form a team and make a solution and work together on it. Then you get a library.
Whereas with Lisp, people would just write the five lines of code it takes to get their problems solved, just right there, in line. They wouldn't make a library for it. They wouldn't share that code.
The curse is it's for existing solutions, Java probably already has a thing where in 20 lines, 100 lines, you could solve the problem, but for non-existing solutions, you want the curse of Lisp because that's where it shines — something where we don't know how it's going to work. We know that no one's done this before, but we can write it, short and sweet, in a functional language.
Also, complexity. Functional programming is great for dealing with complexity. Who knows the idea of incidental and external complexity? Incidental complexity is you're solving a problem. If the problem is complex already, that's incidental complexity. It comes from the domain itself.
Then, there is the complexity that you're bringing because your technology is complex. You don't want to compound the two. You don't want to add them together. If you've already got a really complex problem, you want something that's simple, meaning it doesn't bring a lot of other problems to the table.
For instance, mutable data is a problem, non-thread safety is a problem, those kinds of things. You don't want to bring those to an already-complex problem.
GUIs. It turns out that a lot of GUI programming is easier in functional programming. This is why React is getting popular right now. It's just much easier to say, "This is what I want it to look like based on this data," and just do a transformation from data to GUI. A lot of GUIs are like that. Some of them are not.
If you wanted to make a graph, it's much easier to just plot the graph each time as the data changes than to go in and mutate objects and stuff so that the graph is now correct. It gets out of sync with the data.
A little summary. This is it. If you got hard problems, you want smart people, and then, so you want smart tools, or sharp tools. The smart people probably want sharp tools. They want something that they can do more with less. If you want to solve hard problems, you want smart people. They're going to demand the sharp tools.
Any questions? I hope I didn't say anything new or surprising. Was anybody surprised by something? Was this totally obvious to anybody? Hunter.
[laughter]
**Eric**: Yeah.
**Audience Member**: Reverse question. When would you not want to use functional programming?
**Eric**: Good question. Anything that is similar to that WordPress problem. There's also this paradox of Wikipedia. It's like a super successful project, really big, tons of users, and it's written in PHP. You're like, "Why would I ever choose anything else besides a PHP? Look what they've done with it."
Let's compare it to Rails, not compare it to functional programming but compare it to Rails. Would Wikipedia be better in Rails?
**Audience Member**: No.
**Eric**: No, probably not. You wouldn't even go from procedural to object-oriented. There's no reason to switch.
Also, when I first saw Rails, I was really excited. This was cool. Web programming is going to be much easier in this than it is in PHP. It was cool because it had all sorts of stuff built in.
Then, two months after I'd found Rails, I was using WordPress. The new version of WordPress came out and it had all those features. It had a flash message. It had interactive menus and stuff. Now, you know how they did it is they just had a bunch of PHP programmers pounding on it, whereas in Rails there were nice abstractions for everything and it worked well.
In WordPress, they just threw more labor at it. Anything that's like, I guess, digging a ditch where you can just hand out more shovels and it will get done faster, that's the kind of thing where functional programming just won't apply.
If you want to give someone one of those cranes, or what are they called? Like a backhoe. If you want to give someone a backhoe, you give them a functional language. You give that one guy can drive it and...
**Eric**: ...hold this.
**Audience Member**: But which [inaudible 27:07] ?
**Eric**: Yeah. Sure.
**Audience Member**: When we start digging ditches with a hundred people at a time, then everything looks like it's conquerable. Everything looks like a ditch that you can dig with a hundred people, when it really would be better to have a backhoe from the beginning.
If you already have invested in a backhoe, if you've already invested in a table saw...If you have a table saw in your house, it's almost never worth it to just use a hand saw when you have a table saw in your house. Right?
**Eric**: For sure.
**Audience Member**: If you're doing this kind of stuff all the time...I am in medical software. The problem is that these giant companies think, "Well, we already have 2,000 software engineers. We are just going to keep throwing 2,000 software engineers at the problems."
There are some problems you simply cannot solve that way. They can't see that because all they see is these ditches that they can dig with...Like, we have 2,000 people. We'll just keep digging ditches with 2,000 people.
**Eric**: For sure, and to expand on that and use the analogy I used before with Rails versus PHP. I mean, Rails changed the Web. The idea of Web 2.0 couldn't have happened without Rails. Even though it happened with Rails, they kind of back-ported it to PHP using just brute force. I'm still waiting for that to happen with functional languages.
It will, where there will be something like, "Wow, this is cool. We couldn't do this before. Now that we have functional languages, it's possible." Then people will try to back-port it. Maybe they won't be able to back-port it or maybe they will with enough force.
Yeah, Joe.
**Audience Member**: Given the current ecosystem of functional languages, the paradigm of way to think [inaudible 29:14] functionally, would you say a bad functional programmer would still somehow be able to work effective and accomplish [inaudible 29:24] ?
In other words, could a bad functional programmer still be of the same [inaudible 29:34] value? Provided, by the way, that the two will work.
**Eric**: Well, if I had charts, I do have charts, I would draw some normal curves.
[laughter]
**Eric**: I would say there is your distribution for object-oriented programmer. To continue what I am saying, the distribution for functional programmer would be like that. You still have a lot of overlap on this bad end. Yeah. It's definitely possible that someone claiming to be a functional programmer could be worse than the majority of object-oriented programmers.
**Audience Member**: I guess I'm thinking more in terms of using a compiler that will make it...If you were doing [inaudible 30:27] . If possibly you are not good at it, the compiler helps you be better at it. By the way, it's not worth to train you up. You don't quite [inaudible 30:36].
**Eric**: Right. Well, one thing I've heard with functional languages, especially with something like Haskell that has a lot of type safety, is that it gives a really great programmer a lot of leverage because they can hire one superstar and then hire a team of 10 middling Haskell programmers who can't mess anything up.
This one person is setting everything up so that the others can get work done without messing anything up. It does have that same like ditch-digging idea to it, that you only need one person out here and then a bunch of people in this area and then you're multiplying this person's effectiveness. I've heard that kind of model working.
**Audience Member**: But don't you think, I mean...
**Eric**: I'm sorry if you can't see.
**Audience Member**: That's OK. Don't you think though that...I mean, it's not just the programming language there because for them to be able to break apart a project for 10 people to work...Haskell's notorious for people who are like pure academics and don't actually ever apply it, or it sucks people in and they like to have their secret codes, their secret sets.
It's almost like the language itself becomes the barrier to having more people to work on it.
**Eric**: I worked in Haskell for a while and I felt that a lot, that there are parts of the code that I could not understand because I would have to read 10 papers. I would have to go dig into fragments all around the Web to understand, "What is this thing doing? And this, this other thing happening there?"
It's like monad transformer. I don't know what a monad transformer is. There's like documents on it and you have to...
Anyway, yes, but the thing was, I was still productive. I didn't have to understand the monad transformer. I didn't have to make my own. I just had to know how to work within the type that was created by that monad transformer.
I do have a lot of sympathy for this model, even though I'm also like I have more of a democratic view towards programming. Anybody should be able to do it and obfuscating it is bad. I'm torn too.
**Audience Member**: To address that and another point [inaudible 33:19] . In my work, I've found even doing the great advanced object-oriented patterns, you get more junior programmers or less experienced people that they can't follow along with it. It's not to say that code is inaccessible. They just don't know what it's doing. You have to teach people.
To someone that hasn't seen either of them, a dependency injector is just as complicated as a [inaudible 33:43] . Neither one of them make sense until you explain their strategy that's going on around it. Kind of like the chart there, I'm not even [inaudible 33:48] the case of great functional programmer is as good as throwing...
A super great object-oriented programmer is the equivalent of the average functional programmer. I think that a great object-oriented programmer becomes a functional programmer. You start to mix your paradigms and get better at using the right tool as you become more experienced in any paradigm of programming.
**Eric**: Interesting. Did you call?
**Audience Member**: I've seen several of your functional program talks. I'm always curious, and building on that as well, is interweaving of object-oriented and functional programming. Especially when it relates to places where you can't very well choose the language due to hardware constraints and drivers, a lot of things that some people deal with on a daily basis.
This idea of from a business standpoint, if you want to be more functional and hire more functional people, but you're in an environment that is inherently not typically functional, how do you go about that? Is it like a paradigm in a company you would set up to practice these things?
**Eric**: That's a good question. When I talked about what functional programming means, notice I didn't say it's a particular set of languages or anything like that.
I think that someone who is good at functional programming, if you bring them into another environment, they're going to bring those tools and techniques that they know of. Often, if they're good enough they will know how to write their own math, or write their own reduce, because it's not a complicated thing.
They're going to start functionalizing wherever they're at, whatever tool they're at. Now, you did mention a different environments. If you're in an embedded environment or something like that, that's a super constrained thing. Is that the thing you were talking about, or are you talking about maybe Web?
**Audience Member**: No, also I'm thinking higher...You are in a specific platform, like embedded or...
**Eric**: Like you have to use IOS, you're using Objective-C.
**Audience Member**: Or you have to use a straight vanilla C, or something, but also on that, if you're looking at those kind of constraints, one of the big things of functional programming is immutable data. It's very important that you use mutable data whenever you're in a C language, because pointers are your friends.
**Eric**: One of the reasons why functional programming is actually becoming more popular now is people have a lot more memory and they've got these cores that are idle.
You can put more garbage on to the garbage collector. Just let it figure it out and do extra work, because you've got more processing than you need, but if you're in these constraints...
**Audience Member**: That's great for the massive Webs we exist on, but not...
**Eric**: It's all about the techniques. Unfortunately, I don't know of a really production-ready, awesome embedded scheme. There might be one. Hunter might know more because he's into that stuff.
For instance, it compiles to C, so it is C, if that's the constraint. It's oriented towards embedded systems, which means it produces a lot less garbage, it is going to use mutable data. It just says you're not going to...A scheme has always been mutable. You're just making that trade-off.
**Audience Member**: Rust.
**Eric**: Then Rust. Rust uses a lot of functional programming stuff and it's supposed to be very efficient.
**Audience Member**: To follow that up, you can always have your mutable kernel. You can always have functional programming doing what functional programming is good at. Then draw the line and be like, "This is the part where I need to run 10 million transactions in the GPU. I have Assembly. Go for it."
You're not going to be able to beat the speed having the efficiency of that, but that's fine. Maybe you have five thousand, ten thousand lines of assembly instead of a million lines for your whole program. Use tool that's made for what it's good at.
When you're solving conceptually hard problems, maybe that's not the computationally hard problem. You have to pick where you're going because [inaudible 38:32] .
**Eric**: But then there's also stories of people writing stuff in Assembly because they...
**Audience Member**: They think it's faster but it's slower.
**Eric**: They think it's faster because in microbenchmark it's like, "Look at how fast I can make this loop. It's like three instructions," but then when they have a million lines of it, it actually turns out that they're re-rendering stuffs a hundred times a frame and they don't know why.
They can't debug it. Whereas, if you wrote it in a high-level language with garbage collection and everything going on, it's really fast.
**Audience Member**: John [inaudible 39:10] , the guy who hosts the F# talk?
**Eric**: You saw that talk?
**Audience Member**: Yeah. He can beat a Fortran benchmark, which is one of the top numerical languages and a managed garbage-collected language, because he was exploiting this higher-level parallelism that the lower-level language just couldn't figure out. He could do a lot more work even though he was being less efficient with his machine.
**Eric**: Right, and it's just him versus every Fortran programmer ever to try this benchmark. [laughs]
**Audience Member**: For numerical computing, Fortran is the standard. I'm going to still use it for projects, so it's one of those change of mindsets.
**Eric**: Yes, it totally is. You're talking about parallelism. I've heard of stuff like a Java team versus a C team, and they were benchmarking to say who's faster, Java or C. The Java team beat the C team. Then they looked into the code and the C team was like, "Hey, not fair. You used threads." Then the Java team was like, "Why didn't you use threads?" "Oh yeah, because it's really hard."
[laughter]
**Eric**: It's not like they couldn't have, but it's like, "We're not going to go there. We've got a limited time," but the Java people were like, "New thread, run," and they were done. There's stuff like that when you switch to functional, where it's like you're using higher-order stuff and you're able to do stuff like optimizations, dynamic programming that you wouldn't want to think about.
React is a great example. When you go from JavaScript to React, to ClojureScript to React, where you're using all immutable data structures, it actually becomes faster. Because even though immutable data structures on their own are slower, if you just compare the operations, because they are in a tree and they share structure, comparing them it's very fast.
You can tell if something's changed because it's just a pointer there. We know that the whole tree hasn't changed, so the only way to change it is to change that one pointer.
If they're the same, you just skip it, you'd say "No change," whereas in JavaScript, because you've got this mutable data, you have to go walk in it and ask, "Oh, are you the same as before?" It becomes faster because you're at a higher level.
**Audience Member**: Another interesting thing like that is the modern [inaudible 41:49] look better and all those kinds of things. Even with immutable data structures and linear types, a smart compiler will look at it and see it's the same piece of memory and it will make it mutable internally, even though it appears immutable in the language.
**Eric**: Right, like this never exits this code, so I can make it mutable.
**Audience Member**: Like [inaudible 42:09] says, we've got to get smarter because it [inaudible 42:10] automatically, where your assembly code will always be exactly what it is. You're never getting any better without [inaudible 42:17] .
**Eric**: Right. It used to be that you could hand-tune your Assembly because you could read the book and figure out, "This thing takes eight microseconds and this thing takes nine, so if I do it first, it will be ready and the bus will be free.
You would think about all these things, but now it's like branch prediction and all that stuff. You can't even predict what the processor is going to do, so all that hand-tuning stuff doesn't work anymore.
Anything else? Because I'm almost out of time. Last question?
Awesome. Thank you very much.
[applause]
**Eric**: You're just in time.
[crosstalk]
**Audience Member**: One of the conversations we've had at work about hiring people for functional programming is that it goes back to the [inaudible 43:14] line. There aren't many functional programmers.
If you put an ad out for you want Java people, you'll get a million that are applying. [inaudible 43:22] , if put an ad out for we want a Clojure programmers, they're like "Come and find me," because they want that [inaudible 43:28]. Is that your experience as well?
**Eric**: Yeah.
**Audience Member**: Yeah.
[laughter]
**Eric**: Yeah, it is. Often, they'll say, "I'm willing to take a pay cut," but you don't know what their salary is already.
[crosstalk]
[laughter]
**Audience Member**: [inaudible 43:44] . If you are talking about entry level or junior mid-level programmers, that works really well. If you need to hire an architect, like a Clojure architect type of person, then, no, I don't find that that's true.
The one thing that I will throw cold water on here is if you're trying to hire people that are senior programmers with functional experience that know Erlang, know Clojure, know F#, whatever, and there are not many of those in state and you're trying to bring them in the state, it's hard to get them to come to Louisiana.
There's a lot of them that have families, that have kids. There are a lot of areas that getting those people [inaudible 44:40] . I know my company has had issues with that.
**Audience Member**: Did you mention [inaudible 44:49] ?
**Eric**: I think it was mentioned in the intro.
We have a meet-up every Tuesday. The first Tuesday of the month, at [inaudible 45:03] that launchpad is Functional Programming. We do talks. It's pretty successful. There's a nice core of people who come in. We're always looking for talks, so if you would like to talk about anything functional related, it doesn't even have to really be functional itself, let me know.