Will OOP be in demand in MQL5? - page 2

 
Svinozavr >> :

What are you interested in, the process or the end result?)

I'm interested in both, but the end result is somehow more. ("... OOP gives you many ways to slow down your programs...")

I don't see where OOP would allow me to write faster than with a procedural approach, and that would outweigh all the disadvantages of OOP. It's clear who needs it - the developer who writes for others.


Let me give you an analogy: the first took a knife and carved a filigree figure, while the second took off half his finger with the same knife. What is the point of this? Any tool can be used to create both a "sweetie" and a total bum. It all depends on the programmer, whether he is a craftsman or has a spark of talent. This is a digression, but in essence - if you prefer FOP, then use it further.

 

In creating the subj, I wanted to see arguments in favour of OOP in projects for MT purposes. Maybe due to my ignorance - I'm not being flirtatious - I didn't see them. I don't see them now either.

Let me summarise your posts (thank you all, by the way):

1. Convenience and speed of project implementation.

That's how big a project would have to be to feel that convenience? Show me something that was created for 4 that would be more convenient to do with OOP. No answer.

2. Maintenance, upgrades.

Again - the size of the project.

3. 5 is faster because who cares how to program.

Well, that's not an argument at all. No comment.

3. Handedness as a reason for slower OOP.

Yep. I usually write programs by my hands but if I want to use OOP, I turn my back to the computer. ))) No. OOP will be slower than a procedural one in terms of algorithm.

------------

(shrugging) Understand that I'm not against OOP, I just wanted to find out for myself what it may give me in tasks for MT - in creating of indices, scripts, Expert Advisors.

OK. There is a help on the 5th. Who may give an example of a simple indirect from MT4 standard written using OOP on 5? You will be able to see there. You can also estimate delays by eye from the text, readability of the program, etc.

 
Svinozavr писал(а) >>

1. The convenience and speed of the project.

How big would a project have to be to feel this convenience? Show me something that was created for 4 that would be more convenient to do with OOP. No answer.

2. Maintenance, upgrades.

Again - the size of the project.

1. OOP is very convenient for those who understand the basic principles. You can feel it even in the simplest applications. Any application is more convenient to make with OOP.

2. The size of a project is not a hindrance as long as it is not difficult to understand it. And if a programme is object-oriented, it is not very difficult to understand it. An example is SaxoBank terminal. It is written in C#, which is an object-oriented language. Each dll contains about 20 000 lines of code. If it weren't for OOP it would be almost impossible to understand such an amount of information, all the more so to modernize it.

 
The problem in 5 is not with OOP. It is still unclear how to implement large prereqts from those implemented in 4. The work with graphical objects is made "cancerously". The developers have promised to improve it, but... ... no improvement has been felt so far. It became possible to program toys.
 
Svinozavr писал(а) >>

How big of a project does one have to be to feel this convenience? Show me something that was created for 4 that would be more convenient to do with OOP. No answer.

Probably nen's ZUP would be a good example. There's a lot of tricky stuff in there. The sheer mass of the source code alone inspires respect (368Kb v82), not to mention the content.
 
In 5, no one has abolished procedural programming. If you don't like OOP, write programs the old way. But they have created a huge problem with graphical indicators. They will be very difficult to implement. And for programmers. And for those who manually trade using the graph indicators. Ordinary traders - not programmers - will have to retrain. And not everyone will be able to do it properly.
 
It seems that MQ believes that there is only trading with automated robots. And the 5 is geared precisely towards robots. They have decided to eliminate manual trading as a class.
 

They no longer have OOP at their core (although absolute OOP is practically unusable). We should have created abstract classes from the beginning and used inheritance and polymorphism to reach real objects. For example, to create an abstract base class for custom indicators with abstract methods and properties. It is better to build a hierarchical tree of classes: a tree for graphical objects, for working with the account, for schedules and access to time-series, etc. And the predefined procedures and functions should be left only with the elementary routines that require speed. Then you could expand the capabilities of the platform from any level of abstraction, which would reduce the code size, improve its readability and ease of understanding for other programmers. And in MT5 already implemented quite complex things at procedure level (in fact the whole platform is ready to use) and I haven't seen the possibility of access by pointers at least to descriptors of created internal structures, which is very limiting (judging by the help). In general, the need for OOP is questionable, with such an implementation we could be limited to structures and dynamic placement. OOP should be supported from below by an extensive class hierarchy .

 

It takes 1-3 years of programming to realise that programs are NOT WRITING, but READING.

It takes another 1-2 years to realize that programs are written not for a computer, but for a human (in particular, for oneself).

Then it takes 1-2 years to notice that OOP and C++ contradict the humanoid way of thinking and method of building human languages.

It takes another 1-2 years to study other people's code and realize that the best and most reliable programs are written in classical Ce.

Well after that it's enough to read Dijkstra's interview about C++ and OOP giving him stomach pains.

And after that (4-9 years in total) questions "about OOP" do not arise at all, and such discussions cause only an indulgent smile.

 
AlexEro >> :

And after that (4-9 years in total) there are no questions at all "about OOP", and such discussions only evoke a condescending smile.

>> I sympathise.