Обсуждение статьи "Язык MQL как средство разметки графического интерфейса MQL-программ (Часть 1)" - страница 3

 
Stanislav Korotky:

XML-я не будет. Вся суть в том, чтобы обойтись MQL. Задача сделать "родную" для MQL систему разметки уровня MVP - без наворотов, но достаточно функциональную и расширяемую для тех, кому потребуется. Во внутреннее устройство можно будет не вдаваться. Просто обычно лучше иметь описание концепции и устройства, чем не иметь.

...

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

 
Реter Konow:

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

То есть? В статье нет не то, что бы языка, даже самой концепции нет?

 
Если этот язык разметки ограничивается стандартной библиотекой, то наилучшим решением, упрощающим создание ГУИ посредством этой библиотеки, было бы нормальное справочное руководство по этой библиотеке.
 
Dmitry Fedoseev:

То есть? В статье нет не то, что бы языка, даже самой концепции нет?

Автор не описал принцип работы языка разметки. Задайте вопрос "как работает язык разметки?" и найдите в статье подробный ответ. Его нет. 

 
Реter Konow:

Автор не описал принцип работы языка разметки. Задайте вопрос "как работает язык разметки?" и найдите в статье подробный ответ. Его нет. 

Наверно будет в следующем выпуске.

 
Dmitry Fedoseev:

Наверно будет в следующем выпуске.

Я тоже подумал, что в следующем... Здесь ведь не простачки собрались... Все всё понимают. 

 
Stanislav Korotky:

XML-я не будет. Вся суть в том, чтобы обойтись MQL. Задача сделать "родную" для MQL систему разметки уровня MVP - без наворотов, но достаточно функциональную и расширяемую для тех, кому потребуется. Во внутреннее устройство можно будет не вдаваться. Просто обычно лучше иметь описание концепции и устройства, чем не иметь.

Я тоже не в восторге от стандартной библиотеки, но выбор в общем-то небогатый, поэтому она является (на данный момент) оптимальным компромиссом между теми немногочисленными совсем мелкими и супер навороченными библиотеками, к которым всё равно есть большие вопросы.

Мнимым светочам в вопросах программирования и создания GUI, объявившим себя таковыми на основе наивных поделок, рекомендуется демонстрировать свои шапкозакидательские настроения в собственных ветках.

А кого конкретно вы имеете ввиду? Тем более, что во множественном числе, а нас тут не так много. Было бы в единственном числе, я бы подумал, что это про Петра... но во множественном. Возникают вопросы. 

Слабо прямо по имени обратиться? Что бы лишних вопросов не возникало лишних вопросов. Или можете только воздух пространно пинать?

 

К теме статьи. В пятый раз внимательно, нейтрально и по возможности объективно перечитал все заново. И вот что:

1. В начале статьи, автор ясно и доходчиво обсуждает с читателем вопросы актуальности GUI в программах. Рассказывает об имеющихся графических инструментах MQL - МТ-объектах, библиотеках и даже виз.редакторе. Утверждает, что GUI скорее нужен, чем нет. Это понятная и приятная часть статьи.

2. Начинается ускорение. Автор приводит пример кода стандартной библиотеки и заслуженно критикует его - мол длинно, неудобно, неэффективно при построении GUI. Симпатии на его стороне.

3. Далее, автор переходит к обсуждению GUI в других языках, где он верно подмечает, что описание раскладки мудро отделено от программного кода и представляет из себя самостоятельное ответвление упрощающее рутинную компоновку интерфейсов. Перечисляет преимущества. На этот раз, автор использует общие фразы и отсылки к литературе, платформе .Net, Android, XML... Говорит, что дескать там также, как и здесь, все в "одном флаконе" и просматривается иерархия, а еще определены "одиночные контроллы". Он не поясняет, а просто идет дальше. Для непросвященных ясность заканчивается и все погружается в туман. Где, что, почему.... 

4. Автор "летит" и диалог с читателем переходит в скоростной монолог. Исчезает четкая последовательность изложения: вопросы/темы/решения/примеры/коды - все смешивается. Телепатам конечно не сложно, но остальным приходится не сладко. Создается впечатление, что автор находу придумывает решения для нового языка и не останавливаясь собирается все закончить к концу статьи. Мол "не мешайте, я щас все сделаю!". В бешенном ритме, мелькают обрывки мыслей, кодов, названия переменных и методов (может кому то известных...). Перескоки все более частые и голова уже не справляется в поиске связей предложений. Читать становится реально тяжело.

5. Диалог с читателем был потерян после первых двух глав и дальнейшее чтение мне не принесло ясности ни в чем. Хотя, я очень старался. Осталься вопрос: " а что именно автор предлагает?".

Закрыл статью и не смог ничего вспомнить, кроме примера с пятнашками и первые обзацы. Все остальное растворилось в тумане.


Надеюсь, в следующем выпуске, автор продолжит диалог с читателем и сохранит структуру повествования до конца статьи.

Спасибо.

 
Дмитрий Федосеев, хоть и обидно, но очень смешная вставка видео. Долго смеялся. Когда почитал выделенное вами, понял, что выглядит действительно глупо. Точнее было сказать не переписал, а улучшил и дополнил. Прочитал очень много ваших статей, за пятилетнее присутствие на этом сайте, и не сомневаюсь в том ваш багаж знаний намного больше моего, но в том что в экспретописательстве не возникает надобности в ООП, с вами не согласен. Так как в сложных программах, с использованием графических интерфейсов, объединении нескольких ТС в один советник, ведение статистики и тд, ООП очень помогает, лучше структуировать код программы, а шаблоны проектирования (хотя я еще в самом начале пути их изучения) увеличивают силу ООП в разы. Конечно это не значит, что толкать нужно в небольшой советник, где можно обойтись обычными процедурами, и скорость его написания будет в разы больше. Если будет интересно я опишу пример, где я применил ООП и один шаблон, и как это мне упростило жизнь. И если не сложно Дмитрий, не могли бы вы на примере показать свои слова "и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции". Или в какой статье можно почерпнуть информацию об указателях на функции. Заранее спасибо.
 
Алексей Мокрушин:
Дмитрий Федосеев, хоть и обидно, но очень смешная вставка видео. Долго смеялся. Когда почитал выделенное вами, понял, что выглядит действительно глупо. Точнее было сказать не переписал, а улучшил и дополнил. Прочитал очень много ваших статей, за пятилетнее присутствие на этом сайте, и не сомневаюсь в том ваш багаж знаний намного больше моего, но в том что в экспретописательстве не возникает надобности в ООП, с вами не согласен. Так как в сложных программах, с использованием графических интерфейсов, объединении нескольких ТС в один советник, ведение статистики и тд, ООП очень помогает, лучше структуировать код программы, а шаблоны проектирования (хотя я еще в самом начале пути их изучения) увеличивают силу ООП в разы. Конечно это не значит, что толкать нужно в небольшой советник, где можно обойтись обычными процедурами, и скорость его написания будет в разы больше. Если будет интересно я опишу пример, где я применил ООП и один шаблон, и как это мне упростило жизнь. И если не сложно Дмитрий, не могли бы вы на примере показать свои слова "и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции". Или в какой статье можно почерпнуть информацию об указателях на функции. Заранее спасибо.

Всё есть в документации, изучайте, пользуйтесь.