Why do programmers put up with so much pain?

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 [email protected] 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.