Вопросы по ООП в MQL5 - страница 25
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Тут есть подробная статистика https://githut.info/, правда 14 год.
Свежая статистика по github'у https://madnight.github.io/githut/#/pull_requests/2019/2
Думаю всем будет полезно почитать мнение профессионалов в этой статье.
Удачи
Думаю всем будет полезно почитать мнение профессионалов в этой статье.
все (абсолютно предвзятые) выводы статьи нивелируются одним простым вопросом.
ФП существует давно, почему у него до сих пор такая маленькая ниша если оно такое офигенное?
Ни в коем случае не имею в виду что ООП прям без вариантов наилучшая концепция или ФП отстой.
все (абсолютно предвзятые) выводы статьи нивелируются одним простым вопросом.
ФП существует давно, почему у него до сих пор такая маленькая ниша если оно такое офигенное?
В статье есть ответ на этот вопрос. Вы не внимательно прочли.
В статье есть ответ на этот вопрос.
Абсолютно предвзятый и ни о чем.
Есть девелоперы, которые собственно пишут код. Есть менеджеры, которые могут не уметь программировать от слова вообще.
Так вот стек технологий совсем не обязательно выбирается девелоперами. И если определенный стек позволяет команде эффективней решить задачу, необязательно владеть и знать технологии, чтобы это понять.
Вы все еще считаете что статья отвечает на вопрос?
Думаю всем будет полезно почитать мнение профессионалов в этой статье.
Удачи
Вот как всегда. Крайние точки зрения. Это как спор о том, что лучше - молоток или кувалда.
На C# дрова путные не напишешь, а на чистом С шизнешься разветвленные логические связи в серьезном приложении описывать и отлаживать.
Так что статья ни о чем.
Вот как всегда. Крайние точки зрения. Это как спор о том, что лучше - молоток или кувалда.
На C# дрова путные не напишешь, а на чистом С шизнешься разветвленные логические связи в серьезном приложении описывать и отлаживать.
Так что статья ни о чем.
есть конечно в статье немного правды... ну как минимум, что наследование будет "тянуть" не нужные по сути методы и поля, но увы, за все нужно платить - это экономит время, но это может увеличить использование памяти или общую производительность решения, но пять же не все так грустно, уровень компиляторов и оптимизации кода сейчас очень крут, поэтому зачастую на выходе получается хорошее решение задачи за короткое время разработки
про C#, ну как бы цели у него другие, он чисто "виндовский язык" для быстрого получения результата на конкретном ПК или ограниченной группе ПК, даже не установленные обновления .Net могут вызвать критическую ошибку на ПК к которым нет доступа, а отловить это довольно затратно - писал панельку для торговли на C# уже проверил это, на виртуальной машине, если не установлены все "заплатки" в обновлениях, то проект может не предсказуемо вылетать ;) , можно конечно попытаться писать под самую младшую .Net версию, но и тут беда - все новинки на GitHub выкладывают под новые сборки .Net - т.е. будешь ограничен только своими наработками
в общем как и везде - новаторство это "больно и долго и грустно", приходится следовать трендам задаваемым ИТ-гигантами, тогда все пишется быстро и без проблем, ну написал Майкрософт все что только мог в стиле ООП, приходится всем этим пользоваться или будешь писать с нуля все свои WinForm и пр. тысячи тон и терабайтов кода написанных с момента Win-95 )))
есть конечно в статье немного правды...
Немного? ) Вообще-то всё именно так и обстоит. Впрочем америку автор не открывает, это вроде как очевидные вещи (по крайней мере для меня). Мне казалось, у любого программиста с опытом приходит такое же осознание проблем изменчивого состояния. Кстати я совсем недавно видел очень похожую статью, только покороче. Впрочем это, видимо, извечный холивар между функциональщиками и ооп-шниками )
Но по факту ведь никто не мешает использовать ООП правильно. Даже сам автор упоминает о том, что можно использовать неизменяемые объекты. И 99% описанных проблем сразу отпадают. Т.е. всё упирается лишь в вопрос прямости рук и головы на плечах, а не используемой парадигмы.
Хотя конечно тот факт, что популярные ООП-языки не предоставляют средств контроля изменчивости объектов, осложняет процесс. Так то реально круто было бы иметь ключевое слово immutable вместо const/readonly.
А вот насчёт причин непопулярности функциональных языков - тут я с автором не соглашусь. Дело прежде всего в более сложном восприятии такого кода, как мне видится. Это ведь не просто противопоставление ООП и ФП, а противопоставление императивного и функционального подходов. Первый из них более близок и интуитивен для понимания большинству людей, на мой взгляд. Я с функциональными языками знаком лишь заочно, поэтому не могу судить объективно, но когда допустим вижу код, перегруженный лямбдами, то меня это вводит в когнитивный диссонанс ) Слишком запутанно и мудрёно. И наверное большинство тоже так считает )
Да и кроме того, функциональные языке не предназначены для ряда задач, связанных с взаимодействием с внешним окружением. Взять тот же графический интерфейс. Когда так или иначе необходимо сохранять глобальное изменённое состоянии между событиями.
Немного? ) Вообще-то всё именно так и обстоит. Впрочем америку автор не открывает, это вроде как очевидные вещи (по крайней мере для меня). Мне казалось, у любого программиста с опытом приходит такое же осознание проблем изменчивого состояния. Кстати я совсем недавно видел очень похожую статью, только покороче. Впрочем это, видимо, извечный холивар между функциональщиками и ооп-шниками )
Но по факту ведь никто не мешает использовать ООП правильно. Даже сам автор упоминает о том, что можно использовать неизменяемые объекты. И 99% описанных проблем сразу отпадают. Т.е. всё упирается лишь в вопрос прямости рук и головы на плечах, а не используемой парадигмы.
Хотя конечно тот факт, что популярные ООП-языки не предоставляют средств контроля изменчивости объектов, осложняет процесс. Так то реально круто было бы иметь ключевое слово immutable вместо const/readonly.
все равно в ближайшее время ничего не изменится, ИТ-гиганты эту парадигму поддерживают, возможно это и выгодно - заставлять разработчиков ПО делать сложные реализации, которые будут требовать более мощного железа для работы, как и свою документацию к ОС или компиляторам с готовыми библиотеками представлять в большинстве своем в виде ООП, что вынуждает разработчиков .... и так до бесконечности ;)
можно считать, что эта история с ООП , как когда то обязательное знание медиками латыни - вроде и не нужна была, а как средство коммуникации на профессиональному уровне обязательно было применять ;)