Errors, bugs, questions - page 2637

 
Andrei Trukhanovich:

maybe compared to functional programming?

Check out the wikipedia:

And we find out that it's not the same thing.


So it's all procedural...

 
Nikolai Semko:

I may surprise you, but today's young programmers consider OOP to be easier programming than procedural programming.

You are thinking in terms of 25 years ago. Today's youth absorb OOP with the milk of their mother. Learn OOP if you want to be in the trend otherwise you will do nothing but grumble.

But it is really so. Let old programmers try to solve Olympiad tasks for schoolchildren.

What they studied earlier at universities, such subjects as dynamic programming, graph theory, OOP, classes etc. Present-day schoolchildren of 9-10 classes (not all of course) solve such problems in a few minutes.

And it is natural. Law of nature :)

 
Roman:

Yes, I understand OOP, not to the extent I would like to, of course.
This is not a grumble but a constructive suggestion.
So that the developer doesn't have to write one function to allocate two mallocs, they force users to learn OOP.
Of course, it is that progress and popularization of the language. Well, you can see how much they love and understand OOP here.
You see, Nikolay, everything in the wrapper is unnecessary code to be executed, I don't think we need to explain.
I don't need to tell you about modern optimizing compilers - we don't know what instructions they will apply.
Perhaps I will also surprise you that even American programmers prefer to write in the procedural style not because OOP is bad, but because code is simpler and faster.
And
if there are no object tasks in the project, why use wrappers, which must somehow be understood, for young people))
That's why I don't agree with you that young people eagerly absorb OOP.

I'm thinking in C, which is where the logic of the mql language is built on.
C was born in 1972, so it's 48 years old ))
But anyway, C is one of the fastest languages. Do you know why? Because it doesn't have class wrappers.

Well, that's not true at all. It's just that there are still many languages in use without OOP. C, for example. In Canada, for example, most of the governmental institutions are sitting on Kobol and can't get rid of it.

https://www.tiobe.com/tiobe-index/

Roman, I honestly don't understand why you're making a fuss about changing matrix dimensions - what difficulties can there be with that.
You don't need pointers or OOP for that.
Anyway, for a computer, an array of any dimension is a one-dimensional array.
So, work with a one-dimensional dynamic array. And form matrices virtually and resize them as you wish with the help of functions.
For example something like:

double GetValFromMx(double &A, int x, int y, int SizeX, int SizeY) {
if (x<SizeX && y<SizeY) return A[y*SizeX+x];
else return EMPTY_VALUE; }

In practice I use only one-dimensional arrays in my code, though I also deal with multidimensional arrays on the basis of one-dimensional ones.

 
Roman:

That's why I'd like to ask you to make functions like ArrayResize only for matrices ArrayResizeMx(A, n, m)

all done, don't want ready-made solutions using OOP (you are not required to know OOP, use ready-made!)

use ALGLIB , there is a method to resize matrix Resize().... but still everything is done by OOP ))))

SZS: search through the forum, there were many times on this topic, there were examples, you can wrap a structure with an array field in an array of these structures - it will be without OOP, but to me it all looks cumbersome

Roman:

I'm thinking in C, which is the basis of mql logic.

The C language was born in 1972, so it turns out that it's 48 years old ))
But anyway, C is one of the fastest languages. Do you know why? Because it doesn't have class wrappers.

I don't remember pure C, I studied it at uni long ago, but if I'm not mistaken, C didn't have dynamic arrays as such, but you could work with pointers to memory, and the work on memory allocation and memory access control was fully on the programmer, which is essentially the same wrapper

OK, this could be a great argument, there's no point in continuing.

 
Nikolai Semko:

Roman, I honestly don't understand why you made a fuss about changing matrix dimensions - what difficulties can there be with it.
You don't need pointers or OOP for that.
Anyway, for a computer, an array of any dimension is a one-dimensional array.
So, work with a one-dimensional dynamic array. In the meantime, form matrices virtually and resize them as you wish using functions.

It's clear that any dimension is a one-dimensional array for computer.
It's all about language usability. If we see the [][] dimension in the code, we can visually understand that it is a matrix, not a one-dimensional array.
The code's readability is much higher than guessing what [][] contains.
I had never thought that I would meet such a lack of understanding when asked to add one function on memory allocation for matrices.
All of you are using ArrayResize, it's convenient and you don't bother with it. What problem is it for a developer to write a memory allocation function fora multidimensional array?
That's right, there are no problems and no obstacles, and for users it is convenient to organize code. So I decided to port a big good C library of numerical methods to mql,
but I don't have any normal mql tools for that. Once again there are crutches, which removes all desire to build inefficient code.

 
Roman:

I do understand OOP, not as much as I'd like, of course.
This is not a grumble but a constructive suggestion.
So that the developer does not have to write one function to allocate two mallocs, they force users to learn OOP.
Of course, it is that progress and popularization of the language. Well, you can see how much they love and understand OOP here.
You see, Nikolay, everything in the wrapper is unnecessary code to be executed, I don't think we need to explain.
I don't need to tell you about modern optimizing compilers - we don't know what instructions they will apply.
Perhaps I will also surprise you that even American programmers prefer to write in the procedural style not because OOP is bad, but because code is simpler and faster.
And if there are no object tasks in the project, why use wrappers, which must somehow be understood, for young people))
That's why I don't agree with you that young people eagerly absorb OOP.

I'm thinking in C, which is where the logic of the mql language is built on.
C was born in 1972, so it's 48 years old ))
But anyway, C is one of the fastest languages. Do you know why? Because it doesn't have class wrappers.

MQL is built in C++.

Roman, in order to introduce these features that you mention, MQL will have to introduce many additional things in terms of working with memory. And this is a complication for beginners.

You yourself said that it must be easier for non-professionals.

It is a situation like "I am good at learning to pedal on a bicycle, it is so simple and understandable. Let's put pedals in the BMW, it'll be easier." :)

s.e. I'm generally of the opinion that both procedural and OOP styles are lame and impractical))

 
Igor Makanu:

all done, don't want ready-made solutions using OOP (you are not required to know OOP, use ready-made!)

use ALGLIB , there is a method to resize matrix Resize().... but still it's all done with OOP ))))

SZS: search through the forum, there were many times on this topic, there were examples, you can wrap a structure with an array field in an array of these structures - it will be without OOP, but to me it all looks cumbersome

The problem is that you can't remember pure C, I studied it at uni, but if I'm not mistaken, C didn't have dynamic arrays as such, but you could work with pointers to memory, and the work of allocating memory and controlling memory access was completely up to the programmer, which would be a wrapper for the programmer

OK, this might become a great argument and there is no point in continuing

Tried ALGLIB, there is a problem with printing from object, ArrayPrint function does not print objects.
But from [][] prints a nice matrix, even with headers, again, it's easy to see when you need to visually track the result of the calculation.
Yes, I've looked at some topics on the forum, but I'm not impressed. That's why everything looks cumbersome and inefficient. C is a very elegant language and mql tends to corrupt it.
Yes, C can allocate memory for dynamic matrices through pointers, but in mql there are no pointers to variables, so again we have to pass to objects.
When users only need one function ArrayResizeMx(A, n, m, k) and it will be in the native implementation, you understand the difference.
Well, there's no sense in continuing, if they have heard about it and will do it, thank you very much. But the function is really useful and necessary.

 
Roman:

Speculation out loud, but it's more of an appeal to the developer.
For this Zloy, do not take it personally.

So, the dynamic matrices can only be handled through objects or structures. Another crutch is created in general.
There are no pointers to variable in mql, so we have to use the object approach where pointers are available.
So, to use dynamic matrices, a user must know OOP and working with pointers, and moreover, in MQL execution.
How many of them have this knowledge? You know the answer yourself. I don't have any difficulties in understanding the object approach, but for those who don't know OOP
. They create an artificial threshold for using the language, in particular when dealing with dynamic matrices.
As I see it, a developer, on the contrary, should be interested in making the language easier to use, rather than complicating it.
In other words, they should develop such functions which are necessary to the user for comfortable work with the language.
And all the more so with matrices, which are almost the basis of numerical methods.

For this reason, I would like to ask you to create functions similar to ArrayResize only for matrices ArrayResizeMx(A, n, m),
and perhaps for multidimensional ones as well. In other words, give the possibility to work with matrices not as with objects, but as with customary arrays in the C style.
Especially for visual representation of matrices, the ArrayPrint(A, 0) function prints matrices from arrays, not from objects.

The developers have been quite specific about this. Here

Респект и уважуха создателям языка, Но...
Респект и уважуха создателям языка, Но...
  • 2010.05.15
  • www.mql5.com
Добавление ООП потребовало от создателей языка изменения синтаксиса, для введения классов и структур и много-го чего.
 
Koldun Zloy:

The developers have been quite specific about this. Here

No need to go far, the next post, with specific questions from Prival,
I've known him for a long time since about the same time, a competent military developer, and what, why he left here, the answer is obvious.
It's been ten years, has anything changed?
As it was filled with simple algorithms, it has remained at that level. Where are the professional solutions?
But we're writing more to python than to give tools to write these professional solutions and to develop our kodobase.
That's where the mistake is, there are no tools, no proper level of programmers.
Ok, I'm going to sleep now, I haven't slept yet. Good luck to everyone.

Респект и уважуха создателям языка, Но...
Респект и уважуха создателям языка, Но...
  • 2010.05.15
  • www.mql5.com
Добавление ООП потребовало от создателей языка изменения синтаксиса, для введения классов и структур и много-го чего.
 
Nikolai Semko:

So it's all procedural...

Procedural is B, it's all elementary there, just more opportunities to shoot yourself in the foot.

I think you got it wrong and meant functional. It doesn't matter, though.

Reason: