|
|
|
|
|
|
by josephg
1911 days ago
|
|
|
I think the core issue is that OO is one of the first “solve everything” paradigms most programmers learn. Lots of good programmers I know (myself included) have spent a year or two of our careers convinced OO is the solution to every programming problem ever, because it feels so powerful. Some programmers never grow out of that phase. And that means there’s an OO shaped standing wave in the pool of programmers. Each year the OO wave is made up of different people, but the wave itself is always there because there’s always a new generation of programmers going through their baptism of classes. We have to keep reposting Joe Armstrong’s rant because the sooner people learn non-OO paradigms, the better our field is for everyone. These debates only feel like zombies to some of us because we’re old, and we’ve yelled at the kids for overusing classes on our lawns plenty of times already. There are some other interesting conversations - like, where is the line between when you would use OO or bare structs or FP? But those conversations are fuzzy and nuanced, and hard to have without real code examples. |
|
|
This rings true to me. I've dabbled in several languages but started out with Java and for the longest time its style of OOP was how I approached building systems.
In the last 2 years though, I've had the opportunity to work with Typescript and it's been really nice choosing what approach you want to take (structs, functions, or objects). I've found that starting off with plain structs and functions has let our systems grow in a way that would have been constrained by Classifying things up front -- you really _do_ learn more about your application as you're writing them, so why paint yourself into a corner by dictating what data and operations have to go hand in hand upfront?