[kalcode]

The way that company has posted blog where they seem to have complete lack of understanding what graphql is and their comments on dev.to show a huge amount of disrespect.

The blogs posts comments themselves shows the company's author of these seems dense, rude and unknowledgeable in what they argue. Which also means their product they are making is likely being made by the same mindset.

Definitely wouldn't trust them.

It seems also like a ploy to get attention, which is definitely gonna keep me away from their product.

Seriously, check out these comment section. It's like they posted about something they have no clue about and then are gonna defend it to their grave regardless if they are wrong.

Wait until some security flaw comes out and this attitude makes them unwilling to admit they are wrong. Gross.

https://dev.to/polterguy/oop-a-software-development-mass-psy...

https://dev.to/polterguy/graphql-is-a-hot-smoking-pile-of-ga...

[ShamelessC]

> Even if that was true, the above is 7 lines of code. That is 3.5 times as many LOC as my 2 liner. Science shows us that the amount of resources required to maintain code is proportional to the LOC count. Your example is hence 3.5 times more demanding in both initial resources to create it and resources required to maintain it. One of OOP's sales pitches was "that it makes it easier to maintain your code". You just scientifically proved it wrong ...

I think it has to be trolling, right? I haven't seen mention of LOC as a useful metric since the oughts.

[soulofmischief]

Anyone who's been in the game long enough will tell you that, outside of tight performance-critical loops, developer experience trumps everything. And you cannot reduce devX down to a single number.

[blep_]

That's why I remove all the newlines from my code before committing.

[dangerface]

> If OOP was a solution to anything really, we wouldn't need design patterns, clean architecture, or SOLID design principles.

He's not wrong. I loved moving from C to C++ polymorphic code is such a cool concept but after a while you realise it really doesn't solve anything on its own.

Then you start to encapsulate everything in an attempt to separate concerns then you realise that separation of concerns is actually quite easy if you separate data from function and make sure functions have no side effects, something OOP encourages the exact opposite of.