> 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.
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.
"Hello World is on Fire" (Parody Song About Programming Languages)