A ruby programmer is called a rubyist, an elixir programmer is called an alchemist, a Go programmer is called a gopher, what is an Elm programmer called?

A ruby programmer is called a rubyist, an elixir programmer is called an alchemist, a Go programmer is called a gopher, what is an Elm programmer called?

A programmer.

I believe this discussion has taken place before and that the conclusion was that Elm is a tool, and we don’t label ourselves by our tools. Just as a carpenter aren’t Hammerists or Sawfolks, we’re programmers.


An Elm programmer is called wise. :slight_smile:


I hope that I can say this without offending anyone:

It’s mantras like “Elm programmers do not call themselves anything” and “Code is the easy part” being repeated 100s of times over and over that make me feel really strange about the community. It starts to feel somewhat cultish after reading the same messages over and over.

Good communities are vibrant and diverse and allow multiple schools of thought to coexist in harmony. It’s very possible that some people call themselves “Elmists”, or “Elmos”, or “Elmers” or anything that they’d like! Why not allow people to proudly wear the banner of something they enjoy to try and rally around it?

I don’t mean to call anyone out but I really would like to see more original opinions rather than just parroting something Evan said over and over, ad nauseam.

I personally kind of like “Elmer” because of the Looney Tunes imagery, and think it shows that I don’t take myself too seriously. :wink:


You can do what you want of course. The root argument is that having a “us vs them” mindset has been a big barrier for functional languages in the past. There are languages similar to Elm that have existed for 30 or 40 or 50 years, but for some reason, many have a reputation as being academic or esoteric. Some people who like those languages have become quite resentful about that perception, and I saw a lot of folks acting in an “us vs them” way that it tended to alienate folks. So I encouraged folks to not see functional programming as a cool club for the cool kids. It’s just a thing you can do or you can not do. Like if you use this hammer or that hammer. I think cultural norms like that have actually been extremely important for Elm, and individual behavior has implications for the group. (E.g. it is a quite a small minority of folks that identify as “typed functional programmers” that end up in aggressive and negative interactions, but it does not need to be a large group to create a more general perception.)

The argument itself is independent of me. The root idea is that setting up “us vs them” has a way of “strengthening a community” but in a way that is actually not that welcoming. For example, should a Pythonista get along with a Rubyist? Look around Hacker News and see what the data suggests. So if you want people to say something else, make a better argument that is well-supported by historical data. You say “Good communities are …” but based on what? What is another programming language community that is like that? JavaScript? What are the full implications of having 100 perspectives on everything? Does it have an impact on the package ecosystem? Does that make it harder or easier to get work done? Okay, maybe there is another example… What are the implications of that? How does it fit with other parts of their community?

I’m hopeful that your perspective is explained by the perception of typed functional languages changing so much that you don’t think the root argument based on “us vs them in the historical context of typed functional programming being esoteric” is no longer relevant. That’d be a good improvement. But I don’t think it follows that “therefore encouraging ‘us vs them’ thinking has no other serious downsides.” Again, look at every single Hacker News thread ever. Or look at it in a different context, like in the great blender vs food processor debate.


Yeah, you’re right.

Even if the whole community opposes, I’ll call myself an Elmer. :slight_smile:


So I encouraged folks to not see functional programming as a cool club for the cool kids.

Fair enough! I’m definitely not advocating for trying to create an “us and them” mentality. I only meant to point out the “We elm programmers do not call ourselves anything, unlike those silly Rubyists, etc” really had the opposite effect from my perspective. It sounded like “we are above the realm of those who would name themselves by the tools they use” and not “we try not to label to remain inclusive to everyone!”

You say “Good communities are …” but based on what? What is another programming language community that is like that?

Again, that’s a fair argument. I mean other communities that I’ve been a part of. One example I’m familiar with is barbecue. I am on plenty of forums where people will identify based on the variety or brand of smoker that they have. It doesn’t cause cliques or in-fighting (maybe a few friendly debates over which gets the best smoke flavor, or sear, etc) but rather is helpful to know the type of experience this person will have when cooking.

It’s fair to say that programming communities have not always been like this, and they often will devolve to in-fighting, or treating someone as lesser. (I’ve heard the terms “boring java developer” or “filthy javascript heathen” even thrown around both in jest and seriously.)

I’m hopeful that your perspective is explained by the perception of typed functional languages changing so much that you don’t think the root argument based on “us vs them in the historical context of typed functional programming being esoteric” is no longer relevant.

I would say definitely! It wasn’t my perception that someone calling themselves an “Elmer” makes it exclusive.

I definitely can appreciate the goal of trying to have a more open community! I just wish as a whole that people would lighten up a bit with the dogma. The Elm community is already rather small (compared with many others) and it’s tedious to see the same phrases being repeated over and over.

1 Like

I’m sorry that I gave you that impression. That was not my intention at all!

What I mean to say was that we, as a community, haven’t really come up with a name. There has been a discussion before, and one of the views expressed at the time is that we are simply programmers who like working in Elm. Carpenter’s don’t identify by their tools, so why should we? As far as I know, no one has really challenged that statement.

Anyone can, of course, call themselves what they want. But there’s really no answer to the question: “what do you call a programmer who uses Elm?”

1 Like

No, you’re fine! Like I said, I really didn’t want to call you out directly. This has gotta be the like 7th or 8th time I’ve read this, so it was just the most recent example that I commented on.

I personally have been more successful in helping people once I identify what they currently work in, or what they’ve programmed in before. It helps me draw useful parallels to ease the learning curve. It’s true though that “I program in Elm” can be somewhat semantically different from “I’m an Elmer” or “I’m an Elm programmer”.

I personally enjoy programming in Elm enough that identifying as such helps me paint the picture that I want to: “I’m an Elmer. I only want to program in Elm.” <3


@Andre, your perspective is really interesting. I would be curious to see examples if you have them. It is troubling to think that an effort to avoid “us vs them” may become a new and exciting way to create an “us vs them” dynamic. Perhaps knowledge of the conclusion spread beyond knowledge of the supporting logic, so I would encourage folks who are answering questions like this to give the background as much as possible!

(I can understand why people may not be though. I think a lot of folks feel tired right now. New releases bring in an influx of new folks, and when you see a situation for the Nth time, it is easy to forget that there is also a person you are meeting for first time. And if some of those situations have been negative, you may have anxiety or impatience going into the interaction. I suspect this will improve as we get farther from the last release, but maybe it’ll be helpful to explicitly point out that this pattern exists.)

The barbecue example is interesting. I have thought about how it is in woodworking, knives, and cooking. I think there is some important difference in practice (based on what I hear about their forums) but I’m not certain what it is really. Maybe it is the relative amount time people spend there? Or the age of the participants? Or the fact that the tools are more settled in those other areas? Or that there are money and space costs to certain items? I’m not sure at all. I think it’d be very interesting to find out because it may give some useful insight for programmers.

Anyway, your perspective is very interesting, and I will be on the lookout to find more examples of this!


True! I suspect you are right about the release bringing in an influx of similar questions.

I have more thoughts about why hobby communities tend to be friendlier than programming which is a mix of hobby and livelihood, but it’s probably getting far too off-topic for this thread. :slight_smile:

I appreciate the thoughtful discussion!


To provide another perspective, I’ve programmed in many languages and they all had their pros and cons. I’ve used and enjoyed to varying degrees python, ruby, clojure, java, and javascript, but I never felt like a pythonista or a rubyist or a clojurian or a javangelist(?) or a javascriptorian (I’m just making these up now). I never understood that point of view, and often felt awkward honestly discussing trade-offs in languages with folks who so heavily identified with them. When I eventually discovered Elm, it was really nice to hear Evan and people in the community say, “Oh, we’re just developers and Elm is a tool we really like.” Here was a community who’s ideas about identifying strongly with a language fit much better with my own, and that helped me feel more at home and welcome. I think Elm may have the nicest and most coherent design of any language I’ve used. I sing it’s praises to anyone who will listen, but I don’t recommend it unconditionally for every use case, and I wouldn’t like to be referred to as an “Elmer.”

All this is to say that for me at least, not having a clever name as an Elm programmer isn’t about a “cultish” parroting of things I’ve heard elsewhere in the community, but now participating in a community where the common perspective is more aligned with how I’ve always thought about all programming languages.


There is a crisis of belonging in the world right now and people grasp on anything. A lot of people long for a genuine feeling of community and if a tool, like Elm, can provide that, they will gladly take on an identity based on that tool.


I’ve been part of Elm community one way or another for 3 years now. I’ve seen multiple releases, discussions, gates.

I very much share feelings of Andre here. And if you need more examples - here I am. Feel free to ask more questions if needed here or privately.

I am rarely participating in discussions across various forums, because I learned it feels better to avoid them. I am still using the language and contributing to some of it’s ecosystem though, because I like it. It looks like Elm community wants to be open and inclusive, but it feels like it is “heavily regulated” instead.

Hope it will provide a bit more insight into the topic.


This quote reminds me of something I saw written by Andre Staltz:


In context of Andre Staltz quote mentioned above:

I asked Phoenix core team to add a deprecation warning in docs while accessed through iex, and they did that one month later in the next release (please read the post). I wasn’t and still am not a prominent Elixir programmer. I never contributed to Elixir’s core, didn’t work on any library, didn’t write a book (though I planned to write a book for beginners, but only wrote it’s intro and never went back to work on that again), didn’t create any course, din’t talk at any conference and don’t consider myself an experienced Elixir programmer at all. I am just a mediocre Elixir coder, but still the core team listened to my suggestion. They didn’t tell me a “deprecated” flag with documentation inside iex was “extra work” or “not necessary”, and didn’t tell me “who you are to suggest that”.


So, did anyone here tell you that?

No, I didn’t yet experience that kind of behavior, but Andre Staltz’s comment on Elm community (mentioned in @pdamoc’s reply) clearly describes that Elm community hardly listens to anyone outside of the core team.


That’s not true in my experience. I’m not a part of the “core team”, yet I’ve done a lot of Elm contributions. I’ve been listened to.

That doesn’t necessarily mean all my suggestions have been accepted/followed. In fact, most of it hasn’t. But that only means that Elm has a high barrier to entry, which is one of the reasons why Elm is as high quality as it is. In fact, I found this quote by Evan the other day which seems fitting to write down here:

Point is, thinking that “contribution” means “merged into core” is a poisonous mindset. Languages cannot work that way. Like I say here, many of my projects don’t make the cut. Learning is progress. Prototypes are progress. Performance numbers are progress. Discussion is progress. Doing work doesn’t mean core should change.

My experience that most people are listened too. That is most definitely contribution, but it doesn’t mean that it leads to changes now, or ever. Nor should it.

The thing to be aware of is that Elm has a much slower development cycle than most other projects. Things happens slowly. I proposed two years ago to remove the Color module from elm/core, it only happened last month. While that might seem like a bad thing, I’m pretty certain that the slow development cycle is key to Elm’s success.


On the subject of locked threads. I also noticed there was a period when this happened frequently - but Evan did also post to explain what he was frustrated by:

I have not seen any locked threads since that time, and I also notice that more recently Evan seems to be able to join in here more often. It strikes me that the best way forward is to respect his wishes and not constantly challenge the design choices in the compiler and core. Much better if the core contributors can feel comfortable joining in on here.

1 Like