How we talk about other languages

Request Feedback
1

As a community, we have a habit of throwing other languages under the bus. This is especially true of JavaScript. I’ve seen so many similes recently: garbage fires, fetid trash, something you need therapy for.

To put it directly, this needs to stop. A massive amount of work goes into every programming language, no matter the outcome. It makes me sad that we’re so willing to throw the efforts of so many people in the bin, especially when Elm is able to use all that hard work to such nice effect!

Think also of the impression it leaves on people new to our community. For new folks, that can be a huge turn-off. It makes us appear to be toxic, hateful people. I know this is not true; there are so many lovely, kind people in this community. And this hurts even more since learners tend to think their failure to understand something means they’re bad, instead of realizing that the subject matter is genuinely tricky.

Pure-functional strongly-typed languages have a bad reputation of being elitist. That can stop with us. I’ve had such a wonderful experience with you all, and I want other people to have that as well. :heart:

Edit, April 10: based on some conversations I have had since writing this, it seems like I wasn’t clear enough that this post is more my opinion as a community member than in my capacity as a moderator. This is not an official rule or anything, but rather something that I’d like us to keep in mind as we grow and continue to welcome new folks.

81 Likes
2

I fully agree.
There is a fine line between arguing for the benefits of elm and highlighting the downsides of js, when they are competing in terms of area they are most used in.

I personally am often frustrated by problems I encounter in a legacy js codebase that simply would not exist in an elm codebase the same size.

That said, I think the best way to fight a toxic perception is to talk about the benefits of elm and not so much about downsides of js.
This and honestly telling in the forums when elm might not be the best solution for the requirements.

8 Likes
3

I’m totally on board! :heart:

8 Likes
5

There is a difference between honesty and non-actionable negativity. Examples:

  • honesty: I do not feel confident in the runtime safety of my JavaScript code.
  • non-actionable negativity: JavaScript is a garbage fire.

Do you see the difference here? One of these is a clear statement of preference, and can be compared against. The other doesn’t contribute to the conversation, and can bring other people down.

My point here: let’s make sure the words we use build each other up. This takes deliberation.

Edit: I see you composing a response, @opvasger, so I want to clear the air before you do: I’m afraid that this has come across as a call out to you, and that’s not my intention at all. I’m not particularly interested in rehashing anyone’s decisions. But it’d be nice if all our behavior could change going forward. :slight_smile:

11 Likes
6

I very strongly second this!

Every language you know about has done something nice for people. Made them productive. Empowered them. Made them happy. Made less risk for their department. Etc.

So I personally learn from looking at Python, PHP, Haskell, Java, OCaml, C, Scala, Ruby, JavaScript, and all the others. I may not make the same choices, but when I ask “why do people love this?” I get much more useful insights. There is always a good reason, and I highly recommend this approach!

26 Likes
7

It’s often the case in life that something’s greatest strengths are also it’s greatest weakness.

The strengths and weaknesses of both Elm and JavaScript eminate from this. These two languages are a good example as their design choices seem to put them at either end of several spectrums.

None of which to say some language design choices aren’t just mistakes. Not to mention that far more matters than just a languages design: it’s community, how it evolves, how it gets adopted.

Other than languages that were purposely designed that way (Brainf#%*, really more of an art project than a language), I’ve never seen a language that didn’t have some problem it solved better than others, at least in some context.

By the way, I’ve learned so much about Elm with rust, lisp, JavaScript, Go, and look forward to doing so with more. I’ll bet even a really difficult, obsolete language would yield insight.

5 Likes
8

Next month I’ll be talking about other languages in a lunch-and-learn for the web devs at my office. The goal is to encourage exploration. I call it the “Language Buffet.”

Some languages have proven challenging to present positively. It’s tempting to criticize, but that would defeat my purpose. Instead I’ll be saying things like, “If you like writing Lisp, but actually want to use Java… that compiles to JavaScript, then ClojureScript is the thing for you!”

Well that’s tongue-in-cheek. Guess I’ll have to sell metaprogramming.

9

One thought: JavaScript is one of, if not the, most popular language in the world. And not just in the browser. Clearly they did something right.

The languages most likely to be dissed probably have a strong correlation with those that are popular. But they didn’t get popular totally by accident. Something about them worked well.

9 Likes
10

I’m not sure we can so easily distinguish the two. It’s not dishonest to say that javascript is an objectively bad language. I do agree that there’s no need to be incendiary when pointing it out, however.

I also don’t think that calling javascript a bad language should be perceived as a slight, because there’s more to a language than its design and features. What makes javascript objectively great is its history and impact on society and the path it’s taken to get to where we are now. To understand what javascript is, you have to understand its history:

  • 1995: Created as the result of a 10 day prototype with odd corporate mandates, such as “make it look like java” and fateful requirements to mimic poorly designed Java APIs.

  • 1996: Quickly adopted as the standard for client-side browser scripting.

  • 1999: AJAX! Microsoft releases a non-standard javascript feature that would fundamentally change what browsers are capable of. Its usefulness can’t be denied and other browser vendors quickly adopt it.

  • 2000-2008: Politics and disagreement stagnate the language. ES4, a perhaps overly-ambitious attempt to modernize javascript is abandoned. Javascript’s dynamic and interpreted nature are a detriment to performance, and a technical ceiling is hit.

  • 2008: The release of Chrome and the V8 virtual machine, along with Mozilla’s TraceMonkey JIT, breathes new life into Javascript and client-side web development, improving the performance of javascript code by several factors.

  • 2009: NodeJS is released, an isolated version of the V8 virtual machine with a standard library for running javascript outside of the browser. An entire ecosystem is born.

  • 2010-Present: An explosion in javascript development. Communities create and evolve solutions to javascript’s many shortcomings. Javascript performance is such that other languages are now able to start transpiling to javascript. Nearly all javascript written over the past 23 years still works in all modern browsers.

So yeah, the point I’m trying to make is I curse javascript constantly. It has quirks that make me furious at times. I may even say incendiary things about it, even though I know I shouldn’t. But, considering the circumstances, javascript is an absolute marvel, and a testament to engineering and collaboration that absolutely needs to be lauded and appreciated.

9 Likes
11

I personally disagree. “Bad” is a value judgement, and to be honest or useful at all, it needs to be accompanied by what it is “bad” for. Otherwise it is just a negative comment that isn’t beneficial to anyone.

We can list facts, like inconsistency in DOM APIs, or that coercion in equality is a source of confusion and bugs. We can tell anecdotes, like that dynamic typing in my experience makes it harder to maintain large projects.

And if we do make value judgements, the responsible thing to do, in my opinion, is to be specific and list reasons.

It is also worth nothing if I say JavaScript is good. Good for what? Or generic comparisons, like Elm is better than JS, or viceversa. Better at what?

Let’s just be polite, and if we really have to judge, be specific and reason our comments.

12 Likes
12

“Bad” is a value judgement, and to be honest or useful at all, it needs to be accompanied by what it is “bad” for.

I could list all the objectively bad things about it, and you’ve listed a handful yourself. It’s pretty well accepted that if we could design a new language from scratch for the browser, there are obvious things that would be done differently. More importantly, and the point I was trying to make, is it’s why it’s this way that really matters.

It’s also important to distinguish javascript “the language” from javascript as a language choice. Often times, javascript is the best tool for the job. Again, I could list all the reasons why, in order to be able to “responsibly” assert such a thing, but then discussion devolves into pedantry.

I should point out that I agree with the spirit of what’s being said here: Don’t be incendiary or insulting. Ideally, this is all that would need to be said. I worry about the trend of policing language to the point of stifling meaningful discussion.

13

It’s so nice to see threads like that one :slight_smile:.

I’m grateful to be in such an open minded community.

I don’t want either to be in an elitist community. It’s not useful to anybody. We need to be open to newcomers.

We did it with te ruby community in Paris, now we have so many new ruby developers, it’s kind of crazy how it pays off to be inclusive with other languages and communities.

7 Likes
14

Javascript is easy to learn. There’s a repl in every browser. It’s FP in its own way. I actually wish Elm looked superficially more like it - wish Elm came across as a highly constrained type safe version of JS, then I believe Javascript developers would be more likely to be jumping to Elm.

15

Hey folks, the following is a work in progress. I hope we can make sense of it together.

When we write code, we run the risk of of putting people’s time/effort/privacy/money/safety/lives in danger.
Is it any surprise we’re passionate and emotional about bad code or problematic programming languages?

Emotional intelligence research tells us that emotional responses are valid and helpful if we take the time to understand them. If someone believes there are serious problems with a language, and that these problems could lead to problematic code that could cost people their time/effort/privacy/money/safety/lives, then it is a valid emotional response to be upset, and to use derisive terms when speaking of that language. (It might not be logical, however.)

It is also, a valid emotional response, upon hearing this derisive terms, to be turned away from the people/community using them. (Again, this isn’t necessarily a logical response.)

When deciding how to remedy people being offended, we might just as easily have said:
The problem lies with the new folks. They should fix their behaviour. Let’s fix them by saying “Hey new folks, some of us Elm users get fired up about this stuff and might use offensive language. But you mustn’t judge a book by its cover. Get to know us, we want to help!”

That didn’t happen. Instead it seems the leaders of this community have decided which emotional responses are OK and respected and which ones are not. They decided one group of people can continue with their emotional response, and the other group “needs to stop”. Is that OK?

I agree that we want outsiders to know we are welcoming. We certainly don’t ever want personal attacks (based on technology preference or otherwise). But let’s also respect that people might have had horrible, disastrous, stressful experiences with other languages, and they might be upset about it. They might be frustrated and concerned that others will have bad experiences.

Good things can come from those valid negative emotions. A portion of the Elm ecosystem might OWE itself to those negative emotions. Let’s respect those emotions, try to understand where they’re coming from, and figure out how best to put them to use.

1 Like
16

Here is exactly what OP said:

Of course it’s valid to have negative emotions about a bad experience!

What needs to stop is channeling those emotions into unconstructive public name-calling.

Put another way: if you were frustrated by JavaScript, express that by saying something like “I was frustrated by JavaScript,” not “JavaScript can die in a fire.”

That’s it. That’s the whole message.

12 Likes
17

yes, and to add: it’s impossible to dictate people’s feelings on a subject, and foolish. I don’t want to tell anyone how to feel (but I’ll try and help you feel better if I can.)

The point is behavior, not feelings.

6 Likes
19

Totally agree with this. In my experience taking with disdain about other languages is a terrible strategy for growing a community.

Years ago we had the creator of a functional language talk in our local JS meetup, unfortunatelly he went to strongly attack JS, even mocking it. Instead of learning the good things of his language during the talk I just went into defensive mode and didn’t pay much attention. Talking with others later I found that they had the same emotional reaction.

As a developer I invest a lot of time learning my current language of choice, having someone come and say that it sucks is not going capture my attention at all, it only gives me the impression that you don’t know what you are talking about and I shouldn’t listen to you.

So from this I learnt that bashing other language / framework is a very poor strategy for teaching or evangelising a new thing. I often see people start talk with something like “I hate JS so …”. I always advice against this as I think you will lose half of your audience there. Always focus on the positives on the new thing and how is better.

5 Likes
20

I know it’s off topic, but this whole discussion reminds me of this.

3 Likes
21

Thanks @Dan_Abrams - Facebooked… …and is definitely on-topic IMHO.

The old saying of play the ball not the man, and the concept of a battle of ideas not people, would seem to suggest it okay to attack JS but not the person using JS.

The problem is that people are so attached to the languages they use and their communities that it becomes part of their self identify and their group identity. This results in an attack on JS feeling like an attack to the recipient.

At times this may be not understood by the person doing the attack. For many, the thinking is more in terms of the right tool for the job. It may seem overly sensitive to take it to heart.

Somewhere in there is a middle ground involving good humour and respect. We should be able to joke about the stupid things in JS - it’s nice and reinforcing for us! JS folks who don’t make the move will undoubtably joke about Elm when they understand it better, around the reasons they didn’t make the move.

Am I saying ‘Just lighten up, people’? A bit more than that. Do it with empathy.

Standing up in a crowd of JS folks you’d have to be quite skilled or clever to get the balance right since they are unlikely to have much knowledge of Elm. And keep in mind that people read public forums like this in the process of deciding to engage, so they will see what we are like as a group. Any heavy handed language control would also be a negative. Better to have an invitational approach with a factual and light-hearted attitude to the differences. The product is good enough to sell itself once people have a play.

5 Likes
22

It surprising how easy it is to overstep the mark
56