Self-learning the MQL5 language from scratch - page 17
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 exact opposite of you!
The most important thing in programming is to know the language at the lowest level possible!
For beginners, a low level is the syntax of the language without additional code wrappers.
What about decomposition, as you put it, is an understanding of how flowcharts are composed.
That's why a programmer is valued not by philosophical fantasies, but by practical knowledge of the language.
How can you fantasize without the basics of the language? Where is the simple logic?
Equivalent to the language of an electronics engineer, which is the author of this thread, firstly supply voltages to the board, and then wonder why the board burned out ))
I disagree. When you set a goal, you don't need to know the language, you just need to understand its capabilities. But when setting a goal, solving it, selecting algorithms and coding, at all these stages it is necessary. Setting a problem without knowing the syntax of the language is sometimes a big problem in implementation)))
... Equivalent, in electronic language, which is the author of this thread, first apply voltages to the board, and then wonder why the board burned out ))
Hello Roman! Great comparison. Now I'm in programming at the same level of electronics engineer, when I went from knowing the principles of transistors to learning the principles of digital circuits K155.
Although, many of my colleagues in 1983 managed to repair computers from the EU series without any understanding of how transistors worked. It was enough for them to know the algebra of logic. It was a digression - nostalgia for the Soviet times!
Regards, Vladimir.
I disagree. When setting a goal, knowledge of the language is not necessary, you need an understanding of its capabilities. But in problem setting, problem solving, algorithm selection and coding, all these stages are necessary. Setting a problem without knowing the syntax of the language is sometimes a big problem in implementation)))
So how will you understand the possibilities if you don't know these possibilities ))
Problem definition, is the extreme stage of mastering the basics of the language, when you already understand what a variable is, what sizes it can be, scope, etc.
I was also at a crossroads, when I didn't know where to start, what language to learn and understand everything. It was agony, because I tried several languages to find the truth.
But when I finally realized that mql was a C-like language, I started to learn C as a goal-oriented way, starting from the basics.
And when I've finished basic studying it, I was surprised to find out that I practically know mql already, and everything is clear to me, only syntax and specifics should be improved by docks, it is a feature of mql.
Having understood the procedural approach of programming, I began to get into OOP after a year. For a long time, it was not clear to me, because of other names of the same thing.
For example, method and function, what is the difference )) variable and class member )) etc.
But to get there, you need to understand the very basis of procedural approach, and when you start to gradually understand the OOP terminology, the understanding opens instantly.
That's the difference, the choice of the initial learning path. How can you write in Russian without knowing letters and punctuation marks?
Remember where you started, with hooks and sticks.
The exact opposite of you!
The determining factor in programming is knowledge of the language, at as low a level as possible!
What does it get you? You know the language at an ultra-low level. You know what assembler commands are replaced with if, how the for loop is converted into goto. You know assembler. Where's the profit in that? Look at Python programmers. They don't know any of this. But they are very good at handling functions, they know how to Map/Reduce. They are able to compose them and input them to each other. And where is MQL now that they're not writing so much in it compared to Python?
How can you fancy without the basics of the language? Where is the simple logic?
It's similar to the electronic language, which is the author of this thread, firstly to supply voltages to the board, and then wonder why the board burned out ))
In your understanding of simple logic, it's an over-the-counter procedure. The way I see it, it's like assembly language: "what I see is what I sing about". There's no logic there, it's just dumb typing skills. A typist can do it after a two-week training course. That's not programming.
As far as decomposition is concerned, as you put it, it is understanding how flowcharts are made up.
And what would be the benefit of such knowledge? You know the language at an ultra-low level. You know what assembler commands replace if, how the for loop is converted to goto. You know assembler. Where's the profit in that? Look at Python programmers. They don't know any of this. But they are very good at handling functions, they know how to Map/Reduce. They are able to compose them and input them to each other. And where is MQL nowadays where they write not so much as in Python?
In your understanding of simple logic, it's a terribly procedural thing. In my understanding of logic it's like in assembler: "what I see, that I sing about". There's no logic there, it's just dumb typing skills. A typist can do it after a two-week training course. It's not programming.
A flowchart is a diagram for procedural JDs. "Here's the for loop, here's the if loop". They don't write in procedural languages nowadays. This is nonsense for a user application to choose, for example, C or Pascal. For an OS core or some other procedural language it is the best. But it is a vanishingly small percentage of tasks and is clearly outside the scope of the task at hand.And what would that knowledge achieve? You know the language at an ultra-low level. You know what assembler commands replace if, how a for loop is converted to goto. You know assembler. Where's the profit in that? Look at Python programmers. They don't know any of this. But they are very good at handling functions, they know how to Map/Reduce. They are able to compose them and input them to each other. And where is MQL nowadays where they write not so much as in Python?
In your understanding of simple logic, it's a terribly procedural thing. In my understanding of logic it's like in assembler: "what I see, that I sing about". There's no logic there, it's just dumb typing skills. A typist can do it after a two-week training course. It's not programming.
A flowchart is a schema for procedural languages. "Here's the for loop, here's the if loop". No one writes in procedural languages these days. This is nonsense for a user application to choose, for example, C or Pascal. For an OS kernel or some other procedural language it is the best. But this is a vanishingly small percentage of tasks and is clearly not within the scope of the task at hand.For your enlightenment, Python is written in C.
And Python was designed to make writing code easier. But having turned into a popular language because of its seeming simplicity, coders' knowledge remains at the level of Python.
And only programmers who know C write libraries and additional stuff to it. These are programmers and not coders.
That's the point that a simple code typist will beat coders with her understanding of the subject.
You are just a C#-nik, that's why you have such a look, but don't even think in what language this C# language is written))
So how do you understand the features if you don't know the features ))
Problem setting is the extreme stage of mastering the basics of a language, when you already understand what a variable is, what sizes it can be, scopes, etc.
I was also at a crossroads, when I didn't know where to start, what language to learn and understand everything. It was agony, because I tried several languages to find the truth.
But when I finally realized that mql was a C-like language, I started to learn C as a goal-oriented way, starting from the basics.
And when I've finished basic studying it, I was surprised to find out that I practically know mql already, and everything is clear to me, only syntax and specifics should be improved by docks, it is a feature of mql.
Having understood the procedural approach of programming, I began to get into OOP after a year. For a long time, it was not clear to me, because of other names of the same thing.
For example, method and function, what is the difference )) variable and class member )) etc.
But to get there, you need to understand the very basis of procedural approach, and when you start to gradually understand the OOP terminology, the understanding opens instantly.
That's the difference, the choice of the initial learning path. How can you write in Russian without knowing letters and punctuation marks?
Think back to where you started, with hooks and sticks.
I don't know what to say. Everyone has their own way, I guess. I don't insist. But goals can be solved in different languages, and one may not know the syntax when choosing a goal, but only the possibilities. There are libraries for websites in python, and the site can be done in python, pxp, jumla, html or any other, it is a question of price and availability of ready functionality (scripts), and this is a problem statement and requires deeper knowledge of the language. We can select the following scripts to work with series: MKL, Python, R and Matlab. The native MCL will be enough for setting orders by MAs.
Everything just has to be in harmony. Knowing the mechanics of the car is not the same as driving it well. But not knowing the mechanism is bad for breakdowns on the road.)
And to each his own, often a good coder is not a good algorithmist and vice versa. If these qualities are good together, it's cool and expensive usually, but not so often.))))
And what would be the benefit of such knowledge? You know the language at an ultra-low level. You know what assembler commands replace if, how the for loop is converted to goto. You know assembler. Where's the profit in that? Look at Python programmers. They don't know any of this. But they are very good at handling functions, they know how to Map/Reduce. They are able to compose them and input them to each other. And where is MQL nowadays where they write not so much as in Python?
In your understanding of simple logic, it's a terribly procedural thing. In my understanding of logic it's like in assembler: "what I see, that I sing about". There's no logic there, it's just dumb typing skills. A typist can do it after a two-week training course. It's not programming.
A flowchart is a flowchart for procedural languages. "Here's the for loop, here's the if loop". No one writes in procedural languages these days. This is nonsense for a user application to choose, for example, C or Pascal. For an OS core or some other procedural language it is the best. But this is a vanishingly small percentage of tasks and is clearly not within the scope of the task at hand.It's a lot, it's the right way of doing things. Ideally, the customer should be a good coder))) How much nerve would be saved)))
Knowing a language at a low level does not invalidate knowledge of high-level languages, and just gives a deeper understanding of how the program works. And if he knows how go-to loops work and how much memory they consume, he can optimize them if necessary. No more than that.
To be honest, I don't understand the point of the argument.
...
And frankly I don't understand the point of the argument.