Technology Holy Wars Are Coordination Problems
gwern.net
gwern.net
I read a few years ago "under all anger is fear". I'm not sure if that's completely true (hanger is a thing), but I think it's right most of the time. I've found it very useful when I feel angry about anything to take a step back and think about what I'm afraid of - that's usually the thing that really needs to be addressed.
It seems to me that the anger is not driven by fear of loss of power it is driven in a case like this by envy of the reward one lost out on. by envy of lack of access to more power.
I am in a very unfair relationship right now and my anger is not fear driven, as in what will happen in the future, it is generally anger at what is the current situation. Thoughts of - If they had not done X I would not be in condition Y.
To turn that into a fear situation you have to ignore what I say is the cause of my anger, then postulate something like "he fears condition Y being permanent, or condition Y turning into condition Z" when condition Y should provide ample grounds.
Actually the more I think of this fear thing as the root of anger the more messed up it seems to me, because it seems structured around people never caring about their current or past situations but only about the future, and I don't think real people act like that.
somewhat facetiously - Are you sure this fear theory wasn't created by an economist?
Animals have similar emotions. Bruce Shneier has written a great book “liars and outliers”, which talks about how we maintain the trust society needs to operate.
Studies it cites have shown that people are willing to take a loss to punish others who they perceive are cheating and breaking rules, especially if they do it all the time.
Anger is often the response by those affected, and to a lesser extent those who enforce norms, to systematic rule breaking, and accomplishes the two things:
1) Unmistakably calling attention to the issue and oneself
2) Signaling a willingness to escalate to mutual loss if need be, if the behavior persists
So, to say it’s driven by fear is too reductionist! It serves a major function in human interactions. Consider Steve Jobs’ reaction when Google was going to go ahead with the Android.
Finally, if you want to avoid anger in your own relationships, the key is to hold people to a lower standard and expect less of them as ethical and rational human beings. People find it hard to do because, to stop fighting with someone, you have to greatly lower your respect them in certain areas. But the funny thing is, they will often appreciate you for doing this, and never wanted that respect! Not really, anyway.
Our limbic system isn't that different.
Google anger is a secondary emotion for more on this
Anger leads to Hate.
Hate leads to Suffering.
Yoda.
I understand the need for fundamental changes and Open Source projects are basically free to do whatever. Maybe something needs an overhaul, maybe the landscape changed, maybe there's a need to change the foundation to make the project more future-proof.
But, I can fully resonate with Armin Ronacher's [1] viewpoint, that instead of acknowledging that these migrations are painful for everybody involved, the maintainers or the community often turn this around into "Everyone who does not upgrade misses out" which causes emotional distress.
So actually you do not have a choice. You migrate or are left behind.
Moreover this affects decisions in the corporate world. Do you chase after the bleeding edge or use stable frameworks which are guaranteed to be supported for more than 10 years? I believe, that is the reason many corporations are so entrenched in the Microsoft stack and Open Source could definitely try to be more sensible in this regard.
[1] https://lucumr.pocoo.org/2019/12/28/open-source-migrates/
- Users of one platform have gotten used to it, have gotten over, or adapted to some of the pain points, and/or have developed effective workarounds. Having passed all those stages, their day-to-day interaction with that platform is a state of comfort-zone. Call this mental state A.
- When those users attempt to analyze or review a competing platform (which is new to them since they haven't spent time using it), not only are they uncomfortable with the overwhelm that comes from getting inundated with new information, and having to process all of it, they're also keenly perceptive of every "dot", "comma", "cross" that is, metaphorically, misplaced in that competing platform, i.e., any deficiencies of the competing platform jump out at them like a sore thumb. Call this mental state B.
Holy wars occur when users of two competing platform argue in favor of their own platform from a mental state A, while attack the competing platform from a mental state B.
That is a really insightful point. One think gwern doesn't dive into is that someone closer to one can cost one more. I get more annoyed when someone tries to rewrite Emacs in Scheme than in Rust. The Rust programmer would probably never have written Lisp code, but the Scheme programmer might have. Likewise, someone who writes a neat extension for vim might have been willing to write the same functionality for Emacs — but someone who extends Eclipse would probably never have spent any time on Emacs.
It goes in the other direction in both cases, too!
Sigh, caught it just after the edit window closed!
Sure, they might really like the underlying functionality emacs has, but even evil-mode can't completely hide emac's UI.
I wish there was an emacs with a totally user-defined UI, so some people could configure their UI to feel like Vim, others like emacs, and others as something completely different.
Sure, you can replace the default keymaps, but that only gets you so far. If you go down this road (I have), it quickly becomes a futile effort to remove the emacsness from your UI.
Platforms does indeed split the user base...
The unix solution is offloading the complexity on the script, which makes all scripts more difficult to write.
"The great thing about standards is that there are so many to choose from. "
The point in having standards is not to have the one ultimate standard that everyone uses, but to have a documented way to interoperate at all without interrogating the author or reverse-engineering.
Citation needed. From the latest Rust survey [1], Vim was in second place at 23.6%, behind only VS Code at 34.9%. Emacs was lower at 7%, but still beat Sublime at 4.3%, and Eclipse doesn’t even show up on the list. Not that Rust is representative of programming as a whole, but its results are still probably more accurate than what seem to be anecdotal impressions of editor popularity.
[1] https://blog.rust-lang.org/images/2020-03-RustSurvey/31-edit...
https://i.imgur.com/D128c3T.png
For developers who responded "I am a developer by profession" and used C, C++, Java, and/or Python in their dev environment, VSCode tops VIM, which tops Sublime, which tops Emacs. Every time!
Source: StackOverflow survey results from 2019. Looking at 65,679 responses marked as "I am a developer by profession" https://insights.stackoverflow.com/survey
1. What development environment do you use most (IDE)?
2. What editor do you use most?
3. What editor(s) do you use regularly?
Personally, my day job currently has me working in Java, and I use IntelliJ for that. However, I use Emacs on a daily basis _as an editor_; especially in the case where I need to look at, move around, and manipulate files quickly.
If I had to pick one of them to keep and one to give up... I would be sad, because the fill different roles.
Power structures within tech communities ossify and the community itself can regress in their abilities. And so this means that technologies can sometimes get worse over time.
So that can create conflicts between old tech which is proven and reliable and new tech which is not proven and can be unreliable.
If you click the fnref for one of the footnotes[0] the quote it is referencing gets cut off and isn't readable anymore (but is correctly formatted beforehand).
Another is interface. There are plenty of people who would love to use Vim, but simply don't like the keybindings. Same for emacs, every window manager/desktop environment, etc.
For no reason in particular, we tend to very tightly couple functionality to interface. We could avoid an awful lot of duplicated work if we factored UI out of tooling, and made it more user-definable.