5 ms·
Agreed. You should know that in the past when OOP was not common, we had to work a little harder doing things like managing our own memory or building a LAMP s
by Jemm 4y ago
Agreed.
You should know that in the past when OOP was not common, we had to work a little harder doing things like managing our own memory or building a LAMP server to publish our web pages.
There was a thriving market for language and UI add ons. The result was that each company had their own internal dev tools and recruiting people outside of the company who had experience with those tools was nearly impossible.
All that said, we were at a point where entry to programming was easy (think Visual Basic in the 90s). The quality generally went down as everyone was pushing their "first project" as if it was a polished product. Finding actual good programs on PC is close to the situation on mobile where most of the apps are trash.
- deltaonefour 4y agoOOP to me would be classified as the industry blindly moving towards unnecessary complexity. It is indeed the definitive example of how the industry over-engineers things. While still prevalent today, there's a huge sentiment against this paradigm. Modern languages and frameworks such as React, Golang and Rust show how the tide is turning against this.
- ptudan 4y agoThree object oriented languages prove how there's sentiment against OOP? Or are you saying that Rust/Golang/React are simplistic in a world of over complexity. React I would generally agree with, the other two not really.
- ushakov 4y agoReact is extremely complex internally
- ptudan 4y agoVery true, but unlike backend languages you can generally get away without knowing much about the internals. Unless you're making dev tools of course.
- deltaonefour 4y agoI think react was an attempt at simplification. OOP isn't the only thing that influences complexity. Simply switching a project from OOP to a more FP like paradigm doesn't necessarily make the framework simpler because of other confounding factors.
- deltaonefour 4y agoAll three are moving away from OOP. Functional components in react. Zero classes in golang or Rust. It's actually quite an obvious paradigm shift. No classes with these languages yet every language prior to this has classes. Yet I don't understand why people still insist on calling go and rust object oriented or why they try to argue this point when there is such an obvious change. I mean sure you can twist the language into something that looks like it's oop but come on man. Haskell is OOP if that's the case. Let's not argue about whether these languages are OOP or not. The point is there is an obvious movement AWAY from OOP with substraction of popular and critical syntax and features. For React , the trends are harder to see. See here: https://hackernoon.com/react-functional-components-are-the-future https://hackernoon.com/react-functional-components-are-the-f... The react team recommends functional components over classes, and react itself was derived from functional languages and concepts. I believe the team ideally would like to see ReasonML as the future and react with js syntax is more of a necessary in evolutionary inbetweener thing.
- tabtab 4y agoFunctional can be tricky to debug, as the frowned-on "intermediate state" of imperative programming makes for great x-ray examination points during debugging. The backlash against OOP is partly because existing OOP engines are limiting in many languages. Passing, grouping, and custom-scoping of "blocks of code" (BOC) should be more flexible so that we are not forced into hierarchies or spaghetti scoping. We need new languages that make managing and scoping BOC more flexible. I want to define the scope, not let Nadella or Bezos do it. The distinction between a lambda and method would then be fuzzier. BOC's would no longer be forced to be one or the other. (One these days I may make a proof-of-concept language.)
- deltaonefour 4y agoImperative and OOP are not the same though. None of the languages I mentioned are FP. Though FP has benefits and many of the languages or frameworks mentioned above are either moving towards FP or borrowing concepts from FP. You're not wrong about intermediate state. I shouldn't have emphasized FP here that wasn't my point. An imperative program that is just imperative without OOP or FP tends to be simpler then OOP itself.