Talking about the PLO in the lounge - page 21
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
Militant ignoramuses - how precise and succinct. I'll add to my vocabulary. :))
No, the point is different. There is a banana that you have to eat according to the logic of the program, but you have to eat the palm and the black earth with the manure along with it.
Well, no.
You don't see a palm tree, black earth, fertiliser or a monkey. It's all encapsulated and you don't have access to it.
That's what I'm talking about ! It's just in the functional approach - you have to drag it all EXTREMELY behind you to get a banana. In the OOP approach, the compiler will drag it for you. You - get the "banana" through an agreed interface, and you don't know where it came from. You can find it out if you have proper access.
That's the point of OOP - only what you need, in this case banana, should be available to you. No palm-fertiliser-peanuts are available to you. They exist (otherwise, where did banana come from), but you don't have any access to it, and with all your will you won't be able to chop down a palm tree or kill the very monkey who is ripping up your banana.
What is torment for normal people is joy for masochists... :)
You could imagine that the PLO is your home, with its own rules. There are things that are common to all. These are table chairs, forks, spoons, etc. But there are things that are not even available to the residents of this house. For example personal belongings, a safe etc.
The owner of the safe may give access to the safe. Strangers have no right to enter this house without permission.
You can use a class to describe this house, what's in it with certain functions of each. And the house itself is an object.
OOP is like our life. It looks like a person and consists of two parts: the soul, which describes and controls it, and the physical body, which is an object.
OOP is a discipline, not anarchy - whoever does what they want.
After all, the OOP paradigm can be truly understood only by real programmers who are in love with their craft.
Not necessarily.
Renat on the previous page - quite rightly noted that "put him to do a real project" - he will fail it. And he will quickly become convinced of all the advantages of OOP, which more than compensate for all the disadvantages. I bet that none of those who criticize OOP here took part in writing a single project, even a small complex one. Which explains their opinion.
Like "the car requires a lot of overhead resources, and you can't get away from them, you have to carry that pile of scrap metal around all the time, which means it's much more correct to walk". And indeed, it is quite silly to go to the next street. However, if you have to go to another town - very few people talk seriously about "walking".
And so it is here.
Not necessarily.
Renat on the previous page - quite rightly noted that "put him to do a real project" - he will fail it. And he will quickly become convinced of all the advantages of OOP, which more than compensate for all the disadvantages. I bet that none of those who criticize OOP here took part in writing a single project, even a small complex one. Which explains their opinion.
Like "the car requires a lot of overhead resources, and you can't get away from them, you have to carry that pile of scrap metal around all the time, which means it's much more correct to walk". And indeed, it is quite silly to go to the next street. However, if you have to go to another town - very few people talk seriously about "walking".
And so it is here.
Now for micro-projects of up to a hundred thousand lines. This allows you to create anything, as it has a chance to fit in one person's head and maintain the illusion of control. When you try to scale it up - pain, frustration and death.
I can hardly imagine even a 10K line project without OOP. There are probably very few of them.
The uncle is a theorist and blabbermouth, like most in academia. And it does not matter that he is a professor (the title has long been inflected) and author of books.
This rubbish from phrases has been walking around for a long time and completely ignores the exponential growth of complexity of software products. What was 30-20-10 years ago is in no way comparable to the scale and complexity of current projects. And they still prefer to play in the sandbox, reducing it to models.
Sit him down to make a real product, which has a lot of requirements, including resource, economic and competitive ones. He will instantly flip out with his reasoning, failing in every way he can. More likely to even get kicked out for childish captaincy at the solution design stage.
The world has tried many silver bullets, but they have all proved worthless and have long since been written off. That leaves a constant growth of complexity, growth of libraries (and there's an oop) and frameshots (and there's an oop), which allow at least some control over complexity.
And there's no getting away from the growing complexity. There will be even more complexity, there will be more illiterate developers unable to keep up with knowledge quality requirements.
There will be more attempts to come up with even simpler languages to meet the ever decreasing mass level of programmers. More and more software companies will find themselves at a disadvantage by simply believing in the wrong technology and losing the competitive race. It's just that their competitors will use technology that is heavier, but effective in terms of product results.
Investing in software companies has long been a deadly thing. Mortality and failure rates are staggering, and it's going to get worse from here.
Why? Yes because it's a business with masses of economic demands, not tech. About 80% of a live and standing software company consists of marketing and sales. The wrong technology (and here most people prioritize supposed simplicity) easily kills future sales. Because there are always competitors who took a harder path and got better results in the end.
Now about micro-projects up to a hundred thousand lines. This allows you to create anything, as it has a chance to fit in one person's head and maintain the illusion of control. If you try to scale it up - pain, frustration and death.
Conclusions:
All this is good and beautiful only in words....
To create large and interesting projects using OOP it is necessary to know how to do it.
1 - Those who know how don't go here to µl, the language is limited to a couple of platforms, and they are pros (already with projects in other languages) already in business...
2 - And those who don't know how, they will twist OOP and other like monkeys and will not give birth to anything...
Yes, of course, there are a few fans of financial markets, but too few to do something serious and make a life for themselves... The main interest is...
What I mean is, Renat, mt 5 will soon be 10 years old, 10 years is no joke...
And there is no proper training in OOP programming...
What's the topic I wrote about? About OOP and what did it come down to? Into rubbish...
My question to you Renat, how or where should people who program large projects in mkl appear ???
how or where should people programming large projects in µl come from ???
There have never been and never will be big projects in algotrading within a single trading floor, regardless of language and platform.
At most, there are semi-automated projects.
Even one big project as a semi-automatic in any language? Scalper drives are the hardest. But they've never had mass appeal. And if there is no mass, why bother with something big? It's easier to build something for Market on one knee.