Talking about the PLO in the lounge - page 20
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
The article lies!
I didn't read the rest of the article. Most likely the author's nonsense was immediately pointed out in the comments.Read on, it's all on point.
In procedural coding, it is almost always possible to customize the architecture of a program as you write it. Because the flexibility and freedom is complete
+
You may forget about OOP just for the sake of it, especially for computational algorithms, like in trading...
On the myths of the PLO - not for the faint-hearted PLO adherents.
"There have been several myths about OOP since the mid-1980s. One of them, the Myth of Reuse, says that OOP makes development more productive because it allows you to inherit and extend current code instead of having to write it all over again. The other is the Myth of Design, which implies that analysis, design and implementation follow smoothly from each other, because they are all objects. Of course, none of these myths can be the OOP paradigm."
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:
Forum on trading, automated trading systems and strategy testing
Talking about PLO
Renat Fatkhullin, 2018.01.17 09:17
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 inflated) and an author of books.
This rubbish made of phrases has been circulating for a long time and completely ignores the exponential growth of software complexity. 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:
Best post of the month, or maybe of the year! Renat, why don't you or your company write articles on hubra(the company is not even registered there!)? You have so much to say, but your experience is only learned in snippets from your posts. Seriously, very topical and accurate. To illustrate your post:https://habrahabr.ru/post/344356/
Best post of the month, maybe of the year!
What did you like so much about this post in the context of the OOP topic? It's probably not quite right to generalize about commercial things too, investors are not fools and involve their experts to assess the risk of projects...
This article by some, but still a professor has specific logical arguments to which no adequate counterarguments have been presented for discussion...
It is also clear that simple pogramming is not always an evil for projects...
Best post of the month, maybe of the year! Renat, why don't you or your company write articles on hubra(the company is not even registered there!)? You have so much to say, but your experience is only learned in snippets from your posts. Seriously, very topical and accurate. As an illustration to the post:https://habrahabr.ru/post/344356/
We work for millions, not the 1,000 - 5,000 readers/views that articles on Habra usually get.
We've made an industry standard and are releasing solutions that impact the world. Why do we need some kind of Habr, and even more so, squeezed into a narrow niche of the Russian segment.
What did you like so much about this post in the context of OOP topic? It's probably not quite right to generalize about commercial things too, investors are not fools and involve their experts to assess the risk of projects...
There are specific logical arguments in this article by some, but still a professor, to which no adequate counter-arguments have been presented for discussion...
It is also obvious that simple pogramming is not always an evil for projects...
Stop with the dilettantish jibes, please.
You will simply be banned for being technically illiterate. We don't need belligerent ignoramuses in our forum.
...
It is also obvious that simplicity of programming is not always an evil for projects...
There is an axiom: complexity does not go anywhere. Consequently, "simplicity of programming" for the user is a transfer of complexity to the compiler. The complexity is as though processed by the compiler behind the scenes and it, the compiler, tries to hide any perversion of the programmer according to the principle "better let it work somehow than nothing at all". The compiler, not the programmer, becomes the owner of the project. Development and maintenance of the code becomes impossible, because you don't understand what's going on (the compiler builds it somehow, but whatever).
Forum on trading, automated trading systems and strategy testing
Talking about OOP
Renat Fatkhullin, 2018.01.17 09:17
...
And there is no getting away from the growing complexity. There will be even more complexity, there will be more illiterate developers unable to keep up with the knowledge quality requirements.
There will be more attempts to come up with even simpler languages to meet the ever lowering mass level of programmers. More and more software companies will be at a disadvantage, simply by believing in the wrong technology and losing the competitive race. It's just that their competitors will use technology that is heavier, but more effective in terms of product results
...
Stop with the dilettantish jibes, please.
You will simply be banned for being technically illiterate. We don't need belligerent ignoramuses in our forum.