Interesting take on the PLO - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
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.
I need to see where it came from, I don't understand what about spargeting at all.
A good feature of any code is to have functions as short as possible. You'd better have more of them.
For example, half of OOP properties are things we would want to separate for usability - for example, separate a number of functions into a group and give them their own variables that would live in their namespace).
Since we're working with a storage type "class", we can clearly pre-define all variables to give them a certain type....
it is convenient to create external API. You can work with class reference (8 bytes) when working - very often used.
Example: All sorts of linked node lists and stuff.
// here I wrote only peculiarities that I see, it is clear that there is no sense to write about possibility and properties of protected methods and other things.... that's just sugar.
Properties of FP is what we would like to do somewhere, after something, for example, we would like to make up a new function on the fly in the function - divide current function, which would use some of the current variables from our function. To pass its execution to another function - it turns out we just pass the delayed function, the calculation that has not yet occurred - just as a piece of code....
In fact, this is quite convenient.
This leaves the property of full code unrolling because in fact we clearly know what function we've got - which is likely to be faster in calculation than OOP. You can organize rather clever transfers of calculations from one function to another - also function completely remembers environment of called variables of past function - which is very cool (although in fact it's just saving declared variables from external scope). FP, on the other hand, you can set the address of a function and store it in an array like a class - though not particularly useful.
Easy to write code for delayed actions, all sorts of asynchronous functions, parallel calculations
Let me explain my concerns based on the quoted article and the concept of determinism itself. What scares me about "spaghettification" (the complexity of the code itself and the task of finding calculation errors )? So what is the emphasis in the article - "rubbish" values in variables or nondeterministic returns from functions.
I build/train neural networks of my variable(evolve) structure. And for them it is very critical that "rubbish" in values comes out of nowhere.
Like in the article - you press the brake pedal, and the pedal doesn't give a damn about you. That's in use. And if at the initial stage of building (automatic selection of architecture) and training of your neural network "rubbish" is possible - how it is built/trained?
How to avoid "rubbish" (nondeterminism) in OOP as much as possible?
Let me explain my concerns based on the quoted article and the concept of determinism itself. What scares me about "spaghettification" (the complexity of the code itself and the task of finding calculation errors )? Well, that's what the article focuses on - "rubbish" values in variables or non-deterministic returns from functions.
I build/train neural networks of my own variable(evolve) structure. And for them it is very critical that "rubbish" in values comes out of nowhere.
Like in the article - you press the brake pedal, and the pedal doesn't give a damn about you. That's in use. And if at the initial stage of building (automatic selection of architecture) and training of your neural network "rubbish" is possible - how it is built/trained?
How to avoid "rubbish" (nondeterminism) in OOP as much as possible?
The article in general is somewhat strange, the man clearly forgot to specify the type of const variable, like he had js then at least readonly. After that he writes that he supposedly had an error when the object that must not change the size (be a constant) is somehow not a constant ..... and based on this he makes conclusions that there is much probability of an error in OOP)))
In general, OOP allows you to control areas of variables. OOP is designed to pass variables from a function, i.e. the type should already be defined by default since there are most likely few of them. And if necessary, this function itself can be expanded on the fly.
I.e. in OOP there is more initial control
That's it, I always suspected)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23I don't understand who writes such "articles", empty rhetoric, general phrases, minimum sense.
" The code as a whole was confusing and messy - what is called "spaghetti " in slang " - because of bad programmers atToyota we will consider that inOOP the code is confusing.
" The built-in OOP features only add to the confusion. " - well logic, the ability to use features add confusion to the code, with a constant increase in the number of OOP (C#) features it will be impossible to write simple code anymore. Yes.
"In most object-oriented languages, data is passed by reference, i.e. different parts of the program can deal with the same data structure - and change it. This turns the program into one big lump of global state and contradicts the original idea of OOP " - Andprivate,protected?
"...If you don't like this quote, it's because nondeterminism in general gets you nowhere."Well, yes, the unpredictable functions GetMicrosecondCount, MathRand, CoptBuffer, all the network functions and others should be thrown out because the result there depends on the external state. It is horrible.
Okay, enough, everything is clear here.
There you go, I always suspected)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Most of the arguments there are sucked out of your fingers. Some experiments "proving" the invalidity of OOP are incorrect at all. In normal OOP languages sum(int a, int b) will always be clean, even if you write nonsense like a += b internally. Again, if an object is allocated on heap inside a method, it is always protected, because only the method which called it has a reference to it. You can change it at will. There are reference and significant types. No one prevents you from writing clean functions without any side effects in OOP languages. The standard mathematical functions are like this, for instance. Yes, sometimes you can't do without shared resources, but there are handy thread-safe collections and much more. After all, any pure FP will inevitably interact with IO, BD, network requests and many other things, which is where modifiability daemons will break through.
Weird article....
Quantity tends to change into quality.
When there are a lot of radios, there can be electromagnetic incompatibility and they will stop working.
The spaghetti properties of code is usually from quantity and not taking into account all the properties of the wrapper when there are many uses in different states.
In functions the presence of feedbacks will lead to the same thing. Hysteresis is a joke)
Understanding problems, and getting them right ... ))))
// I have only described the features that I can see here, obviously there is no point in writing about the possibility and properties of protected methods and other things.... that's just sugar.
Properties of FP is what we would like to do somewhere, after something, for example, we would like to compose a new function on the fly in a function - sharing the current one, which would use some of the current variables from our function. To pass its execution to another function - it turns out we just pass the delayed function, the calculation that has not yet occurred - just as a piece of code....
In fact, it's quite convenient.
Well, who prevents to do the same in OOP? Even in a purely procedural language? You pass a pointer to a function to another function and get delayed execution.
In general, asynchrony is a pure design pattern. You can write asynchronous code in pure C as well. You just need to make a state-machine that performs the task in parts. By the way, I did it with indicators in MQL which took a long time to be calculated. I did it to avoid slowing down the chart and display a nice status-bar that changes its percentage of fulfilment.
Well, who prevents you from doing the same in OOP? Even in a purely procedural language? You pass a pointer to a function to another function and achieve delayed execution.
In general, asynchrony is a pure design pattern. You can write asynchronous code in pure C as well. You just need to make a state-machine that performs the task in parts. By the way, I did it with indicators in MQL which took a long time to be calculated. It helps me not to slow down the chart and display a nice status-bar that changes its percentage of implementation.
) You may also use assembler. The question is where it's easier.
And do not put me in one or the other side.... I'm not a stickler for one thing or the other.
Strange article. OOP doesn't differ from procedural style for the worse, because in it you can do everything in procedural style by default, and vice versa without terrible code bloat, i.e. OOP is a "superstructure over", not a fundamentally different style.
If the article is really about functional rather than procedural (which isn't that obvious if you pick on it), then why compare things that have completely different uses.
Topeka starter, are you yourself writing and now talking about which? functional or procedural?
After all, what it turns out is that OOP is mostly for readability and team programming, i.e. for big projects.
I don't know how to use OOP. But I do use primitive things of it. From the recent past, posted some very simple code.
Started writing it in FP, when I didn't yet understand what I would eventually need to look at.
Finished through primitive OOP elements. Probably lost FP skills, but here OOP seemed much simpler and more readable.
The code is very simple and short(description). If you write it in FP, it would be interesting to compare.