3 ms·

All 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

All 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 ago
Functional 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 ago
  Imperative 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.

tabtab 4y ago

Functional 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 ago
Imperative 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.