Is Clojure a language for hipsters?

In this episode, I contemplate whether I am an early adopter or a pragmatist, and how that influenced my choice of Clojure. Does Clojure appeal to early adopters? Has it crossed the chasm?

Transcript

Are closure programmers language hipsters? My name is Eric Normand and I help people thrive with functional programming. So, I was listening to a talk, a very good talk by Gabriel Gomez about, it was a Haskell Talk, Haskell Conference Talk, and he did a really great job of explaining this, crossing the chasm idea. I've read the book, I think twice, it's a really good book, but it's so full of details and practical advice, I'd never gone through and taken them out and tried to apply them directly the way he did. He took each of the ideas and gave great examples in the Haskell world of sort of the challenge of getting what's called crossing the chasm, getting from these early adopters who are all about new technology to making a technology mainstream. And there's this idea that there's these pragmatists who are waiting to try a technology until everyone else has tried it. So, there's a kind of catch-22 problem, and one of the ways that's been sort of engineered to solve this, and this is more like the kind of tech startup space, right, when you build a new technology. And the way that they've engineered to solve this problem is to be the best at some job, the best thing for that job, so that the pragmatists have to use it, and then they're happy to use it because it really is better than anything else. And solves the problem well, and then they tell all the other pragmatists, and then every day, suddenly everybody's using it, example is Python and machine learning. A lot of people would say that maybe Python is not the best language for this, but as a complete package in terms of getting started and solving real problems with it, the documentation, the libraries available, the integrations with C++ libraries that are out there, the tutorials, all that stuff put together in a package, Python is actually probably the best solution, and that's why they are all using it. Okay, but it made me think, because he's talking about the attitudes between the differences between the early adopters who are keen on trying something, and often trying something because it's not mainstream, and the pragmatists who distrust the early adopters because they're always after the new and shiny, and they have a job to do, and they just want to get the job done. So I was thinking about this, and also about how many times I had been accused of being a language hipster because I was into closure, and sometimes I would, you know, take it personally, and sometimes I would get offended, and sometimes I would try to defend myself, sometimes it didn't bother me so much, and I just kind of thought it was weird and a joke, because I never, I'm not a, I'm not like a gadget person, I don't like new technologies, I'm not constantly trying out new libraries, and new stuff, and in fact, like somewhat too a fault, you know, I write a newsletter, and I don't talk about news, and people are like, hey, have you tried spec, and I'm like, oh, no, it's too new, it came out four years ago, and so it's things like that where I think I'm objectively see that I'm not a hipster. I didn't choose closure because it was new and shiny, but I can also see that if people interpret that I must be a language hipster, because to them closure is this new and shiny thing that still hasn't crossed the chasm, that I must be a new and shiny kind of person. So I just wanted to explore that a little, that I think that, you know, just like, like an objective fact, I've been programming in LISP since 2000, so I was working, I was at the university working on projects, and I came across common LISP at, in an AI class that we had, and the professor was old enough, and AI was still kind of like this obscure topic, where like the textbooks were all in LISP, and that's what he knew, and so that's what he taught, and I didn't get it at first, but I started understanding the appeal of it, started getting used to modeling stuff in terms of lists, and I eventually really liked it and preferred it to Java, which was the main language that they taught at the university, and so I started doing all my projects in it, that I could, you know, some projects you had to do in Java, that was just the assignment, but a lot of projects were more open ended, and I would ask the professor, hey, could I do this in LISP, and he'd say, he or she would say sure, why not, and so I would run circles around the Java programmers, because LISP gets out of your way, lets you explore, you got a REPL, you don't have this long compile time, and for stuff like parsing data files and stuff, it is way better than Java, and so I just kept using it, and I even tried to build a little app and company around it back in, let's say 2007, I had no idea what I was doing, so it was terrible, but I did it all in common LISP, and then when closure came out, I was very skeptical, it seemed like, wait, we have this thing that's really awesome, common LISP is a, I've heard it described as a very pragmatic and professional system, so it's not made for teaching, it's made for real software, and it's got so many things built in that you need, so I was very skeptical of closure, but someone suggested I look at it, and I heard Rid Tiki talk, and so I did take a look, and I liked what I saw, it was LISP, but modernized, there are a lot of problems with common LISP that we all knew about, but it was kind of a standard and hadn't changed since the standard came out, there wasn't enough industry momentum to come up with a new standard, and it worked on the JVM, which I also knew from university working in Java, and so it meant that a lot of stuff that was sort of siloed off, a lot of the, let's say soap, you know, web services, modern libraries that were being developed at that time, like those things were now accessible, could run anywhere, because it was on the JVM, and I liked the more functional feel of it, as immutable data structures, it uses a lot more, you know, map filter and reduced than you would in LISP. And so, to me, it was always a pragmatic choice, you know, closure wasn't like, oh, this is this new hot thing that can do all this cool stuff, it was much more like, I still want to program in LISP, which I've already been doing for years, and then this gives me access to the JVM ecosystem, and also some modernization, which is also, like, very pragmatic, because common LISP was standardized before, I mean, you know, things you don't think about anymore, but like, there were hundreds of different kinds of file systems, and each one had different dividing characters for the path, and so they had a whole system for how to work with that, that just felt very antiquated. There was, it was, in a lot of ways, a step backwards, common LISP had a lot of cool features that closure does not have, okay, but in general, I felt like this was a very pragmatic step for me. And then closure is such a conservative language in terms of adding new features, rarely, very rarely has any breakages, and those are prioritized when there is a breakage, those are prioritized and a new release comes out right away. And so I would, like, looking back on it and having this explained, I actually wonder how much of closure's perception is that it is a new language, like it's a new way to program, when it's actually a much older way to program, and that it, you know, if you squint a little, it could be the conservative choice, it could be the more, like, backwards-looking choice, not that it's, you know, a backwards language or anything like that, but if you're looking for, like, what is more rooted in history, what is more rooted in good ideas that has, you know, it's closure, Java is sort of the new kid on the block, in that sense. And so I don't know, that just made me think a lot that one of the things that maybe we're missing is in terms of if closure wanted to say "cross the chasm" as this book calls it, that there's kind of a perception issue, that it's not for the cool kids who just want to be different, it's for the old cranky people who are tired of dealing with poorly designed languages with fast-moving ecosystems that don't actually ever solve the problems that they talk about solving. So I don't know, my name is Eric Normand, this has been my thought on functional programming, and as always, rock on.