Why do programmers put up with so much pain?

If you're using a less popular language, it may seem like there is a ton of pain there. But there's pain everywhere. Every stack has its own problems. The key is you need to pick the pain you want to live with.

Transcript

Eric Normand: Why do programmers put up with so much pain? By the end of this episode, I hope to explore this idea a little bit more. This won't be one where I have some definitive answer, some definition. This is more just me pontificating. My name is Eric Normand and I help people thrive with functional programming.

I'm bringing this up because a kind listener who's new to programming, certainly new to functional programming, he was watching a talk about the pain of using Haskell for a business. Now, every language has some pain, but this one was particular to the Haskell language because he was interested in Haskell.

He was asking me why someone would go with Haskell as opposed to going up with one of the more established languages when they're building a business. Then he mentioned a few languages, like why not go with Java and Spring? Why not use ASP.NET?

I thought this was an interesting idea to explore. Let's go over some facts.

Fact number one is programmers put up with a lot of pain. They really do. There's quite a lot of pain in every stack. In every language, there is pain. There's no getting around that.

Even if it is I have to read a book this thick and be certified in Spring to be able to do it, or I have to be like a pioneer [laughs] and figure out how to get this stuff working, which is available in Spring, but I need to get it to work in Haskell.

All of that is pain and programmers deal with that. It's everywhere. That's fact number two. Programmers deal with it and it's everywhere. The resolution to this question, I'm not going to say it's an answer, but the resolution is it's about picking your pain.

Just as a personal example, I have used a little bit of Spring. In my experience, a lot of it was figuring out which XML file to edit, editing it; that was what you did most of the time for solving problems. That was painful to me.

It was painful that I just wanted to do something very simple like something that I thought I should be able to do with just an if statement. I just want to either do this in this case or do that every other case, just a very simple thing. Of course that required setting up a new plugin and that required adding a line to an XML file and then configuring that with more XML.

It's not that it's XML, it's that there's so many XML files. You just had to know all these things about where things go. When to me this was a simple change and, because I'm not that experienced in Spring, it seemed like it should just be an if statement.

That is one of the reasons why I like Clojure because it's all code and I can just put an if statement where I think it needs to go.

However, I do deal with other pain. A lot of people ask me how, in Clojure, I deal with the pain of using immutable data structures everywhere. Now to me, I'm used to it. I've chosen that pain, but it is a pain, compared...For some algorithms, it is much easier to just do a mutable, just throw things in a map, hash map, a mutable hash map.

Why have I chosen that pain instead of some other pains? As a functional programmer, I like that it's immutable because at any point, I know that my functional code is thread-safe and that I can hold on to references to things and they're not going to change, and because that is a pain having things changed underneath you.

What I'm trying to get at here is it's all pain. It's all pain. You have to use your own judgment, and your own taste, and just really knowing yourself to decide which pains are worth it.

In the case of the Haskell programmer giving this talk that prompted this question from a listener, I think that Haskell programmers really like the purity of the language, they like the strong — meaning powerful — type system. They are willing to put up with a lot of the pioneering aspects of the programming, that there's much less tooling.

The libraries are not as prolific and full-featured as you would find in, say, the Java ecosystem, and there's just not as much help around. It's just the truth. I'm talking about in absolute terms or in relative terms. Relative to Java, there's just less help. There are fewer books, for instance.

That attracts people. They feel like they're going to get...They're going to outweigh the costs from the benefits of the type system. The type system will pay for all the other costs.

I worked at a company that was doing Haskell on the back end. Their philosophy, the CTO's philosophy who chose Haskell, this was the pain trade off he was making. He remembers working in Ruby and Rails and not knowing what types he could expect anywhere.

He would, as an example, print out an array at a random point in the program and expect to find user records in it. He found lots of different things. He found user records. He found user IDs. He found nils. He found random stuff in it.

He felt like there was...because this array was mutable and it had been passed around to all these different parts of the program, there was very little way to know how all those different things got into that array. That was a pain that he experienced, that this was causing bugs and there was very little way to diagnose the problem.

And so, something like Haskell, which has immutable lists, so you can't...Even if you pass it around to different parts of the code, they're not going to be able to mess with it and it has strong type lists. You can't just add anything to it.

He felt with those two things, that would solve the problem and that that problem was worse than the, "How do I get this installed on my machine? How do I run it as a server? How do I deal with finding libraries for certain things we need?" All of those things were sort of, "I could solve this one time, and it will be done" problems.

Whereas this, "What am I going to find in my random data structure?" problem was an ongoing problem that was not solvable, once and for all, in the Ruby language. That was the trade-off he made. He traded off the pain of...Ruby was a sizable community at that point, had lots of libraries. It's very convenient to create a Web app in it. He traded that for knowing what was going to be in his arrays.

I'll just recap. There's not much to talk about in this one. I just wanted to bring up this. That's an opinion that I have that it's all a trade offs.

Fact, programmers put up with a lot of pain. If you go to a conference on in any language, it's all about the pain. Some are more enterprise-y so it's like, "Who do I pay a million dollars to to solve this pain?" [laughs] Some of them are more like, "Well, we wanted to do this thing, but it's really hard in this language and here's how we solved it." That's just the way it is.

We put up with a lot. It's everywhere.

My opinion is it's just about picking your pain. You look at your problem, like, what are we trying to solve here? What are the hard things? You pick a language that aligns with that decently well. You look at, if you can, what are the things that we're going to face, that are hard, if we choose this language? And you decide whether they're worth it. That's it. That's all you can do.

All right. If you liked this opinion piece, you should subscribe because I do more like it and there's more where I just talk about more factual stuff, go deep into functional programming concepts, share some tips and tricks on how to do functional programming better. I'd love to hear your pains, like what are the pains that you...?

Here's the question. What do you want to never do without?

We've all got something that we've fought hard for and now I've got it, I don't want to do without it. For me, in Clojure, it's interactive programming. I cannot go back to any other system that doesn't have interactive programming. I really like interactive programming.

I also like immutable data structures and stuff, but my number one thing is interactive programming. I think Clojure does it the best. If you're into Haskell, you might say it's types. I want category theory level types. It could be something like that.

Let me know. You can email me at eric@lispcast.com. If you do email me, I might talk about it on the podcast. Let me know if you don't want me to. You can get in touch with me on Twitter. I'm @ericnormand with a D or you can find me on LinkedIn and search for me there.

Awesome. Take care. See you in the next episode.