Interesting take on the PLO

New comment
 

There you go, always suspected)

https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23
 
Read fewer articles from radical FP activists. The FP concept is not a year or two old, but you don't hear about a revolution
 

This is not a problem with OOP, but with its application, and even more so with those who apply it. They're the ones who feel...

enthusiasm, even ecstasy that with the help of OOP you can write incredibly

incredibly complicated code (and even compete in it :). They feel themselves to be a special elite.

They even invented their own "great book" which they read and read and read but can't

but they can't read it. It's called " Design Patterns" - in human language

translates as "The Ultimate Art of Writing Fuzzy, Muzzy and Confusing Code". If, however.

it 's a very, very cool thing, incredibly simplifying and

simplifies and simplifies life.

 
Mikhail Mishanin:

There you go, always suspected)

https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23

You should understand that such articles are most likely written by people who are unfamiliar with FP and their confusing hooks, which can include 20 tabs....

Hard FP is something else. Then you start thinking about laconicity and convenience of OOP, you can declare some of functionality in advance and so on..... In essence, the similarity of one with the other. That's just such articles are often written by people who have mastered only procedural code - and this is not even close to FP, so if you do not know what the hooks and vivid use of it, no FP is out of the question

Also many of the "dyinglanguages" listed in the article support full functionality of FP and OOP, why should they die?! And a couple of them are the highest paidin the CIS
 
I was rather talking about "spaghettification" in OOP, without any thought of "drowning" in FP. In my opinion, the procedural paradigm is realistic and more resource-efficient than OOP.
 
Mikhail Mishanin:
It's more about "spaghettification" in OOP, without any thought of "drowning" in FP at all. In my opinion, the procedural paradigm is realistic and more resource-efficient than OOP.

just that the code itself is longer on oop? well, yes, there is a constructor and in some cases the code is usually longer on it.... technically, FP deployment should be more efficient for machine code generation.... but the code doesn't get any simpler and it's impossible to make normal wrappers as far as typing is concerned...

these days, you can often find a mixture of one and the other - ways don't interfere with each other

 
Alexandr Andreev:

just that the code itself is longer on oop? well, yes, there is a constructor and in some cases the code is usually longer on it.... technically, FP deployment should be more efficient for machine code generation.... but the code doesn't get any simpler and it's impossible to make normal wrappers as far as typing is concerned...

Nowadays, it's often possible to see a mixture of one and the other.

Without OOP and FP everything works easier and faster (yes, without "beauties", panels etc.), but it is sometimes difficult to understand even your own code)

 
Mikhail Mishanin:

Without OOP and FP, everything works easier and faster (yes, without "beauties", panels, etc.), but it is sometimes difficult to understand even your own code).

First master one or the other, or better both, and then decide what you prefer. And with such an approach as now in time you will turn into Fedoseev who agrees with everything you don't understand (i.e. almost everything).

 
The worldwide new-technology trend is to study something new for three months, use it for a month (gathering a bunch of bugs), then scrap it, and then study something new again for three months, only to scrap it in a month (gathering another bunch of bugs). If someone likes to live their life this way - you're welcome.
 

What a destructive reaction to the topic and a destructive discussion. Tell me a follower of Procedural programming how to avoid "spaghettization" in OOP, how to parse and whether it makes sense to use someone else's "spaghetti"?

After all, what turns out, OOP is mostly for readability and team programming, i.e. for large projects. An Expert Advisor that trades a symbol to its chart with the control of the maximum risk of the balance / funds in the account, well, can not be called a big project - it is sufficient and more profitable in memory / speed - procedural programming.

Questions:

- disadvantages/advantages of OOP(as imperative) from personal experience

- disadvantages/advantages of FP (as declarative) from personal experience.

And an opinion on the prospects is of course interesting, especially in the direction of parallel computing. I don't see any point in touching the quantum topic.

 
Mikhail Mishanin:

Tell me, as a procedural programmer, how to avoid "spaghettization" in OOP

The recipe is given in the quoted article: strive to write deterministic functions.

How to disassemble and does it make sense to use someone else's "spaghetti"?

Good code, yes, but not spaghetti.

After all what do you get, OOP is mostly for readability and team programming, i.e. for big projects.

Right.

An EA trading a symbol to a chart of which it is attached with maximum risk control of the balance/account funds, well, can't be called a big project - so procedural programming is sufficient and more profitable in terms of memory/speed.

To travel to Australia, it's more convenient to use a plane (OOP), to travel to a neighbouring city, a car or even a bicycle is sufficient (PP). You just have to choose the more convenient means to achieve the goal.

12345678910111213
New comment