Sunset programming? - page 17

[Реter Konow]

Alexandr Andreev:

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.

I agree.

[Konstantin Nikitin]

So we have come to the conclusion that although a horse works harder in a collective farm, it is of no use without a good groom.

[Alexandr Andreev]

But you have to work out the usability of it all very well. And understand what is most often needed. I.e. it makes no sense to show the whole mess of all the interrelations, because there can be 20 inheritance (in depth) of the object with many attachments, reloads. But to see where this object is mentioned in the parent structures or where it is initialized if we have an external detailed initialization of the object in the code under analysis. Or quickly create a new intermediate entity with reloading of certain functions and understand that you didn't make mistakes in the parent ones. Although usually this task is handled by search or compiler

[Aliaksandr Hryshyn]

Alexandr Andreev:

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...

[Aleksey Mavrin]

Aliaksandr Hryshyn:

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...

There are programs such as 3D design for oil refineries. They have a diagram of piping connections. For experienced process engineers, it is easier to read a pile of drawings than a single "visual" diagram, but they get used to it after a while. 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.

[Alexandr Andreev]

Aliaksandr Hryshyn:

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.

[Aleksey Nikolayev]

Реter Konow:
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).

[TheXpert]

Aleksey Nikolayev:

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 )

[Реter Konow]

Aleksey Nikolayev:

...

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. )

[Aliaksandr Hryshyn]

Aleksey Mavrin:
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:

//+------------------------------------------------------------------+
//| Initialization of the indicators                                 |
//+------------------------------------------------------------------+
bool CSampleExpert::InitIndicators(void)
  {
//--- create MACD indicator
   if(m_handle_macd==INVALID_HANDLE)
      if((m_handle_macd=iMACD(NULL,0,12,26,9,PRICE_CLOSE))==INVALID_HANDLE)
        {
         printf("Error creating MACD indicator");
         return(false);
        }
//--- create EMA indicator and add it to collection
   if(m_handle_ema==INVALID_HANDLE)
      if((m_handle_ema=iMA(NULL,0,InpMATrendPeriod,0,MODE_EMA,PRICE_CLOSE))==INVALID_HANDLE)
        {
         printf("Error creating EMA indicator");
         return(false);
        }
//--- succeed
   return(true);
  }

Next, remove the graphic 'tinsel'. Minus the colour, minus the indentation (relative positioning).

//Initialization of the indicators

bool CSampleExpert::InitIndicators(void)

{

//create MACD indicator

if(m_handle_macd==INVALID_HANDLE)

if((m_handle_macd=iMACD(NULL,0,12,26,9,PRICE_CLOSE))==INVALID_HANDLE)

{

printf("Error creating MACD indicator");

return(false);

}

//create EMA indicator and add it to collection

if(m_handle_ema==INVALID_HANDLE)

if((m_handle_ema=iMA(NULL,0,InpMATrendPeriod,0,MODE_EMA,PRICE_CLOSE))==INVALID_HANDLE)

{

printf("Error creating EMA indicator");

return(false);

}

//succeed

return(true);

}

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.