Закат программирования? - страница 17

Новый комментарий
 
Alexandr Andreev:

Конечно проще разбирать код зная схему, чем не зная схему.

Технически даже было бы удобно иметь некий визуализатор кода... особенно если одно не отменяет другое а дополняет. 

Согласен.
 
Ну вот и пришли к тому что хоть лошадь в колхозе работает и больше, но без хорошего конюха от нее толку ни какого.
 
правда надо очень очень хорошо проработать юзабилити этого всего. И понимать что чаще всего нужно. Т.е. всю портянку всех взаимосвязи показывать точно нет смысла, т.к. их может быть по 20 наследований(это в глубину) обьекта с множеством вложений, перезагрузок. А вот что то типо глянуть где упоминается данный объектов вышестоящих структурах, или где инициализируеться если у нас в разбираемом коде написана внешняя детальная инициализация обьекта. Либо быстро создать новый промежуточный обьект с перезагрузкой определенных функций и понять что ненакосячил в вышестоящих. Хотя обычно с этой задачей справляется поиск ну либо компилятор
 
Alexandr Andreev:

Конечно проще разбирать код зная схему, чем не зная схему.

Технически даже было бы удобно иметь некий визуализатор кода... особенно если одно не отменяет другое а дополняет. 

А почему не сделать полноценный визуализатор кода, который был бы самодостаточен?

Придумать графический язык представления кода, продумать хорошую навигацию в нём, определиться с приоритетом значимости отображаемой информации(более значимая информация требует меньше усилий для её отображения, менее значимая - наоборот). Ещё нужен полноценный разбор кода.

Легко точно не будет. Ладно, знаю что до реализации наврядли дойдёт...

 
Aliaksandr Hryshyn:

А почему не сделать полноценный визуализатор кода, который был бы самодостаточен?

Придумать графический язык представления кода, продумать хорошую навигацию в нём, определиться с приоритетом значимости отображаемой информации(более значимая информация требует меньше усилий для её отображения, менее значимая - наоборот). Ещё нужен полноценный разбор кода.

Легко точно не будет. Ладно, знаю что до реализации наврядли дойдёт...

Есть такие проги, как например 3д проектирование нефтеперерабатывающих установок. В них есть диаграмма связей трубопроводов. Бывалым инженерам-технологам поначалу кипу чертежей прочитать легче, чем одну "наглядную" диаграмму, потом привыкают. Я к тому что сложный код он и при визуализации останется сложным для восприятия. Если соблюдать все правила то код довольно легко читать в исходном виде. 
 
Aliaksandr Hryshyn:

А почему не сделать полноценный визуализатор кода, который был бы самодостаточен?

Придумать графический язык представления кода, продумать хорошую навигацию в нём, определиться с приоритетом значимости отображаемой информации(более значимая информация требует меньше усилий для её отображения, менее значимая - наоборот). Ещё нужен полноценный разбор кода.

Легко точно не будет. Ладно, знаю что до реализации наврядли дойдёт...

С возможностью создания своих настроек со своим кодом и визуальным оформлением, а также использованием готовых шаблонов визуального оформления других, это называется лень написать пару строк)))

В програмировании у меня на первом месте по использованию скорее всего перезагрузка функций. Но в коде там и так все очень кратко, пишем новое название, пишем откуда наследуемся (и как правило это шаблон), пишем что и на что заменяем. Все!

Думаю эти выкрутасы быстро разрастутся в огромную библиотеку и сложно будет запомнить все это.

 
Реter Konow:
Да, но его направление верно. Кодинг - узкий канал использования потенциала мозга. Закономерность описанная кодом понимается в сотни раз дольше той же закономерности, воспринимаемой глазами. Представьте вращение волчка, который на каждом круге замедляется и немного увеличивает угол наклона. Опишите этот процесс формулами в коде и снимите на камеру. Замерьте время, за которое программист поймет, что это одно и тоже.

У каждого свои подходы. Лично меня диаграммы только раздражают слегка) Мне гораздо больше нравится подход литературного программирования Дональда Кнута (по-русски почему-то переводится как "грамотное") и то как это реализовано, например, в языке R (R Markdown)

Про волчок зря вы написали) Это нерешённая задача механики - нет общей формулы движения (даже если пренебречь трением). 

Literate programming - Wikipedia
Literate programming - Wikipedia
  • en.wikipedia.org
The literate programming paradigm, as conceived by Knuth, represents a move away from writing computer programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts.[2] Literate programs are written as an uninterrupted exposition of...
 
Aleksey Nikolayev:

Про волчок зря вы написали) Это нерешённая задача механики - нет общей формулы движения (даже если пренебречь трением). 

А кельтский камень тоже волчок )

 
Aleksey Nikolayev:

...

Про волчок зря вы написали) Это нерешённая задача механики - нет общей формулы движения (даже если пренебречь трением). 

Как то не подумал об этом. ) 

 
Aleksey Mavrin:
Есть такие проги, как например 3д проектирование нефтеперерабатывающих установок. В них есть диаграмма связей трубопроводов. Бывалым инженерам-технологам поначалу кипу чертежей прочитать легче, чем одну "наглядную" диаграмму, потом привыкают. Я к тому что сложный код он и при визуализации останется сложным для восприятия. Если соблюдать все правила то код довольно легко читать в исходном виде. 

Вы задайтесь вопросом, почему ниже два варианта отображения кода по разному воспринимаются:

//+------------------------------------------------------------------+
//| 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);
  }

Дальше убрали графическую "мишуру". Минус цвет, минус отступ(относительное расположение).

//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);

}

Читаемость заметно ухудшилась. Это говорит о том, что графическое представление может заметно улучшить читаемость. Я не говорю про конкретно про диаграммы, вариантов может быть много.
1...1011121314151617181920212223
Новый комментарий