![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Of course, it's easier to parse code knowing the schematic than not knowing the schematic.
Technically it would even be convenient to have some kind of code visualizer... especially if one does not cancel the other but supplements it.
Of course, it's easier to parse code knowing the schematic than not knowing the schematic.
Technically it would even be convenient to have some kind of code visualizer... especially if one doesn't cancel the other but supplements it.
But why not make a full-fledged code visualizer which would be self-sufficient?
invent a graphical language for code representation, think over a good navigation in it, decide the priority of the information to be displayed (the more important information requires less efforts to display it, the less important on the contrary). You also need a thorough analysis of the code.
It will not be easy for sure. OK, I know that it's unlikely that it will come to implementation...
Why not make a full-fledged code visualizer that is self-sufficient?
Think of a graphical language for code representation, think of a good navigation in it, decide on the priority of the information displayed (more significant information requires less effort to display it, less significant - on the contrary). You also need a thorough analysis of the code.
It will not be easy for sure. OK, I know that it's unlikely that it will come to implementation...
Why not make a full-fledged code visualizer that is self-sufficient?
Think of a graphical language for code representation, think of a good navigation in it, decide on the priority of the information displayed (more significant information requires less effort to display it, less significant - on the contrary). You also need a thorough analysis of the code.
It will not be easy for sure. Ok, I know that it's unlikely that it will come to implementation...
With the possibility of creating my own settings with my own code and visual design, and using ready-made visual design templates of others, it's called laziness to write a couple of lines)))
In programming, my first place to use is probably reloading functions. But in the code everything is very brief anyway, write the new name, write where we inherit from (and usually it's a template), write what and what we replace it with. That's all!
I think these quirks will quickly grow into a huge library and it will be hard to remember them all.
Yes, but its direction is correct. Coding is a narrow channel for harnessing the potential of the brain. The pattern described by the code is understood hundreds of times longer than the same pattern perceived by the eyes. Imagine the rotation of a volley which on each circle slows down and increases the angle of inclination slightly. Describe this process with formulas in code and film it on a camera. Measure the time it takes the programmer to realise that this is the same thing.
Everyone has their own approaches. Personally, I find diagrams only slightly annoying) I much more like the approach of literary programming by Donald Knuth (translated in Russian as "literate" for some reason) and the way it is implemented, for example, in R language (R Markdown).
You are wrong to write about a spinner) It is an unsolved mechanics problem - there is no general formula for motion (even if you neglect friction).
You're wrong to write about a spinner) It's an unsolved mechanics problem - there's no general formula for motion (even if you ignore friction).
And the Celtic stone is also a volute )
...
You're wrong to write about a spinner) It's an unsolved mechanics problem - there's no general formula for motion (even if you neglect friction).
Somehow I didn't think about it. )
There are software programs such as 3D design for oil refineries. They have a diagram of piping connections. It is easier for an experienced process engineer to read a pile of drawings than a single "visual" diagram, then they get used to it. I mean the complicated code will still be difficult to comprehend in case of visualization. If you follow all the rules, the code is quite easy to read in its original form.
You wonder why the two code displays below are perceived differently:
Next, remove the graphic 'tinsel'. Minus the colour, minus the indentation (relative positioning).
The readability is noticeably worse. This suggests that graphical representation can noticeably improve readability. I'm not talking specifically about diagrams, there could be many options.