61–70 of 355 posts
God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.
Let me try to list the objections: 1. Inheritance creates dependencies on their parent class 2. Multiple inheritance is hard 3. Inheritance makes you vulnerable to changes in self-use 4. Hierarchies are awkward for expressing certain relationships All true. But likewise, functions introduce dependencies on their arguments, and data structures introduces dependencies on their fields. You must consider your dependencie…
1. You depend on the library and its dependencies
2. Version controlling libraries is hard when you depend on A and B both of which depend on C
3. Someone changes something in, say, npm and it breaks everything that depends on it. Also, security is only as strong as its weakest library.
4. Do you put everything in one monolithic library or have libraries require each other? Requiring is also a hierarchical graph.
5. Libraries may want to share pointers to the same objects, but then who owns them?
6. Libraries do things for you but sometimes you need to override or customize something, so that breaks encapsulation.
And so forth.
I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…
But, it is not whether a paradigm/language is better than another one.
It is about getting shits done. The paradigm/language war/agile are cargo cult science. It is transforming a practice into a religious thinking while it is not the case.
All the list he makes about OOP is right, on the other hand, you can admit that objects as a namespace can be a right thing.
Like ... well the stringIO, the string and the file or IO objects. But, the data encapsulated these way have finite well known states.
I had a lot of pleasure using OOP in Perl, python, PHP because it was easy to remember where things were for some stuffs, and error/resource handling can be done in a nifty way, even though trying to make stuff optimized for speed or memory required to dive into the guts of the implementations or counter-intuitive so called intuitive ways of doing stuffs.
I guess the rant can be made about making leaky stateful objects that are coupled. Which is what OOP has been advocated for years now. With every dimension with finite states you couple, your cardinality is the cross product of every dimension and it grows more than linearly, defying very soon the brain cognitive power. But still, people insists on going for more complexity because their «tool» can handle it. The limit is NOT the language. It is the human brain. But the hubris is there.
Is Bill built from an Invoice itself built from a Quotation, or are these simple transition applied to a document through the use of functions?
The OOP approach may seem simpler for «encapsulation» but as soon as you add the polymorphism to add the payment gateway and the serialization of data ... and have to make it straight with book-keeping while no developers actually understand accounting, this becomes hell to synchronize what should be plain documents that are worthy with objects. Because ... coders are lost in complexity and lose focus about the real world application, and that what they think may be wrong. Very few coders I know check that their model fit the reality : they make assumptions.
The Quote/Bill/Invoice is basically no better as a poor document in ascii you can read and is self descriptive with stamps giving the stage.
The problem of OOP is documents are «abstracted» as a view on multiple states that are poorly modeled because people are overthinking the implementation and losing the goal : to put $ in the bank and make your accounting/billing/commercial services working. Very soon, the document is very dependent from a database, its view, its controler ....
And, while most boss are kind of embezzling. They don't say it this way, they say they want something flexible that can be easily changed. To make an innovation. All our IT is about subtly walking around rules or regulations.
Coder are over-specialized in coding, while they should first learn the craft they are modeling.
Other times, bosses are overgeneralizing expecting rules (like accounting) to stay the same across country. Well coders being believers they have bugs, not because their code is complex, sometimes because the real world accept no possible automation of tasks.
The problem sometimes do not lie in the paradigm or the language but in the excess of confidence people have.
Let's wait for a few years and we'll see plenty of articles "Goodbye functional programming". You can write good and bad stuff with OOP, you can do the same with FP. There is no one-size-fits-all porgramming style.
You're making a false equivalence. Functional programming has a strong basis in discrete mathematics that OOP simply does not. This makes it better suited to accurately describing computation at a high level than OOP. However, you probably arrived at this conclusion because you still see programming languages as having intrinsic paradigms and those paradigms meaning anything about computation. The fact of the matter…
Functional programming is not that easy to do right in the real world. It takes some level of abstract thinking and understanding. Not too many people in this industry really want to do this level of thinking. They just want a recipe for getting things done with the least amount of thinking.
Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inheritance for encapsulation to be useful, for instance. The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "…
I feel the same way about this as I do platforms. There is amazing projects on every platform. There is horrendous projects on every platform.
Taking sides just a narrows your point of view and lessens the amount you can learn.
Let's wait for a few years and we'll see plenty of articles "Goodbye functional programming". You can write good and bad stuff with OOP, you can do the same with FP. There is no one-size-fits-all porgramming style.
You're making a false equivalence. Functional programming has a strong basis in discrete mathematics that OOP simply does not. This makes it better suited to accurately describing computation at a high level than OOP. However, you probably arrived at this conclusion because you still see programming languages as having intrinsic paradigms and those paradigms meaning anything about computation. The fact of the matter…
Inheritance is overused in OOP. There are many ways to share object behaviors, inheritance only works well when you expect all objects of both classes to share all behavior except one or two things. Even then, you should investigate dependency injection before reaching for inheritance. For the example given for the Triangle Problem, the author isn't clear about exactly what behavior is being shared among the classes.…
Sounds to me like PoweredDevice would be an interface.
Then an interface is a capability.
God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.
Only thing missing is "Father..."
God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.
Only thing missing is "Father..."
If something doesn't need to be an instance, it probably shouldn't be one.
This article articulates a lot of problems I've noticed in OO code, I think it would be foolish to ignore it. My life as a developer became 10 times easier once I realised some of these same pain points and pivoted, or maybe even more so.
In school I was taught all about OO coding practice and I think he's right, they were wrong.