The information presented implies that techno-tribalists are rare. Certainly not enough to warrant such a long essay that I gave up reading it.
> Every so often, a developer forum erupts into war.
This implies that language debates are relatively uncommon.
> Yet the vast majority of language debates in technical communities erase every constraint from the outset and step straight into the arena of “which is better.”
This seems to omit the large number of intra-language debates, like the uproar over the walrus operator in Python, or formalized debates which go into C++ language changes, or the "which is better" debates about new core library APIs, or the "which is better" debates about which package is more important.
A lot of this debate is dog-shedding, not "techno-tribalism". It's people who have and want to express their opinions.
The author failed to define the group any tighter than the entirety of a language or Linux distribution. As a result, this claim:
> The function of this structure is to maintain group cohesion.
is likely wrong. If most Python developers do not participate in these language debates, and most Python developers that there are trade-offs, then group cohesion clearly exists without language holy warriors.
CPython in specific has always promoted itself as being both extensible by and embedded in C programs. You will be hard pressed to find a Python core developer -- or any C/C++/Fortran/Rust extension author -- making the argument that Python is a better than C for all cases. (Some PyPy developers might say otherwise.)
Which means the "group" in "group cohesion" must exclude quite a few people in the group of Python developers.
I am a Python developer. I've used Python for decades. Go ahead and criticize Python. I've heard it all before.
It's more often what newbies do when they have a chip on their shoulder and haven't yet learned better. That's not tribalism but inexperience.
What do you think about the (quite infamous) Method Resolution Order (MRO) and C3 linearization algorithm, which is, basically a topological sort over the inheritance chain IIRC? And I have a lot of mysterious package bugs are actually due to that breaking, like I used to have with ComfyUI.
But you know, I've worked with Python codebases before, and all those are painful to deal with. Don't get me started with the confusing aspect of **kwargs vs **args, although in JS there is a similar concept called arguments object (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) and spread operator I think?
Oh, I still remember one particular hell that my team wrote scripts that directly add packages to PYTHONPATH. THE PYTHON FUCKING PATH.
The fact that you can directly append to sys.path is mindblowing and ridiculous to me. You can totally insert some malicious code to take over the program, so this is a huge cybersecurity issue. I tried to solve this by introducing Poetry (or is it PDM? I don't remember) to the team but nobody follows. Back then uv doesn't exist if I remembers, but the effort to "correct" (hell I don't even know if that is really correct or not) it is kinda futile.
As a DevOps that creates a huge dependency hell and I resigned soon after. Perhaps it is a cultural problem I don't want to drill on in too mcuh.
Okay, maybe something else more meta. The fact that Python wants to have duck types and traditional OOP is kind of like having a cake and eat it, you really can't have both, unless you have some form of mediators, like you have interface/protocol in C#/Java/Swift/Obj-C.
With Python, almost everything is a dynamic value, even with the new type hints facility. Same problem goes for JavaScript (and evolving it to a certain extent, TypeScript too).
I think that's one of the few banes of prototypical design I would say, that everything essentially becomes a hash table in live environment.
But I guess it is suffice to say, the legacy of Lisp really does live on.
People think programming languages are just tools, but the persistent holy wars should tell us they're more than that.
If you really want to understand the holy wars you have to view programming languages as though they are cults. Not all of them, but there are enough that have cult-like properties for it to be a common way PL communities organize.
First and foremost the core promise of a PL is a way of thinking that will lead to nirvana - better code, faster code, safer code, whatever. Choose this PL and you will experience coding bliss. They divide the world into followers of "the way" who are on a path to enlightenment, and outsiders who are lost in the wilderness of inferior thinking. Sometimes the rhetoric becomes very on the nose it becomes hard to see how people miss the cult parallel e.g. lispers calling it "God's programming language".
Often times they are lead by a charismatic BDFL who have no trouble forming a personality cult. e.g. Johnathan Blow -- Jai is a PL cult that doesn't even have a PL. It's held together by Blow's personality and a promise of nirvana one day. Urbit was a cult formed around Curtis Yarvin's technical implementation of his neoreactionary politics. These people are often deified by their communities as "Godlike" programmers or in the case of Ruby, they want to be more like their founder because he's nice; "MINASWAN" is very high on the cult-ometer, basically reads as "WWJD" to me.
There are sacred scriptures and sacred texts as well. Various tomes like K&R, SICP are held up as bibles. Zen of Python reads like a version of the 10 commandments. They detail the steps one must take on their path to enlightenment within the language, and people get dogmatic about them.
There's also great pressure from within the community to never leave, and great retribution is visited upon those that do. e.g. Bun leaving Zig and the Zig response to that was to go scorched Earth against the Bun dev. There's a religious fervor to that kind of response.
Lot's of other parallels, you could write a dissertation on this.
Seems to apply to tribalism in general, not just about technology.
The information presented implies that techno-tribalists are rare. Certainly not enough to warrant such a long essay that I gave up reading it.
> Every so often, a developer forum erupts into war.
This implies that language debates are relatively uncommon.
> Yet the vast majority of language debates in technical communities erase every constraint from the outset and step straight into the arena of “which is better.”
This seems to omit the large number of intra-language debates, like the uproar over the walrus operator in Python, or formalized debates which go into C++ language changes, or the "which is better" debates about new core library APIs, or the "which is better" debates about which package is more important.
A lot of this debate is dog-shedding, not "techno-tribalism". It's people who have and want to express their opinions.
The author failed to define the group any tighter than the entirety of a language or Linux distribution. As a result, this claim:
> The function of this structure is to maintain group cohesion.
is likely wrong. If most Python developers do not participate in these language debates, and most Python developers that there are trade-offs, then group cohesion clearly exists without language holy warriors.
CPython in specific has always promoted itself as being both extensible by and embedded in C programs. You will be hard pressed to find a Python core developer -- or any C/C++/Fortran/Rust extension author -- making the argument that Python is a better than C for all cases. (Some PyPy developers might say otherwise.)
Which means the "group" in "group cohesion" must exclude quite a few people in the group of Python developers.
I am a Python developer. I've used Python for decades. Go ahead and criticize Python. I've heard it all before.
It's more often what newbies do when they have a chip on their shoulder and haven't yet learned better. That's not tribalism but inexperience.
> Go ahead and criticize Python
Okay, I will be the one to challenge you.
What do you think about https://docs.python.org/3/library/abc.html and how painful it is to work with?
What do you think about the (quite infamous) Method Resolution Order (MRO) and C3 linearization algorithm, which is, basically a topological sort over the inheritance chain IIRC? And I have a lot of mysterious package bugs are actually due to that breaking, like I used to have with ComfyUI.
But you know, I've worked with Python codebases before, and all those are painful to deal with. Don't get me started with the confusing aspect of **kwargs vs **args, although in JS there is a similar concept called arguments object (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) and spread operator I think?
Oh, I still remember one particular hell that my team wrote scripts that directly add packages to PYTHONPATH. THE PYTHON FUCKING PATH.
The fact that you can directly append to sys.path is mindblowing and ridiculous to me. You can totally insert some malicious code to take over the program, so this is a huge cybersecurity issue. I tried to solve this by introducing Poetry (or is it PDM? I don't remember) to the team but nobody follows. Back then uv doesn't exist if I remembers, but the effort to "correct" (hell I don't even know if that is really correct or not) it is kinda futile.
As a DevOps that creates a huge dependency hell and I resigned soon after. Perhaps it is a cultural problem I don't want to drill on in too mcuh.
Okay, maybe something else more meta. The fact that Python wants to have duck types and traditional OOP is kind of like having a cake and eat it, you really can't have both, unless you have some form of mediators, like you have interface/protocol in C#/Java/Swift/Obj-C.
With Python, almost everything is a dynamic value, even with the new type hints facility. Same problem goes for JavaScript (and evolving it to a certain extent, TypeScript too).
I think that's one of the few banes of prototypical design I would say, that everything essentially becomes a hash table in live environment.
But I guess it is suffice to say, the legacy of Lisp really does live on.
People think programming languages are just tools, but the persistent holy wars should tell us they're more than that.
If you really want to understand the holy wars you have to view programming languages as though they are cults. Not all of them, but there are enough that have cult-like properties for it to be a common way PL communities organize.
First and foremost the core promise of a PL is a way of thinking that will lead to nirvana - better code, faster code, safer code, whatever. Choose this PL and you will experience coding bliss. They divide the world into followers of "the way" who are on a path to enlightenment, and outsiders who are lost in the wilderness of inferior thinking. Sometimes the rhetoric becomes very on the nose it becomes hard to see how people miss the cult parallel e.g. lispers calling it "God's programming language".
Often times they are lead by a charismatic BDFL who have no trouble forming a personality cult. e.g. Johnathan Blow -- Jai is a PL cult that doesn't even have a PL. It's held together by Blow's personality and a promise of nirvana one day. Urbit was a cult formed around Curtis Yarvin's technical implementation of his neoreactionary politics. These people are often deified by their communities as "Godlike" programmers or in the case of Ruby, they want to be more like their founder because he's nice; "MINASWAN" is very high on the cult-ometer, basically reads as "WWJD" to me.
There are sacred scriptures and sacred texts as well. Various tomes like K&R, SICP are held up as bibles. Zen of Python reads like a version of the 10 commandments. They detail the steps one must take on their path to enlightenment within the language, and people get dogmatic about them.
There's also great pressure from within the community to never leave, and great retribution is visited upon those that do. e.g. Bun leaving Zig and the Zig response to that was to go scorched Earth against the Bun dev. There's a religious fervor to that kind of response.
Lot's of other parallels, you could write a dissertation on this.
There can be only one.
"Hello World is on Fire" (Parody Song About Programming Languages)
https://www.youtube.com/watch?v=Uqp5tXbmu5g