I use both where choosing what I believe is appropriate for particular case.
Frankly I do not give rat's ass about what "People have written extensively". From what I read most of it sounds like spoken by politician: look Jimmy, someone can do a bad thing with it. Well fuckin don't do a bad thing.
So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper.
>"you haven't mounted any defense"
Why would I bother. It does not need a defense. It is like do not use Java because it encourages FactoryFactoryFactory, 20 level of abstraction etc. Well it does not. Architecture astronauts do it and I am not one of those
> So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper.
I don't think so. "Having" vs "being" are descended from an overly simulationist notion of program design. The fact that John has a key in real life does not suggest that this relationship should be represented by an object John which owns an object Key. I think this kind of ontological approach is behind a lot of bad object-oriented design.
> Architecture astronauts do it and I am not one of those
This is the same rationale used to defend memory-unsafe languages. I like that as a point of comparison because we can actually measure the relationship between the use of memory-unsafe languages and the number of dangerous memory vulnerabilities that show up even in highly-scrutinized code bases like the Linux kernel. "I write good code" doesn't fly; bad code is getting written, and the tools we have to correct that are our languages and paradigms.
> Why would I bother. It does not need a defense.
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'm not saying you have to defend it to me—I'm just some guy online—but if you're disinterested in defending it in general, I think that's a craft issue.
>"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.
Frankly I do not give rat's ass about what "People have written extensively". From what I read most of it sounds like spoken by politician: look Jimmy, someone can do a bad thing with it. Well fuckin don't do a bad thing.
So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper.
>"you haven't mounted any defense"
Why would I bother. It does not need a defense. It is like do not use Java because it encourages FactoryFactoryFactory, 20 level of abstraction etc. Well it does not. Architecture astronauts do it and I am not one of those