Разговоры на завалинке о ООП - страница 20
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Статья врет!
Дальше статью не читал. Скорее всего, на этот бред автора в комментариях сразу указали.Читайте дальше, там все по делу.
В процедурном кодинге почти всегда можно додумывать архитектуру программы по ходу написания кода. Потому что гибкость и свобода полная
+
Только ради этого можно забыть про ООП, особенно для вычислительных алгоритмов как в трейдинге...
О мифах ООП - не для слабонервных адептов ООП.
"С середины 80-ых об ООП гуляет несколько мифов. Один из них, Миф о повторном использовании, гласит, что ООП делает разработку продуктивней, потому позволяет наследовать и расширять текущий код вместо того, чтобы всякий раз писать его заново. Другой, Миф о проектировании, который подразумевает, что анализ, проектирование и реализация плавно следуют друг из друга, потому что все они — суть объекты. Конечно же, ни один из этих мифов не может быть парадигмой ООП."
Дядя теоретик и балабол, как и большинство из академической среды. И не важно, что он профессор(звание давно инфлировало) и автор книг.
Этот надерганный бред из фраз давно гуляет и совершенно игнорирует экспоненциальный рост сложности программных продуктов. То, что было 30-20-10 лет назад, ни в какой степени не сравнимо с масштабами и сложностью текущих проектов. А они все еще предпочитают в песочнице играть, сводя к моделькам.
Посадить его сделать реальный продукт, у которого масса требований, включая ресурсные, экономические и конкурентные. Мгновенно сольет со своими рассуждениями, провалив все, что можно. Скорее даже выгонят за детское капитанство на этапе проработки решения.
Серебрянных пуль перепробовал мир много, но все они оказались негодными и давно списаны. Остается постоянный рост сложности, рост библиотек(а там ооп) и фрейморков(а там ооп), которые позволяют хоть как-то контролировать сложность.
И никуда от роста сложности не деться. Будет еще сложнее, будет еще больше неграмотных разработчиков, не способных угнаться за требованиями к качеству знаний.
Будет еще больше попыток придумать еще более простые языки, чтобы соответствовать все более понижающему массовому уровню программистов. Все больше софтверных компаний окажутся у разбитого корыта, просто поверив не в ту технологию и проиграв в конкурентной гонке. Просто их конкуренты будут использовать более тяжелые, но эфффективные по продуктовому результату технологии.
Уже давно инвестиции в софтверные компании - это смертельная вещь. Смертность и провалы потрясающие, а дальше будет хуже.
Почему? Да потому, что это бизнес с массой экономических требований, а не технарство. Процентов на 80 живая и стоящая на ногах софтверная компания состоит из маркетинга и продаж. А неверно выбранная технология(а тут у большинства приоритет за якобы простотой) запросто убивает последующие продажи. Потому что всегда есть конкуренты, которые пошли более тяжелым путем и в финале добились более лучших результатов.
Теперь о микропроектах до сотни тысяч строк. Это позволяет творить все, что угодно, так как имеет шанс уместиться в голове одного человека и поддерживать в нем иллюзию контроля. При попытке масштабироваться - боль, разочарование и смерть.
Выводы:
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Разговоры на завалинке о ООП
Renat Fatkhullin, 2018.01.17 09:17
Дядя теоретик и балабол, как и большинство из академической среды. И не важно, что он профессор(звание давно инфлировало) и автор книг.
Этот надерганный бред из фраз давно гуляет и совершенно игнорирует экспоненциальный рост сложности программных продуктов. То, что было 30-20-10 лет назад, ни в какой степени не сравнимо с масштабами и сложностью текущих проектов. А они все еще предпочитают в песочнице играть, сводя к моделькам.
Посадить его сделать реальный продукт, у которого масса требований, включая ресурсные, экономические и конкурентные. Мгновенно сольет со своими рассуждениями, провалив все, что можно. Скорее даже выгонят за детское капитанство на этапе проработки решения.
Серебрянных пуль перепробовал мир много, но все они оказались негодными и давно списаны. Остается постоянный рост сложности, рост библиотек(а там ооп) и фрейморков(а там ооп), которые позволяют хоть как-то контролировать сложность.
И никуда от роста сложности не деться. Будет еще сложнее, будет еще больше неграмотных разработчиков, не способных угнаться за требованиями к качеству знаний.
Будет еще больше попыток придумать еще более простые языки, чтобы соответствовать все более понижающему массовому уровню программистов. Все больше софтверных компаний окажутся у разбитого корыта, просто поверив не в ту технологию и проиграв в конкурентной гонке. Просто их конкуренты будут использовать более тяжелые, но эфффективные по продуктовому результату технологии.
Уже давно инвестиции в софтверные компании - это смертельная вещь. Смертность и провалы потрясающие, а дальше будет хуже.
Почему? Да потому, что это бизнес с массой экономических требований, а не технарство. Процентов на 80 живая и стоящая на ногах софтверная компания состоит из маркетинга и продаж. А неверно выбранная технология(а тут у большинства приоритет за якобы простотой) запросто убивает последующие продажи. Потому что всегда есть конкуренты, которые пошли более тяжелым путем и в финале добились более лучших результатов.
Теперь о микропроектах до сотни тысяч строк. Это позволяет творить все, что угодно, так как имеет шанс уместиться в голове одного человека и поддерживать в нем иллюзию контроля. При попытке масштабироваться - боль, разочарование и смерть.
Выводы:
Лучший пост месяца, а может быть и года! Ренат, почему Вы или Ваша компания не пишите статьи на хабре (компания даже там не зарегистрирована!)? Вы можете так многое сказать, но Ваш опыт узнаешь только урывками из постов. Серъезно, очень злободневно и точно получилось. В качестве иллюстрации к посту: https://habrahabr.ru/post/344356/
Лучший пост месяца, а может быть и года!
Что вам так понравилось конкретно в этом посте в контексте темы про ООП? Про комерческие вещи тоже обобщать на все случаи жизни наверно не совсем правильно, инвесторы ведь не дураки и привлекают своих специалистов для оценок риска проектов...
В данной статье какого-никакого, но все же профессора есть конкретные логические доводы, на которые не были представлены адекватные контраргументы для обсуждения..
Также очевидно, что простота пограммирования это не всегда зло для проектов...
Лучший пост месяца, а может быть и года! Ренат, почему Вы или Ваша компания не пишите статьи на хабре (компания даже там не зарегистрирована!)? Вы можете так многое сказать, но Ваш опыт узнаешь только урывками из постов. Серъезно, очень злободневно и точно получилось. В качестве иллюстрации к посту: https://habrahabr.ru/post/344356/
Мы работаем на миллионы, а не на 1 000 - 5 000 читателей/просмотров, что обычно набирают статьи на Хабре.
Мы сделали индустриальный стандарт и выпускаем решения, влияющие на весь мир. Зачем нам какой-то Хабр, да еще зажатый в узкой нише российского сегмента.
Что вам так понравилось конкретно в этом посте в контексте темы про ООП? Про комерческие вещи тоже обобщать на все случаи жизни наверно не совсем правильно, инвесторы ведь не дураки и привлекают своих специалистов для оценок риска проектов...
В данной статье какого-никакого, но все же профессора есть конкретные логические доводы, на которые не были представлены адекватные контраргументы для обсуждения..
Также очевидно, что простота пограммирования это не всегда зло для проектов...
Прекращайте дилентантские набросы, пожалуйста.
Будете просто забанены за техническую неграмотность. Нам не нужны в нашем форуме воинствующие невежды.
...
Также очевидно, что простота пограммирования это не всегда зло для проектов...
Есть аксиома: сложность никуда не девается. Следовательно "простота программирования" для пользователя - это перекладывания сложности на компилятор. Сложность как бы перерабатывается компилятором за кулисами, и он, компилятор, уже пытается скрыть любой изврат программиста по принципу "лучше пусть работает хоть как-то чем вообще никак". Владельцем проектом становится уже не программист, а компилятор. Развивать и поддерживать код становится невозможным, потому что уже непонятно что происходит (компилятор как-то собирает, ну и ладно).
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Разговоры на завалинке о ООП
Renat Fatkhullin, 2018.01.17 09:17
...
И никуда от роста сложности не деться. Будет еще сложнее, будет еще больше неграмотных разработчиков, не способных угнаться за требованиями к качеству знаний.
Будет еще больше попыток придумать еще более простые языки, чтобы соответствовать все более понижающему массовому уровню программистов. Все больше софтверных компаний окажутся у разбитого корыта, просто поверив не в ту технологию и проиграв в конкурентной гонке. Просто их конкуренты будут использовать более тяжелые, но эфффективные по продуктовому результату технологии
...
Прекращайте дилентантские набросы, пожалуйста.
Будете просто забанены за техническую неграмотность. Нам не нужны в нашем форуме воинствующие невежды.