Questions on OOP in MQL5 - page 25
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
There are detailed statistics here https://githut.info/, but it's the year 14.
Fresh statistics on github https://madnight.github.io/githut/#/pull_requests/2019/2
I think everyone would benefit from reading the professional opinion in this article.
Good luck
I think everyone would benefit from reading the professional opinion in this article.
all the (totally biased) conclusions of the article are offset by one simple question.
FP has existed for a long time, why does it still have such a small niche if it is so awesome?
I don't mean by any means that OOP is the best concept or OP sucks.
all the (totally biased) conclusions of the article are leveled by one simple question.
FP has been around for a long time, why does it still have such a small niche if it is so awesome?
The article has the answer to that question. You haven't read it carefully.
The article has an answer to this question.
Totally biased and about nothing.
There are developers who actually write the code. There are managers who may not know how to program at all.
So the technology stack is not necessarily chosen by the developers. And if a certain stack allows a team to solve a problem more efficiently, you don't have to know and possess the technology to understand it.
Do you still think the article answers the question?
I think everyone would benefit from reading the professional opinion in this article.
Good luck
Here's the usual. Extreme points of view. It's like an argument about what is better - a hammer or a sledgehammer.
You won't write good tools in C# but in pure C you will get tired of describing and debugging ramified logical chains in a serious application.
So this article is of no use.
That's the way it always is. Extreme points of view. It's like an argument about what is better - a hammer or a sledgehammer.
You won't write good tools in C# but in pure C you will get tired of describing and debugging ramified logical chains in a serious application.
So this article is about nothing.
There is, of course, some truth in the article... at least, that inheritance will "pull" methods and fields that are not really needed, but alas, you have to pay for everything - it saves time but it may increase memory usage or overall performance of a solution, but five not all so sad, the level of compilers and code optimization is very steep now, so the output often results in a good solution for a short development time
about C#, well, as if the purpose it has others, it is purely a "Windows language" to quickly get results on a particular PC or a limited group of PCs, even if not installed updates .Net can cause critical errors on PCs that do not have access, and catch this is quite expensive - wrote a panel for trading in C# already checked it on a virtual machine, if not installed all the "patch" in the updates, the project can not predictably bounce ;) Of course, you can try to write for the most junior version of .Net, but there is a problem - all the news on GitHub posted under the new .Net builds - i.e., you will be limited only to their developments
In general, as elsewhere - innovation is "painful and long and sad", you have to follow trends set by the IT giants, then everything is written quickly and without problems, well Microsoft wrote all they could in OOP style, you have to use it all or will write from scratch all their WinForm, etc. thousands of tons and terabytes of code written since Win-95)))
there's certainly a bit of truth in the article...
A little? ) Actually it's just the way it is. However, the author doesn't reveal the truth, it's kind of obvious things (at least for me). I thought any programmer with experience comes to the same realization of the problems of changing state. By the way, I've recently seen a very similar article but shorter. But, perhaps, it is the eternal debate between functionalists and open source programmers )
But in fact no one prevents you from using OOP correctly. Even the author himself mentions that you can use immutable objects. And 99% of the described problems disappear at once. So it all depends only on the question of straight hands and head on shoulders, not the paradigm being used.
Although, of course, the fact that popular OOP languages do not provide the means to control object variability, complicates the process. So, it would be really cool to have the keywordimmutable instead of const/readonly.
As for reasons of unpopularity of functional languages, I don't agree with the author here. First of all, it is more complicated perception of such code, as it seems to me. This is not just an opposition of OOP and FP, but an opposition of imperative and functional approaches. The former is more close and intuitive for most people to understand, in my opinion. I am only acquainted with functional languages through correspondence, so I cannot judge them objectively, but when, for example, I see code overloaded with lambda, it causes cognitive dissonance) It's too complicated and intricate. And probably most people think so too )
And besides functional languages are not intended for a number of tasks connected with interaction with external environment. Take the GUI for instance. When in one way or another you need to store the globally changed state between events.
A little? ) Actually, that is exactly the case. However, the author is not revealing the Americas, these things are kind of obvious (at least to me). I thought any programmer with experience comes to the same realization of problems of a changeable state. By the way, I've recently seen a very similar article but shorter. But, perhaps, it is the eternal debate between functionalists and open source programmers )
But in fact no one prevents you from using OOP correctly. Even the author mentions that you can use immutable objects. And 99% of the described problems immediately disappear. So it all depends only on the question of straight hands and head on shoulders, but not on the paradigm used.
Although, of course, the fact that popular OOP languages do not provide a means to control the variability of objects, complicates the process. It would be cool to have the keyword immutable instead of const/readonly.
In any case nothing will change in the near future, IT-giants support this paradigm, it may be beneficial to force software developers to make complex implementations which will require more powerful hardware to work, as well as to present their documentation for OS or compilers with ready-made libraries in the form of OOP, which forces developers .... and so on to infinity ;)
We can consider this OOP story as obligatory knowledge of Latin by medics - it was not necessary, but as the means of communication at the professional level it was necessary to use ;)