Я думаю, у нас разный взгляд на оценку произведений творчества.
Например, я написал код, где встречаются элементы ООП, элементы ФП и какие-то общеизвестные паттерны. Но я назвал это MyVeryOwnParadigm.
Вопрос — корректно ли мне навязывать мнения типа «да ты просто изобрёл велосипед, это тот же ООП»?
Лично я считаю, что автор сам в праве определять как называть и классифицировать его творение. Если он не хочет, чтобы его OOP-like-Paradigm называли ООП, то зачем так делать?
Да откуда угодно могло взяться это название. Я предпочитаю не гадать и не придумывать интерпретации. Если Линус скажет прямо, что он использует ООП в ядре Линукса, я поверю. По умолчанию — не верю. Если кто-то другой про это скажет — тоже не поверю, уж простите меня великодушно.
… limiting your project to C means that people don’t screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don’t screw things up with any idiotic “object model” crap.
Лично мне в этот цитате Линуса сложно заметить любовь к ООП. Конечно, некоторые адепты ООП могут искать в ядре Линукса следы «сквозного ООП», но как мы знаем при желании и при наличии определённой доли фантазии можно найти что угодно и где угодно. А где подтверждение любви к ООП и его использования в Linux Kernel от самого автора?
Автор статьи против ООП умеет формулировать мысли так, что они понятны при прочтении. А люди, у которых есть более-менее опыт в реальной разработке, находят в его примерах отражение реального положения дел на рынке.
У Вас же даже на этапе формулирования мыслей случаются, кхм… exception'ы.
Что касается управления сложностью, то она производится на этапе формулирования требований и дальнейшего проектирования решения. Никакой код не породит столько оверинжиниринга, как изначально неоптимальные требования, которые «не ложатся» ни на потребности бизнеса, ни на технические возможности целевой платформы.
Поэтому в хороших компаниях до программиста доходит оптимальным образом сформулированная задача, которую можно решать как ему больше нравится, пусть даже и на ООП его мечты.
А в плохих компаниях всё превращается в свалку — и документация, и код, и бизнес-процессы в итоге тоже. Кстати, требование в стиле «должно быть готово вчера» — это как раз маркер плохой компании с некомпетентным менеджментом. Программист, идущий на поводу у таких требований, развращает менеджмент и бизнес, демпингует и в итоге сам себя оставляет без штанов и без выходных.
Я не знаю кто минусует. Наверное, те, кто ядро Линукса на С++ переписывают в свободное от школы время)
Я лично полностью согласен с автором. «Плоская» структура С-кода даёт гораздо больше свободы и возможностей, чем С++ или Java аналоги.
Я перешёл на web в 2013-м. Я не никогда не занимался фронтендами для масс маркета. Мне достаточно, чтобы веб-приложение работало на одном браузере.
Но даже если думать о реализации кроссбраузерности через jQuery. Да, он даёт полезный функционал, но при этом также подсовывает очень опасную архитектуру, от которой проект сильно деградирует. Для примитивного лендинга-однодневки это нестрашно. Для сложного web-приложения это большая проблема.
В общем случае одна и та же связка управляющих объектов должна иметь возможность рассматриваться с точки зрения разных иерархий. Своя иерархия под свою задачу. Потому что идеальной иерархии подо всё, что реально нужно на проекте, выбрать нельзя. А создать несколько иерархий не позволяет инструментарий.
Мой заказчик — автор статьи. Он программист и всё прекрасно поймёт. Скажем так, у меня — текстовый квест)
Вот игра в сторе, созданием которой я руководил: crystal slots. Серверная часть написана без ООП, на ней вся игровая и бизнес- логика крутится. DSL для настройки правил игры присутствует. Исходники, конечно, не покажу. Но можете их купить за N x $100k, если есть большое желание.
Да у вас у самого проект не 3Д. Все события происходят в плоскости. Если игрок и монстры хотя бы прыгать начнут… тогда на 3Д будет похоже)
Я лично не буду писать никакой графики и интерактива — ничего этого в описании задачи в оригинальной статье не было. Я выбрал наиболее лаконичный способ реализовать описанное в статье взаимодействие сущностей и вполне себе доволен этим. Мой билд занял 15 минут жизни (вместе с презентацией), весит 301 байт и я могу его демонстрировать.
Ваш билд весит 36 863 414 байт, до сих пор не готов к демонстрации и уже занял как минимум 2 часа на изготовление и презентацию.
Как говорится, «раз пошла такая пьянка — режь последний огурец!»
Если вы реально хотите что-то делать, то начинать обсуждение надо в контексте бюджета. Если вам реально ничего не надо, то не надо тратить время друг друга.
С проблемой отжатия бизнеса я не встречался. Просто тут кому что нравится. Кто-то любит создавать бизнесы, а кто-то — развивать их и жить в уютной операционке. Последние 4 года я работаю не с Россией, а с Ирландией и Великобританией. Там та же история.
Например, я написал код, где встречаются элементы ООП, элементы ФП и какие-то общеизвестные паттерны. Но я назвал это MyVeryOwnParadigm.
Вопрос — корректно ли мне навязывать мнения типа «да ты просто изобрёл велосипед, это тот же ООП»?
Лично я считаю, что автор сам в праве определять как называть и классифицировать его творение. Если он не хочет, чтобы его OOP-like-Paradigm называли ООП, то зачем так делать?
Лично мне в этот цитате Линуса сложно заметить любовь к ООП. Конечно, некоторые адепты ООП могут искать в ядре Линукса следы «сквозного ООП», но как мы знаем при желании и при наличии определённой доли фантазии можно найти что угодно и где угодно. А где подтверждение любви к ООП и его использования в Linux Kernel от самого автора?
У Вас же даже на этапе формулирования мыслей случаются, кхм… exception'ы.
Что касается управления сложностью, то она производится на этапе формулирования требований и дальнейшего проектирования решения. Никакой код не породит столько оверинжиниринга, как изначально неоптимальные требования, которые «не ложатся» ни на потребности бизнеса, ни на технические возможности целевой платформы.
Поэтому в хороших компаниях до программиста доходит оптимальным образом сформулированная задача, которую можно решать как ему больше нравится, пусть даже и на ООП его мечты.
А в плохих компаниях всё превращается в свалку — и документация, и код, и бизнес-процессы в итоге тоже. Кстати, требование в стиле «должно быть готово вчера» — это как раз маркер плохой компании с некомпетентным менеджментом. Программист, идущий на поводу у таких требований, развращает менеджмент и бизнес, демпингует и в итоге сам себя оставляет без штанов и без выходных.
Я лично полностью согласен с автором. «Плоская» структура С-кода даёт гораздо больше свободы и возможностей, чем С++ или Java аналоги.
Это фиаско, бро. Тут даже обсуждать нечего… А я так надеялся (
Я попробовал, мне не понравилось. Если Вам нравится — не смею мешать — наслаждайтесь процессом)
Я перешёл на web в 2013-м. Я не никогда не занимался фронтендами для масс маркета. Мне достаточно, чтобы веб-приложение работало на одном браузере.
Но даже если думать о реализации кроссбраузерности через jQuery. Да, он даёт полезный функционал, но при этом также подсовывает очень опасную архитектуру, от которой проект сильно деградирует. Для примитивного лендинга-однодневки это нестрашно. Для сложного web-приложения это большая проблема.
То, что Вы делаете выводы о качестве проектировании софта, который не видели, говорит лишь о плохом воспитании.
Вот игра в сторе, созданием которой я руководил: crystal slots. Серверная часть написана без ООП, на ней вся игровая и бизнес- логика крутится. DSL для настройки правил игры присутствует. Исходники, конечно, не покажу. Но можете их купить за N x $100k, если есть большое желание.
Я лично не буду писать никакой графики и интерактива — ничего этого в описании задачи в оригинальной статье не было. Я выбрал наиболее лаконичный способ реализовать описанное в статье взаимодействие сущностей и вполне себе доволен этим. Мой билд занял 15 минут жизни (вместе с презентацией), весит 301 байт и я могу его демонстрировать.
Ваш билд весит 36 863 414 байт, до сих пор не готов к демонстрации и уже занял как минимум 2 часа на изготовление и презентацию.
Если вы реально хотите что-то делать, то начинать обсуждение надо в контексте бюджета. Если вам реально ничего не надо, то не надо тратить время друг друга.
Мы тут с Энди уютно общались про векторы, листы и мапы. И вдруг на тебе — Top10000!