Мт4 Конец поддержке. - страница 10

 
Artyom Trishkin:

Если только "бабушка" и "ребёнок" не по возрасту, а по активности разума. Ибо многим, кто с успехом используют все возможности современных реалий, гораздо больше, чем "продвинутая молодёжь"

А зачем же нужно "использовать все возможности", если для конкретных нужд требуется ровно одна из них? Это позиция продавца - перечислять много-много возможностей. Давно уже известно действующее всюду правило (и в программировании тоже): специальные решения эффективнее универсальных.

Резать хлеб дома эффективнее большим ножом с одним лезвием, чем универсальным с 9 предметами, включая вилку и штопор. Не в походе ведь.

На любом языке можно написать свою базу данных, но есть и СУБД, которые которые хорошо работают с БД и никак не реализуют возможности редактирования фотографий. Для больших БД они обычно эффективнее языков общего назначения. Но можно небольшую БД сделать и в Excel. Какой инструмент лучше подходит, тот и нужен.

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

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

Может быть, для организации интерфейса с пользователем? Вот уж где наворочено множество вариантов на ООП, одна библиотека визуальных компонентов Delphi чего стоит. Так советники и скрипты призваны заменять человека у компьютера, этот интерфейс прямо противоречит их назначению, не нужен. То есть мешает. Также, как лишние предметы в перочинном ножичке. Или гвоздодер на конце стальной ручки универсального молотка - не только царапает, но и смещает центр тяжести от бойка к ручке.

Какая же специализация реально требуется от MQL? Этот язык должен обепечивать то, что другими средствами невозможно. То есть прием сведений от сервера и передачу запросов к серверу. С возможностью отдавать сведения во внешние программы. Пусть в универсальных средствах разработки кто как хочет, так и применяет хоть ООП, хоть разработку снизу, хоть сверху, хоть экстремальное программирование, хоть визуальное и пр. и пр.

Я бы обрадовался, если бы вместо ООП в MQL5 появилась возможность программно узнать комиссию ДЦ. Ее не хватает, а в терминале комиссия известна. Это, на мой взгляд, очевидная недоработка.

 
Vitaly Muzichenko:

И ещё, как-то навеяло.

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

Реter Konowпростите за критику


Слушай, я бы тебе сейчас ответил, но забанят. Мягко говоря - ты покажи свои результаты, потом говорить про шлак будешь. 

 
Gorg1983:

Он когда-то говорил что и тиков с локами принципиально не будет в мт5. Даже банили людей за обсуждение этого. И что?

Это вопрос не ко мне, спросите напрямую у источника.
 
Vladimir:
Это вопрос не ко мне, спросите напрямую у источника.

Не вижу смысла. К тому же это был риторический вопрос.

 

Если говорить о пользователе, то компания MetaQuotes сделала очень много чтоб приучить пользователя к наворотам МТ5.

Вспомните каким был МТ4 до 230 билда (номер на вскидку, последний билд что помню который декомпильнули).

А теперь МТ4 почти не отличим от МТ5, хотя они и имеют разную архитектуру. Всё это делалось для того чтоб пользователи долбили свои диллинги требуя перехода, и чтоб этот переход был комфортным, теже кнопочки, теже функции, всё в тех же папках.

Потому как сами диллинги выходить из зоны комфорта не желают. Мало того что желания у них нет, так за это ещё  и больше денег платить нужно, лицензия то на МТ5 подороже будет чем на МТ4.

И тут мы внезапно попадаем в сферу обсуждения ценообразования лицензированных продуктов, поэтому я умолкаю, потому как обсуждать это как считать чужие деньги.

Для того чтоб иметь своё мнение в этом разделе бизнеса, нужно иметь опыт продажи хотя бы одного продукта дороже $100К.

 
Реter Konow:

Конечно, для опытного программиста и разработчика разобратся в MQL5 - ерунда. Но вспомните о новичках и самоучках, которые хотят овладеть программированием только для того, чтобы реализовать свои "гениальные" стратегии. Так вот именно им и будет тяжело освоить дополнительные навороты и при выборе платформы, они скорее всего, долго думать не станут. В этом то и проблема.

А у новичка самоучки какие проблемы? Это сообщение пишет один из самоучек. После mql4 мне хватило 2-3 недель чтобы написать свой первый индикатор на mql5. Теперь только совершенствую свои познания.

О каких наворотах идёт речь? О функциях которые в ООП принято называть методами, или о перегрузке функций? В конце концов можно в mql5 обойтись вообще без классов, никто не запрещает. Ну, а если говорить о тех кто никак не в силах разобраться, то уж... не относящееся к Вам, надо вспомнить В.С. Высоцкого

Но, если туп, как дерево - родишься баобабом

и прямиком во фриланс.

 
Artyom Trishkin:

Всё гораздо проще. Никто не запрещает писать в процедурном стиле на mql4 и mql5 - совершенно одинаково. Равно как и с использованием ООП - и там, и там.

Просто Пётр выдумал проблему и холит её. Скорее всего из-за того, что сам не в силах понять. А может потому, что очень любит преодолевать трудности и сложности. Из двух путей, которые приведут к одинаковому результату, выбирает долгий и тернистый. Зато потом чувствует себя крутым программистом. Мне кажется суть его отторжения ООП кроется в этом. Могу ошибаться конечно, но обычно чувствую людей.


Я например терпеть не могу инклюдники в виде библиотек, тупо потому что не знаю что туда напихали и как это мне поможет, проще написать еще десяток функций

по аналогии с Реter Konow.

Ну и закон сохранения энергии: зачем декомпилировать библиотеку и разбираться в ней если все работает без нее?

З.Ы

мой топ про лосей не встречался?

 
Artyom Trishkin:
  1. ч_идентификатор_графика;
  2. m_chart_id;

Первое от второго отличается длиной. А смысл понятен равнозначно.

Что проще читать - лаконичный код, или растянутую на два экрана в ширину портянку?

Мне проще и быстрее читать короткий лаконичный код. Если вам в радость перемещать ползунком код по горизонтали на каждой строке - перемещайте, кто ж вам запрещает.

Видел я такие коды от новичка - глаза чуть не потерял, и отказался в нём разбираться пока не переименует свои

"ПеременнаяДляХраненияОщейПрибылиПозицийВыбранныхПоМагику" на

"profit_all_by_magic";

1. Идентификатор_графика читается русскоязычным человеком быстрее чем m_chart_id.


2. Если в программе сотни переменных, то русский язык оказывает незаменимую поддержку.  


Все это можно проверить в эксперименте. 


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


Надо просто разработать правила именования переменных на русском. Вместо "переменная_для_хранения_общей_прибыли _позиции, - просто: Общая_прибыль.

 
Nikolai Semko:
Если вы своей бабушке подарите флагманский iPhone или Android взамен сломавшегося её кнопочного телефона и попробуете объяснить ей все новые возможности в сравнении с её старым телефоном,  то процентов 90,  что она скажет,  что её  старый телефон был лучше,  т.к. там были кнопки и можно было чувствовать пальцами какую кнопку нажимаешь. И,  думаю, максимальным достижением кроме совершения звонков для неё будет освоить отправку смс,  особо одаренных бабушек возможно даже удастся научить юзать Whatsapp.  Все же остальное для неё будет выглядеть "пятым колесом". И ей будет проще спросить кого-то на улице, как добраться до улицы Лизюкова,  чем открыть Google maps. Ибо сила привычки грандиозна! 
Но если вы в то же самое время подарите такой-же телефон своей 5-летней дочери или сыну и покажете все его основные функции,  то процентов 90,  что второго раза необходимости объяснять не понадобиться.  А возможно даже объяснять не придётся,  сами разберутся. 
Так же и с ООП и MQL5... 

Умеешь ты Николай находить аргументы.)

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

 
Vladimir:

А зачем же нужно "использовать все возможности", если для конкретных нужд требуется ровно одна из них? Это позиция продавца - перечислять много-много возможностей. Давно уже известно действующее всюду правило (и в программировании тоже): специальные решения эффективнее универсальных.

Резать хлеб дома эффективнее большим ножом с одним лезвием, чем универсальным с 9 предметами, включая вилку и штопор. Не в походе ведь.

На любом языке можно написать свою базу данных, но есть и СУБД, которые которые хорошо работают с БД и никак не реализуют возможности редактирования фотографий. Для больших БД они обычно эффективнее языков общего назначения. Но можно небольшую БД сделать и в Excel. Какой инструмент лучше подходит, тот и нужен.

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

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

Может быть, для организации интерфейса с пользователем? Вот уж где наворочено множество вариантов на ООП, одна библиотека визуальных компонентов Delphi чего стоит. Так советники и скрипты призваны заменять человека у компьютера, этот интерфейс прямо противоречит их назначению, не нужен. То есть мешает. Также, как лишние предметы в перочинном ножичке. Или гвоздодер на конце стальной ручки универсального молотка - не только царапает, но и смещает центр тяжести от бойка к ручке.

Какая же специализация реально требуется от MQL? Этот язык должен обепечивать то, что другими средствами невозможно. То есть прием сведений от сервера и передачу запросов к серверу. С возможностью отдавать сведения во внешние программы. Пусть в универсальных средствах разработки кто как хочет, так и применяет хоть ООП, хоть разработку снизу, хоть сверху, хоть экстремальное программирование, хоть визуальное и пр. и пр.

Я бы обрадовался, если бы вместо ООП в MQL5 появилась возможность программно узнать комиссию ДЦ. Ее не хватает, а в терминале комиссия известна. Это, на мой взгляд, очевидная недоработка.

Очень трезвый и практичный взгляд на вещи. Полностью поддерживаю.
Причина обращения: