Попробуйте для примера написать какую-нибудь простую задачку а-ля «Сапер», потом прокачаться в использовании возможностей IDE, а потом написать еще раз — разница во временных затратах будет весьма значительная.
Очень часто раздумие над тем, как формально соответствовать каким-либо признакам, отнимает больше времени, чем собствено написание кода. Поэтому написание хорошего кода, определение ошибок «на глаз», использование всех возможностей IDE, горячих главиш, макросов и т.д. должно войти в привычку. И именно эти привычки окупают вложения в конечном счете.
Поэтому советую отталкиваться от цели. Если цель Junior'а вначале — научиться писать качественный код, и ему действительно необходимо следовать этим принципам, чтобы привыкнуть, то для Senior'а не первое место выходят оптимальность затрат и легкость поддержки. И на этом уровне уже не важно, циклом обходить коллекцию или завернуть в filter-map — легкость поддежки будет одинаковая. Поэтому естественным образом выбирается второй вариант — писать меньше и читать проще.
И пока midlle-разработчики определяются с тем, какой подход лучше, senior'ы пишут framework'и и plugin'ы для IDE, которые позволят еще ускорить воплощение разработческой мысли (не только в насписании кода, а вообще во всем процессе разработки).
Автор приобрел опыт самостоятельного нешаблонного решения задачи
В таком случае не стоило браться за реализацию.
Навык определения, когда нужно решать нестандартным способом, а когда — по шаблону, нужен гораздо чаще, чем поиск нестандартного алгоритма.
И еще: база знаний об известных алгоритмах составляет инструментарий для создания более совершенных и сложных нестандартных алгоритмов. И банальное знание того, какие бывают алгоритмы и что они делают, оказывается на практике важнее, чем умение придумать нестандартное решение.
Да и под «нестандартным решением» обычно скрывается комбинация более мелких стандартных решений. :-)
Да, парадокс множества всех множеств порождается неформальностью определения множества.
Если дать формальное определение, то понятие «множество всех множеств» просто нельзя будет описать, т.е. будет противоречить определению множества. IMHO.
В конце статьи я немного поплыл в абстракциях. :-)
Надо будет еще раз внимательнее расставить точки над i.
P.S. Было бы неплохо в начале статьи (или отдельной статьей) предоставлять глоссарий терминов, которые вы же сами определяли. Мне в свое время очень помогало в освоении универовской программы. :-)
Как только вам нужно смотреть в реализации объекта, чтобы понять, как компоновать его с другими объектами, вы потеряли достоинства ООП.
К сожалению, возможность написания функций с side effect вынуждает смотреть в реализацию объекта, ибо документация может врать или не описывать некоторые use case'ы. И это верно как для ООП, так и для функционального подхода.
Думаю, тут важно упомянуть, что эксперт, находясь в D, четко понимает границы, в которых он является экспертом, и всегда видит, когда ситуация выходит за эти границы.
Если не видит — он еще не в D.
эксперт в состоянии привести цепочку выводов, почему он пришел к такому результату
Именно так.
Если не может — это A, а не D.
Причем независимо от того, поступает он правильно или нет в данном конкретном случае (и, возможно, в ряде других случаев).
IMHO, не совсем правильно описано, что такое «неосознанная компетентность».
По-моему правильно будет сформулировать так: «Это состояние, в котором человеку нет нужды вспоминать промежуточные шаги для принятия правильных решений, но при необходимости он всегда может это сделать.»
Многое становится понятным, если исходить из целей, которых хочется достичь.
Тогда многое встает на свои места, даже холивары по поводу code style. :-)
Для примеров лучше использовать код попроще и попонятнее — в три цикла.
Для реальности — нужно мерить, сравнивать и оптимизировать обоснованно.
И уж никак не предлагать такой код в качестве учебных примеров.
Очень часто раздумие над тем, как формально соответствовать каким-либо признакам, отнимает больше времени, чем собствено написание кода. Поэтому написание хорошего кода, определение ошибок «на глаз», использование всех возможностей IDE, горячих главиш, макросов и т.д. должно войти в привычку. И именно эти привычки окупают вложения в конечном счете.
Поэтому советую отталкиваться от цели. Если цель Junior'а вначале — научиться писать качественный код, и ему действительно необходимо следовать этим принципам, чтобы привыкнуть, то для Senior'а не первое место выходят оптимальность затрат и легкость поддержки. И на этом уровне уже не важно, циклом обходить коллекцию или завернуть в filter-map — легкость поддежки будет одинаковая. Поэтому естественным образом выбирается второй вариант — писать меньше и читать проще.
И пока midlle-разработчики определяются с тем, какой подход лучше, senior'ы пишут framework'и и plugin'ы для IDE, которые позволят еще ускорить воплощение разработческой мысли (не только в насписании кода, а вообще во всем процессе разработки).
Фиксация на существенном, несущественное урезано или отсутствует.
В таком случае не стоило браться за реализацию.
Навык определения, когда нужно решать нестандартным способом, а когда — по шаблону, нужен гораздо чаще, чем поиск нестандартного алгоритма.
И еще: база знаний об известных алгоритмах составляет инструментарий для создания более совершенных и сложных нестандартных алгоритмов. И банальное знание того, какие бывают алгоритмы и что они делают, оказывается на практике важнее, чем умение придумать нестандартное решение.
Да и под «нестандартным решением» обычно скрывается комбинация более мелких стандартных решений. :-)
Если дать формальное определение, то понятие «множество всех множеств» просто нельзя будет описать, т.е. будет противоречить определению множества. IMHO.
Надо будет еще раз внимательнее расставить точки над i.
P.S. Было бы неплохо в начале статьи (или отдельной статьей) предоставлять глоссарий терминов, которые вы же сами определяли. Мне в свое время очень помогало в освоении универовской программы. :-)
К сожалению, возможность написания функций с side effect вынуждает смотреть в реализацию объекта, ибо документация может врать или не описывать некоторые use case'ы. И это верно как для ООП, так и для функционального подхода.
Но это монтировать долго и нудно. :-)
Если не видит — он еще не в D.
Именно так.
Если не может — это A, а не D.
Причем независимо от того, поступает он правильно или нет в данном конкретном случае (и, возможно, в ряде других случаев).
По-моему правильно будет сформулировать так: «Это состояние, в котором человеку нет нужды вспоминать промежуточные шаги для принятия правильных решений, но при необходимости он всегда может это сделать.»
Тогда многое встает на свои места, даже холивары по поводу code style. :-)
Так где вы находитесь?.. :-)
Для реальности — нужно мерить, сравнивать и оптимизировать обоснованно.
И уж никак не предлагать такой код в качестве учебных примеров.
P.S. Это все IMHO, забейте — статья отличная! :-)