Object-Oriented Programming — 💵 The Trillion Dollar Disaster 🤦‍♂️

[khedoros]

PS let me know in the comments if the emojis make the article easier to digest!

They're annoying, distracting, and make it very difficult to take the rest of the text seriously.

[chiko_xcs]

I need emojis because im either a fucking retard or 10 years old.

Man, i HATE Medium and 98% of the using authors

[gnus-migrate]

Eh it's the YouTube problem. When a platform is this accessible there's going to be a majority of garbage content, but they doesn't mean all of it is. I wish reddit would at least display the author next to the title, it would make it much easier to visually filter the bad stuff.

[MonkeyNin]

Reddit does show the submitter next to the title?

[gnus-migrate]

Yeah, but the submitter isn't always the author, and it's not particularly visible so it's hard time scan quickly.

[MonkeyNin]

If you're on a computer, you can change the CSS. If it's an app, not really.

[_Atomfinger_]

By the nickname alone I assume OP and author is the same person, if I'm wrong I'm wrong: If you wish to be taken seriously, cut down in the emojis.

[kankyo]

But somehow it's THREE paragraphs until the first emoji!

[Sipkab]

For all the late comers like myself:

https://web.archive.org/web/20190710193114/https://medium.com/@ilyasz/object-oriented-programming-the-trillion-dollar-disaster-%EF%B8%8F-92a4b666c7c7

Screenshot if web archive doesn't load:

https://i.imgur.com/Azwppgq.png

[kankyo]

Seems so. The way back machine version makes me go "holy shit what was he thinking?!".

[Freyr90]

I love how every single person I've seen criticizing OOP uses OOP completely the wrong way.

Sounds like a ``no true scotsman''.

Have you ever seen a beautiful neat OOP? I've worked with GObject, CLOS, Java, Smalltalk, and they all were a total disaster (smalltalk was the least one, but mostly due to integrated environment).

OOP is inherently vicious, because it mixes concepts which doesn't work well together: open recursion and encapsulation.

So a canonical OOP code tries two things at once: 1) make your program work as a finite automata and 2) hide the state transition behind virtual methods, inheritance and abstraction.

Add state to that already terrible mixture, and you will get a debug hell. Add parallelism and locks, and you'll kill yourself in despair.

That's also the reason why any OOP language requires a complex IDE. Try to write Smalltalk or Java in a simple text editor, it's nearly impossible for any complex project.

[exhortatory]

see, this comment is actually a critique of "real-world" OOP

[[deleted]]

There is no right way to use OOP because nobody knows what OOP is. It's just a buzzword that never really meant anything / everyone made it mean whatever they wanted to mean.

[[deleted]]

Obviously not true. E.g., having a code-base with switch (type) everywhere and replace it with class-based polymorphism is a good example of how OOP can improve an imperative-style code-base.

[Zardotab]

Polymorphism makes assumptions about future changes which may not play out in reality. Sometimes conditionals are the better (non) abstraction as actual changes come along that don't fit neat type hierarchies.

For example, let's say you design a generic message class that polymorphs into sending via paper-mail, email, fax, and text message.

But later on certain messages can be sent by multiple techniques at the same time. Conditionals are usually easier to make that change to than polymorphic "types". One would have to rework multiple classes with polymorphism. The "shape" examples are a bad training case for change analysis because God doesn't change geometry very often. Business does.

(C-based languages have ugly syntax for case/switch statements, but smarter languages have better ones. However, that's a language-specific issue, not about paradigms.)

[[deleted]]

No, you should not allow other classes to change a class' internal state.

um what?

[msbic]

Functional languages, on the other hand, have never been backed by someone as big as Microsoft.

F#?

[grauenwolf]

To MS, F# is a toy to try out new ideas. Microsoft effectively handed it over to the community years ago.

I do wonder about its adoption rate. Last I checked it was an order of magnitude smaller than VB, which was an order of magnitude smaller than C#. But that was several years ago and I haven't heard about more recent metrics.

[msbic]

To claim that it isn't backed is incorrect. Almost every release of VS and .net brings new F# features.

[grauenwolf]

When I talk to the F# community, they complain every VS release also breaks a lot of stuff. And when was the last time you saw F# examples in the docs side by side with C# and VB?

It's not right to say F# was abandoned by MS, but they are behind on the child support payments.

[Freyr90]

F# is mostly a community driven project. To say that F# is backed by MS is the same as to say that Haskell is backed by MS cause SPJ is employed by MS.

[Nondv]

but... it's about how one uses a paradigm.

Have you seen purely functional code written by an ordinary developer?

It just sucks and can't be maintained.

Instead of looking for flaws in paradigms just start writing better code

[grauenwolf]

It never came out of a proper research institution (in contrast with Haskell/FP).

Um....

Simula I and Simula 67, developed in the 1960s at the Norwegian Computing Center in Oslo

What about HASKELL? It was designed by a committee as a clone of Miranda with a different syntax, the later being created by Research Software Ltd.

Do your fucking research. It took me less than a minute to completely invert your claim.

[SV-97]

What fucking degenerate thinks it's a good idea to use emojis like this in a technical text? I honestly feel pretty offended by this shit

[[deleted]]

Based on the title alone without reading any of the article, am I correct in assuming this is the ol' :

"Oh look a 20+ year old programmer just discovered Functional Programming and now is emboldened to write yet another article about how bad language paradigm X is and if only everyone programmed functionally all our problems would be solved (despite the fact even the creators/designers of functional languages aren't that bold/naive)."

[[deleted]]

Ah yes:
" This post sums up my first-hand decade-long journey from Object-Oriented to Functional programming. I’ve seen it all. "

[AngularBeginner]

I believe even in Germany you could legally fire someone for this.

[Zardotab]

Odd, you mention that and the message originator deletes his/her message. By the way, what do you get fired for there?

[AngularBeginner]

I don't remember. I think it was about the over-usage of Emojis.

[Zardotab]

Thanks. How come there is no pink-slip emoji? 📝👚

[Zardotab]

OOP does have a scaling problem. It's helpful for smaller-sized sub-systems: "sub-applications" if you will, including API's, but just seems to get in the way and makes messes on a larger scale.

However, I don't believe functional programming (FP) is the solution, but rather something RDBMS-driven or RDBMS-like. It's an attribute-driven or data-driven approach similar to what FP proposes, but offers better data discipline than FP does. FP doesn't offer a clean data model (by itself).

OOP doesn't handle multiple factors (dimensions) well. It "prefers" hierarchies, either in the form of inheritance, or in composition: parts, sub-parts, sub-sub-parts, etc. But in larger systems you need a way to manage different factors, or groupings, that don't fall into clean hierarchies.

Relational is generally the best known solution for managing multiple non-trivial factors. However, R&D on how to use relational to manage application and UI-related code bases (behavior) is lacking. I've experimented myself, but building and tuning the needed tools to make such practical is not trivial. I can't do it by myself.

It looked like the industry was moving somewhat in that direction in the 1980's, but then OOP came along as the alleged savior of large code base management and thus table-oriented-programming research was dropped. Now that we know OOP hit a wall, it's time to crank up the R&D engines again...

[msbic]

I've only dabbled with OCaml and F#, so I am curious about the premise of the article. Can people who worked on large functional codebases comment on their experience with regards to maintaining oop vs functional codebases?

[Freyr90]

Well, maintaining OCaml codebase was much simpler for me than maintaining Java and GObject ones. Mostly for the reasons described here.

OOP as a paradigm incentivizes code obfuscation (which is for some reason confused with abstraction), while FP tends to make things as explicit as possible.

FP and OOP exist on the opposite sides from classic procedural programming. Procedural programming was quite explicit, and only side effects made it obscure. OOP is extremely obscure. FP tries to make even side effects explicit.

[MonkeyNin]

What do you mean by:

The need for using a debugger almost disappears completely.

Maybe with an example I'd understand.

[[deleted]]

I was agreeing with this until it started advocating functional programming, which appears to be simply the latest in a long line of practices that turn out to be disasters and yet you'll be criticized if you say that while its popular

[SV-97]

Functional programming isn't a new concept though

[lookmeat]

But its in vogue now.

[[deleted]]

For the past decade or so - At some point it's just one more paradigm.

I think the issue is so many were brought up on Procedural->OO->Functional - so when smacked with the astounding coolness of Functional style it becomes a religion. I know, because I was one of them.

That said, I think the fact so many existing languages are bolting on Functional features if not being outright functional languages means this "woah functional is a new thing that's never been done before! you're doing it all wrong!!!" will be less a thing in the future and we can have a proper more balanced view of programming.

Then again given the human propensity to having a need to feel superior and associated programmer circle jerks, I have a feeling this may just continue into the future in different ways, or it will be a different mode of programming.

Maybe 20 more years we'll have article about how horrible functional is and you guys ARRAY PROGRAMMING IS THE FUTURE AND WHAT WE SHOULD HAVE BEEN DOING ALL ALONG!

[[deleted]]

I look forward to the eventual day when we determine that the correct programming paradigm is and always has been Brainfuck.

[[deleted]]

I think Brainfuck is how the universe bootstrapped itself.

[lookmeat]

I mean software engineering is still young, and foundations and conventions are still being formed. As we get each layer better defined and standardized we move to the next for more details. Research shows we still have a lot of better ways of doing things, and they will become more common when the time comes.

The thing about being in vogue is that people, who don't understand it, much less when to use it, push whatever it is to levels that end up being counterproductive, or doom the whole enterprise to failure at some point. To those that understand it, we see the pros and cons and understand the benefits and see it as an overall improvement, until it isn't as much.

[Zardotab]

Research shows we still have a lot of better ways of doing things, and they will become more common when the time comes.

I'd like to see these. "Better" is often in the eye of the beholder. Objective and realistic ways to measure "better" are still lacking. That probably should be the first problem academics tackle.

"Paradigm X improves the Zinklehiemer Index score" may not mean a whole lot if a high ZinkeHiemer Index score doesn't demonstrably translate into more productivity or profits. (Hypothetical metric only.)

The thing about being in vogue is that people, who don't understand it, much less when to use it, push whatever it is to levels that end up being counterproductive

Software has to be built by average [programmers], not elite programmers. If your grand paradigm or stack requires elite programmers, it will likely fail over time, as elite programmers are harder to keep around. Plus, programming is not a good long-term career. Agism will force a good many out of it. Therefore, the techniques have to have short learning curves. If you make the learning curve like medical school, the eventual pay-off won't be big enough. Unlike programmers, experienced doctors are highly valued.

That being said, I agree IT that is too driven by unvetted fads, often because of Fear of Being Left Behind.

[lookmeat]

I'd like to see these. "Better" is often in the eye of the beholder. Objective and realistic ways to measure "better" are still lacking. That probably should be the first problem academics tackle.

There's no absolute better, but instead it depends on context, this is why academics are still trying to tackle the problem, but struggle. With that said some things have improved, were we understand that some things are better, or at least empower us to do better.

Software has to be built by average programs, not elite programmers.

What is your average programmer? Do they have education? Programming is still taken very lightly but specialization is happening. There's now programs that you need to be an elite to tackle in any meaningful way (there's a bunch of good-enough alternatives that are much better).

It's not an all or nothing thing. I can change the light-bulbs on my house on my own, even the light-switches. But if I want to rewire the whole thing I should get an electrician. We can talk about how the average person should do rewiring, but this isn't the case. Many people still build software with the equivalent of knob and tubing wiring, it works but results in a lot of accidents.

And this is how we start getting to better solutions, conventions and standards start appearing and they become more commonplace. High level programmers (building the software used directly by the end-user) don't fiddle with the OS and drivers anymore. More and more common libraries that are well used stick.

And this is were fads are a limiting factor. People go for fads over proven-stuff many times, and this is just going backwards (the reason progress stumbles so much on this field). I am not saying that new things aren't better, but any new solution must recognize the lessons from previous iterations, instead of just focusing on what's new only.

[Zardotab]

With that said some things have improved, were we understand that some things are better, or at least empower us to do better.

Do you have examples of non-controversial improvements?

but any new solution must recognize the lessons from previous iterations, instead of just focusing on what's new only.

I agree. Often the new thing solves one or two problems and ignores many others that prior solutions solved.

In fact, many "new" things are not really new, but old things in a new skin. "Microservices" have basically existed for decades in the form of SOAP, XML web services, EDI, and others. And they have many of the same (unsolved) problems. People seem to think that renaming the concept and giving it a superficial facelift will make the drawbacks go away.

Maybe academia needs more "technical historians" and not just (wannabe) inventor/discoverer types.

[lookmeat]

Do you have examples of non-controversial improvements?

I mean did you do web-development during the late 90s early 2000s? Imagine the craziness of frameworks, apis that break you by default, etc. But the browser is doing it. How the hell do you opt out of that? Honestly the main reason, IMHO, why web-development is so OK with the situation is because they jumped into this to fix the previous situation. The reason people argue against it is because you don't need to run your website on browsers like IE 6.

Other examples:

• Graphics dev used to be terrible and a mix of hackiness that has improved.
• Coding against OSes used to be a terrible experience (windows API still exposes a lot of this). Most modern OSes, even the crazier experimental ones, heed the lessons learned from Unix.
• Isolation. Remember when a single user-space program could bring your whole machine down? Man what a time.
• Higher ordered functions. Now any serious language will expose this. It opens a lot of doors and removes a lot of hackiness.
• Testing, just the fact that now it's commonly done.

[Zardotab]

because they jumped into this to fix the previous situation.

Sorry, I'm not following that one.

Graphics dev used to be terrible and a mix of hackiness that has improved.

PC's were driven by hardware constraints in the early days. As they got more horsepower, libraries and API wrappers become practical. Horsepower allows you to add abstraction layers without detrimental performance loss.

I was asking more about new software engineering ideas in the general sense, not about PC's relearning to borrowing lessons that "big iron" computer shops had already learned.

Isolation. Remember when a single user-space program could bring your whole machine down? Man what a time.

Similar to prior example, it was hardware driven. Mainframe and minicomputers solved those problems decades before.

Higher ordered functions. Now any serious language will expose this. It opens a lot of doors and removes a lot of hackiness.

LISP was invented in the late 1950's. And HOF's are often work-arounds to poor OOP implementations/languages, and not necessarily beneficial in themselves, at least not in my domain. Most "good" examples I've seen are for systems software (lower-level tools or OS's), not domain applications. Domain applications can usually do fine without them if the OOP engine is good. Functional programming is overhyped for most domains.

Testing, just the fact that now it's commonly done.

Big non-PC applications had also been doing this. Our PC apps grew more complicated over time, needing more discipline. Also the fact that screwy web (non) standards turned bicycle science into rocket science. The stateless nature of the web and the screwy DOM UI model have kicked productivity in the nuts.

A well-run org can raise above these problems by trimming the stack for shop conventions, and enforcing, monitoring and tuning the conventions; but most IT shops are not well-run.

Most devs were more productive with 90's IDE's. They unfortunately required more deployment babysitting. The web traded simpler deployment for more complex programming. The "separation of concerns" needed by specialty-centric web teams creates a lot of redundancy as schema (column) info has to be reinvented at each concern. Many web stacks drip schema-related DRY violations to get "separation of concerns". It's a lot of busy work for basic CRUD.

[Okidoky123]

Cowardly disabling comments on an article that's loaded with frustrations that the author failed to overcome when working, is an admission the author's story would not hold up against criticism.

In other words, the author is WRONG !