>"The fact that John has a key in real life does not suggest that this relationship should be represented by an object"
Exactly and that is my point. If you came up with the set of real business entities, their interaction rules and constraints we would have something to discuss and as a curious person and former scientist I would enjoy it. However blanket statements like "one should not use XYZ some abstract community thinks so" to me have near zero value. I do not waste my time on abstract statements taken out of any real life context
>"This is the same rationale used to defend memory-unsafe languages."
Total BS. What one has to do with the other. And even with memory safe languages it is extreme generalization on your side. Come to a company whose life depends on software running their business that had worked for years without problems and was written in say C++ and tell them that they're "holding it wrong" and must "rewrite it in Rust".
>"If we take our craft seriously, we need to be able to discuss the merits and drawbacks of our tools without getting defensive and refusing to engage"
I do take my craft seriously and my craft is to design and implement robust solutions for clients, bring them value and get paid for delivering said value. I do not find arguing abstract concepts disregarding of particular situation having much value.
> However blanket statements like "one should not use XYZ some abstract community thinks so" to me have near zero value.
Come on, you don't believe this. How about a blanket statement like, "one should not use asbestos insulation in buildings because some oncologists think so"? Is that an "abstract statement" which we shouldn't waste time on? Don't be obtuse. Abstract best practices are valuable sometimes.
> Come to a company whose life depends on software running their business [...] and tell them [...] "rewrite it in Rust".
Obviously a full rewrite isn't typically viable. An approach where the path for new contributions is gradually pivoted to Rust can be much more practical. Google's done this with Android to the tune of a 1000x reduction in the density of memory safety vulnerabilities¹, and that matters. Android vulnerabilities can ruin lives. CrowdStrike's life depended on a piece of memory-unsafe software, and look how that turned out. Don't act like software safety & quality aren't serious concerns.
> my craft is to design and implement robust solutions for clients [...] I do not find arguing abstract concepts disregarding of particular situation having much value.
Again, imagine a housing contractor saying in response to an "abstract discussion" about asbestos insulation. Abstract concepts have concrete consequences. And don't tell me the asbestos example is too extreme, because the consequences of the CrowdStrike bug were extreme too. Software quality matters.
Exactly and that is my point. If you came up with the set of real business entities, their interaction rules and constraints we would have something to discuss and as a curious person and former scientist I would enjoy it. However blanket statements like "one should not use XYZ some abstract community thinks so" to me have near zero value. I do not waste my time on abstract statements taken out of any real life context
>"This is the same rationale used to defend memory-unsafe languages."
Total BS. What one has to do with the other. And even with memory safe languages it is extreme generalization on your side. Come to a company whose life depends on software running their business that had worked for years without problems and was written in say C++ and tell them that they're "holding it wrong" and must "rewrite it in Rust".
>"If we take our craft seriously, we need to be able to discuss the merits and drawbacks of our tools without getting defensive and refusing to engage"
I do take my craft seriously and my craft is to design and implement robust solutions for clients, bring them value and get paid for delivering said value. I do not find arguing abstract concepts disregarding of particular situation having much value.