Никто не "гадил". Лично я высказал обоснованное мнение, что автор не изложил четких принципов устройства языка разметки, поскольку их не знает. В статье с одной стороны много общих слов, с другой - ненужных деталей (вроде игры в пятнашки). Автор еще не понимает концепции языка разметки и считает, что обычную библиотеку можно в него переделать. Ждем момента, когда он опишет план реализации.
Лично я имею право критиковать, потому что создал язык разметки и мне хорошо видно, когда "льется вода", а когда идет дело. В данной статье нет концепции, но есть попытка ее сформулировать. Посмотрим, что дальше...
Лучшее описание статьи - автор "включил" поток сознания, и пытается рассуждать, как можно было бы попробывать подойти к реализации. Собственно, он в статье сам это пишет (проверка реализуемости концепции "POC").
Я бы сказал, что язык разметки (по какой бы технологии он не создавался) это набор комманд, к.слов, правил и синтаксиса оформляемых поверх графического функционала обслуживающего элементы управления. То есть, теоритически, граф.библиотеку можно обернуть в язык с упрощенным синтаксисом и легким построением граф.конструкций, ускорив процесс описания GUI для пользователя и экономя его силы, НО, не забывайте что для этого нужно:
1. Придумать язык с правилами и синтаксисом.
2. Написать интерпретатор переводящий код "языка" в код MQL , т.е - обертку (запись разметки) в библиотечные вызовы соответствующего функционала.
За этим стоит создание специального движка, устройство которого нужно хорошо понимать заранее.
Алексей Мокрушин: ...так как в mql нет делегатов, пришлось понять, что это за блюдо и с чем его едят. Пришлось переписать все стандартные классы. Начал с начала, с CObject. Написал в итоге простую реализацию обработки событий OnTradeTransaction, OnChartEvent, OnTimer с помощью "настоящего" ООП...
положа руку на сердце - CObject и "Стандартная библиотека" это то ещё наследие 90-х годов :-)
пока не возникнет подобие STL не требующего дополнительных аттрибутов от экземпляров и/или наличия "адама" (гранд-класса/общего предка) будут существенные проблемы - видимая часть которых это объём кода прикладных программ. Они блин очень большие....
положа руку на сердце - CObject и "Стандартная библиотека" это то ещё наследие 90-х годов :-)
пока не возникнет подобие STL не требующего дополнительных аттрибутов от экземпляров и/или наличия "адама" (гранд-класса/общего предка) будут существенные проблемы - видимая часть которых это объём кода прикладных программ. Они блин очень большие....
CObject здесь не главное. ООП != Шаблоны, не надо путать, где используется сила шаблонов, а где сила ООП. Никакой особой потребности ни в ООП, ни тем более в шаблонах при экспретописательстве не возникает, и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции.
Как бы это не было печально, но шутка про "клуб жертв с++" становится реальностью. Странно, что люди наваливают на себя кучу всяких заморочек и считают это крутым кодингом. А по сути, современный программист выродился в подключателя библиотек.
CObject здесь не главное. ООП != Шаблоны, не надо путать, где используется сила шаблонов, а где сила ООП. Никакой особой потребности ни в ООП, ни тем более в шаблонах при экспретописательстве не возникает, и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции.
Как бы это не было печально, но шутка про "клуб жертв с++" становится реальностью. Странно, что люди наваливают на себя кучу всяких заморочек и считают это крутым кодингом. А по сути, современный программист выродился в подключателя библиотек.
"в чём сила, брат?"
подключатели_библиотек должны рулить. Это на самом деле правильно, когда сокращает объём кода и время разработки.
PS/ пока-что все публикуемые статьи (и их наработки, что важнее) являются антитезой программирования - они не влекут повышения эффективности.
подключатели_библиотек должны рулить. Это на самом деле правильно, когда сокращает объём кода и время разработки.
PS/ пока-что все публикуемые статьи (и их наработки, что важнее) являются антитезой программирования - они не влекут повышения эффективности.
Сила в знании, а статьи, как раз дают знания, и ничего другого они должны давать. Повышение эффективности, это дело личное каждого. Повышение эффективности программирования, это конечно хорошо, но не тогда, кода от этого падает удобство для пользователя этой программой.
... А по сути, современный программист выродился в подключателя библиотек.
Скоро он совсем исчезнет, так как собирать "объекты" (именованные группы параметров с предустановленными связями) можно интуитивно и без высшего образования, с поддержкой "интеллектуально-развитой" IDE, которая с "полу-слова" будет "понимать" суть возводимой логической структуры. Среда поумнеет и настанет конец эры специализированных программистов и разнообразия языков. Каждый сможет строить алгоритмы прочтя инструкцию к программе. Естественный процесс, ничего страшного... Странно, что это не началось раньше, а вместо этого расплодились языки повторяющие одну концепцию на разный лад.
XML-я не будет. Вся суть в том, чтобы обойтись MQL. Задача сделать "родную" для MQL систему разметки уровня MVP - без наворотов, но достаточно функциональную и расширяемую для тех, кому потребуется. Во внутреннее устройство можно будет не вдаваться. Просто обычно лучше иметь описание концепции и устройства, чем не иметь.
Я тоже не в восторге от стандартной библиотеки, но выбор в общем-то небогатый, поэтому она является (на данный момент) оптимальным компромиссом между теми немногочисленными совсем мелкими и супер навороченными библиотеками, к которым всё равно есть большие вопросы.
Мнимым светочам в вопросах программирования и создания GUI, объявившим себя таковыми на основе наивных поделок, рекомендуется демонстрировать свои шапкозакидательские настроения в собственных ветках.
Мнимым светочам в вопросах программирования и создания GUI, объявившим себя таковыми на основе наивных поделок, рекомендуется демонстрировать свои шапкозакидательские настроения в собственных ветках.
...
...так как в mql нет делегатов, пришлось понять, что это за блюдо и с чем его едят. Пришлось переписать все стандартные классы. Начал с начала, с CObject. Написал в итоге простую реализацию обработки событий OnTradeTransaction, OnChartEvent, OnTimer с помощью "настоящего" ООП...
.
.
положа руку на сердце - CObject и "Стандартная библиотека" это то ещё наследие 90-х годов :-)
пока не возникнет подобие STL не требующего дополнительных аттрибутов от экземпляров и/или наличия "адама" (гранд-класса/общего предка) будут существенные проблемы - видимая часть которых это объём кода прикладных программ. Они блин очень большие....
положа руку на сердце - CObject и "Стандартная библиотека" это то ещё наследие 90-х годов :-)
пока не возникнет подобие STL не требующего дополнительных аттрибутов от экземпляров и/или наличия "адама" (гранд-класса/общего предка) будут существенные проблемы - видимая часть которых это объём кода прикладных программ. Они блин очень большие....
CObject здесь не главное. ООП != Шаблоны, не надо путать, где используется сила шаблонов, а где сила ООП. Никакой особой потребности ни в ООП, ни тем более в шаблонах при экспретописательстве не возникает, и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции.
Как бы это не было печально, но шутка про "клуб жертв с++" становится реальностью. Странно, что люди наваливают на себя кучу всяких заморочек и считают это крутым кодингом. А по сути, современный программист выродился в подключателя библиотек.CObject здесь не главное. ООП != Шаблоны, не надо путать, где используется сила шаблонов, а где сила ООП. Никакой особой потребности ни в ООП, ни тем более в шаблонах при экспретописательстве не возникает, и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции.
Как бы это не было печально, но шутка про "клуб жертв с++" становится реальностью. Странно, что люди наваливают на себя кучу всяких заморочек и считают это крутым кодингом. А по сути, современный программист выродился в подключателя библиотек."в чём сила, брат?"
подключатели_библиотек должны рулить. Это на самом деле правильно, когда сокращает объём кода и время разработки.
PS/ пока-что все публикуемые статьи (и их наработки, что важнее) являются антитезой программирования - они не влекут повышения эффективности.
"в чём сила, брат?"
подключатели_библиотек должны рулить. Это на самом деле правильно, когда сокращает объём кода и время разработки.
PS/ пока-что все публикуемые статьи (и их наработки, что важнее) являются антитезой программирования - они не влекут повышения эффективности.
Сила в знании, а статьи, как раз дают знания, и ничего другого они должны давать. Повышение эффективности, это дело личное каждого. Повышение эффективности программирования, это конечно хорошо, но не тогда, кода от этого падает удобство для пользователя этой программой.
... А по сути, современный программист выродился в подключателя библиотек.
Скоро он совсем исчезнет, так как собирать "объекты" (именованные группы параметров с предустановленными связями) можно интуитивно и без высшего образования, с поддержкой "интеллектуально-развитой" IDE, которая с "полу-слова" будет "понимать" суть возводимой логической структуры. Среда поумнеет и настанет конец эры специализированных программистов и разнообразия языков. Каждый сможет строить алгоритмы прочтя инструкцию к программе. Естественный процесс, ничего страшного... Странно, что это не началось раньше, а вместо этого расплодились языки повторяющие одну концепцию на разный лад.
XML-я не будет. Вся суть в том, чтобы обойтись MQL. Задача сделать "родную" для MQL систему разметки уровня MVP - без наворотов, но достаточно функциональную и расширяемую для тех, кому потребуется. Во внутреннее устройство можно будет не вдаваться. Просто обычно лучше иметь описание концепции и устройства, чем не иметь.
Я тоже не в восторге от стандартной библиотеки, но выбор в общем-то небогатый, поэтому она является (на данный момент) оптимальным компромиссом между теми немногочисленными совсем мелкими и супер навороченными библиотеками, к которым всё равно есть большие вопросы.
Мнимым светочам в вопросах программирования и создания GUI, объявившим себя таковыми на основе наивных поделок, рекомендуется демонстрировать свои шапкозакидательские настроения в собственных ветках.
...
Мнимым светочам в вопросах программирования и создания GUI, объявившим себя таковыми на основе наивных поделок, рекомендуется демонстрировать свои шапкозакидательские настроения в собственных ветках.
В точку.