Switching to OCaml bois

He died of XML factory injection pattern exposure.

It would say Prototype­Filter­Stub­Facade­Bridge­Decorator­Task­Request­Map­Event­Exporter­Info­Model­Request­Iterator

I’m just not sure what the middle guy would be saying

"I hate inheritance! I hate inheritance! I hate inheritance! I hate inheritance!"

But well, inheritance goes brrrrrr.

You will still have private/public sections, interfaces (unless you class them as inheritance), classes and instances, the SOLID principles, composition over inheritance. OOP is a lot more than just large family trees of inheritance, a way of thinking that's been moved away from for a long time.

Yep. I'm old, cranky, and prone to broad statements to get reactions.

That said, for any of you all that love inheritance, I'm judging you so hard. So hard. Very judged. I probably hate your code, and your friends' code, and your last teacher's code. Especially your last teacher's code.

I have the same problem with oop. 10 levels of encapsulated calls just to see you were in an overridden methods without enough data to find out which implementation it was. Ugh

I'm not advocating one way or the other, but I would gladly take on the gardening duties :D

If the only tool you have is a hammer, everything looks like a nail.

That's the only thing I can think to answer your question. There are some problems that are best solved with other tools, like text parsing for example you might want to call out to some code written in a functional language.

I don't think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let's add encapsulation and implementation hiding to this list.

The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore

1. It is difficult to understand: the developer has to open two, three or more different classes to view the whole algorithm
2. It is inefficient: because the algorithm is distributed over many classes and instances, as the algorithm runs, there are a lot of unnecessary calls (eg one method on one instance has to iterate over many instances of its children, and each child has to iterate over its children) and data has to pass through these function calls.

Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it's the function that walks the object structure. The navigation is done using tools like apply or map rather than a loop in a method on the parent instance.

A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.

In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object's private members, or data processing for that object and its immediate children or peers.

I don't really think it's any of those things in particular. I think the problem is there are quite a few programmers who use OOP, especially in Java circles, who think they're writing good code because they can name all the design patterns they're using. It turns out patterns like Factory, Model View Controller, Dependency Injection etc., are actually really niche, rarely useful, and generally overcomplicate an application, but there is a subset of programmers who shoehorn them everywhere. I'd expect the same would be said about functional programming if it were the dominant paradigm, but barely anyone writes large applications in functional languages and thus sane programmers don't usually come in contact with design pattern fetishists in that space.

Operator overloading is adding complexity, making code subtly harder to read. The most important lesson for code is: It should primarily be written to be easy to read by humans because if code is not trash, it will be read way more often than written.

Because an object is good at representing a noun, not a verb, and when expressing logical flows and concepts, despite what Java will tell you, not everything is in fact, a noun.

I.e. in OOP languages that do not support functional programming as first class (like Java), you end up with a ton of overhead and unnecessary complications and objects named like generatorFactoryServiceCreatorFactory because the language forces you to creat a noun (object) to take an action rather than just create a verb (function) and pass that around.

Nothing, just use a good tool for the job, whatever that job requires.

Having to run a debugger to know what gets called at a given time is awful, and this oop practices exacerbate this

But you have used objects I think.

Huh? I've worked with TypeScript + React for the last 5yrs and the only time I see OOP is when someone's done something wrong.

Maybe you're thinking of old react with class based components?

Oh no, the FizzBuzz EE has evolved since I've last viewed it! 😱 Is it bad if it actually reminds me of my current work project's backend (that I haven't written) a bit?

Man thanks for sharing the fizz buzz link.

I got as far as seeing they chose Java and opening the constants file, and immediately executed a strategic withdrawal. I love that people went to this level of detail

Just like any software design principle, it's understood at a surface level by tons of bad developers who then try and solve every problem with that one principle. Then slightly better developers come along and say "ugh this is gross, OOP is bad!" And then they avoid the principle at all costs and tell everyone how bad it is at every opportunity.

Those are nice. Services that manage data are an example. Having the class also declare how to interact with the data is nice.

My most OOP pattern I like using is implementing an interface with an abstract class for "standard" implementation. Then implement abstract methods for a concrete thing.

Excuse me if I don't appreciate when the compiler adamantly refuses to do its job when there's one single unused variable in the code, when it could simply ignore that variable and warn me instead.

I also don't enjoy having to format datetime using what's probably the most reinventing-the-wheel-y and most weirdly US-centric formatting schemes I have ever seen any programming language build into itself.

You spelled Elixir wrong.

once i learned about defer it became a hard requirement. cpp kinda gives me that but other c like languages do it better.