Вот тут была недавно ветка про электронные выборы, где мне досталось по первое число за то, что я склонялся к тому, что это хорошо. На что основная масса критиков говорила, что на бумажных выборах могут в теории прийти наблюдатели и всё разрулить, а то, что они по факту не приходят (см. Татарстан или Чечню), это неважно, потому что в теории могут. В данном случае я стану на эту сторону -- если люди голосуют так, они в своём праве, и мне неважно, им телевизор наплёл или ещё кто, так они хотят. Недопуск -- это другое дело, это как раз снижение базы.
Но это всё лирика, самое важное в другом. Вы как человек современного западного мира скорее всего представляете себе "победу общества над государством" как некую пастораль с мельницами и коровушками из книг Линдгрен. Если же посмотреть вокруг, на практике это куда чаще выражается в судах Линча, "убийствах чести", власти парамилитарных групп, "преступник скрылся в Дагестане" и т.п. Когда власти США под конвоем провожали чёрную девочку в когда-то белую школу в рамках уничтожения сегрегации -- это была победа государства над обществом, и вот скажите теперь, что вы в той ситуации были бы на стороне общества.
Здесь необходим баланс, но так человек устроен, что кому-то всегда кажется, что государства слишком много, а кому-то -- что слишком мало, и как бы окей, потому что никакого golden standard у нас всё равно нет.
Немало экономистов считает, что она была существенно усугублена действиями государства.
Например?
Начатые государствами.
Вот это отличная тема для дискуссии. Скажем, первая мировая война была развязана конкретными авторитарными правителями европейских стран при отсутствии каких-либо рычагов влияния на них со стороны людей. Крестьянский сын имел лишь одно право -- пойти на войну и умереть за короля. Формально да, войны развязаны государством, но современное общество ровно в борьбе с такого типа государствами (авторитарными монархиями) и появилось. То есть мы ровно с этим явлением и боремся.
На что слабое государство развело бы руками?
Вот Маск пока ничего, а гугл что -- ну то же, что и Фейсбук. Бесконтрольное влияние на общество без каких-либо официальных возможностей с этим что-то делать. Государство и не делает пока ничего, но вы же прекрасно знаете о желании приравнять соцсети к СМИ, вот был бы интересный прецедент.
Мне этот аргумент не кажется сомнительным по довольно простой причине. Когда у вас натуральное хозяйство и вообще первобытное общество, то государство вроде бы и незачем. Картошка растёт, коровы доятся.
Однако с усложнением жизни появляются ситуации, когда оно само не срабатывает. Ну вот сегодня коронавирус, а до этого была Великая депрессия, например, или мировые войны. То есть довольно странно ожидать, что у нас тут с одной стороны Гугл и Маск, а с другой стороны государство, способное разве что развести руками -- ну да, мы можем вам участкового полицейского прислать, например. То есть государству тоже нужны какие-то рычаги для эффективной работы.
с уровнем доверия в период Эдо,
Ну это же абстрактный разговор или мне надо напомнить, что тогда соцопросы не проводились?
США выглядит для меня более свободной страной,
Мы тут не обсуждаем эти страны вообще. Есть Дания, есть США. И там, и тут имеется некий статус-кво, с которым люди мирятся. Далее обе страны вводят некую довольно схожую меру, а граждане реагируют по-разному.
Если сослаться на исходных авторов, они считают, что проблема в том, что ряд американских ведомств (как NSA) действительно слабо подконтрольны обществу, и поэтому люди действительно имеют основания опасаться, т.к. Гуантанамо и Сноуден, а воз и ныне там.
На это авторы говорят, что сила государства должна возрастать пропорционально способностям общества его контролировать. То есть да, и государство усиливается, и общество тоже. Скажем, расширение базы голосующих -- это про оно самое.
Вот если совсем кратко, то мне кажется, что нынешних компьютеров с головой хватает для нужд инди-разработчиков. Иными словами, MonoBehavior, C#, сборка мусора и прочие тормоза -- ну и ладно, сгодится. Бывает, появляется что-то жрущее процессор типа хитрых шейдеров или какой-то умной физики, чтобы волосы там или юбочка развевались красиво, но на этом всё. Поэтому разговоры про миллионы юнитов и летящих пуль и прочую голливудскую красоту -- это всё не для простых смертных. Могу ошибаться, конечно, но так мне видится.
Соответственно, затронутые автором проблемы -- это про AAA проекты фирм типа EA или UbiSoft, где как раз миллионы юнитов, графика как в блокбастере, вылизанный мир и т.д. и т.п. Ну так и пусть со всей этой радостью, гм, имеют дело, за такие-то деньги. Выдавим скупую слезу по их тяжёлой участи.
В данном случае это всё некоторый оффтопик, поэтому глубоко и не лезу. Но мы ведь в каком-то смысле воспринимаем государство, в котором выросли, как некоторое "статус-кво", относительно которого мы измеряем остальное. Для россиянина 2021 -- это "цифровой гулаг" относительно, не знаю, 2000го года, например. А для Спарты и даже СССР это было бы общество неслыханных свобод, так что надо хотя бы напоминать себе, что наша точка отсчёта по сути выбрана произвольно.
Вот просто в рамках дискуссии предлагаю вам такое соображение, почерпнутое из книги The Narrow Corridor. Там авторы пишут, что после 9/11 в США и в Дании примерно одинаково закрутили гайки в плане возможностей всяких силовых структур, и при этом в США было гораздо больше протестов и возмущений по этому поводу.
Авторы делают вывод, что это не потому, что датчанам всё норм, а потому что они гораздо больше доверяют своему правительству и видят прозрачность принимаемых решений и полную отчётность по результатам применения расширившейся власти.
То есть сильное государство с большими возможностями -- это не зло, это именно что большие возможности по решению проблем, это хорошо. А если вы беспокоитесь тенденций цифрового гулага, то это вопросы не к ковиду, а к тому, что некоторые государства устроены непрозрачно и неподконтрольно. Если японцы в целом доверяют своему государству, с чего опасаться гулага? Пусть боятся те, где власть перекошена, ну и мрут заодно от ковида.
Ну вот наше (японское) правительство бодро рапортует успехи. И я думаю, что успехи действительно очень значительные, если смотреть статистику. А методы очень просты -- изолированные локдауны в очагах инфекции + чёткое отслеживание путей распространения болезни. Истоки чуть ли не каждого заражения трассируются и все причастные изолируются.
Вообще, конечно, очень интересно -- всё-таки полноценный DSL язык с достаточно глубокой проработкой темы и явно не "на коленке" сделанный. Но штука специализированная, поэтому со стороны трудно предложить толковую реплику кроме "спасибо за статью". Но всё же слегка есть ощущение "начали за здравие..." Например, есть рассуждения о том, что в C++ с массивами не очень, нельзя выполнить глубокую оптимизацию вложенных циклов и т.п. Но в конечном итоге всё равно по бенчмаркам не выиграли же.
Ну то есть листинги на Питоне вас не смутили :) Аргументы я стараюсь воспроизводить аккуратно, формулировки могут отличаться. В оригинале -- "spread out in text space".
Именно это ограничение заставляет нас заниматься логической декомпозицией системы так, чтобы на каждом уровне все укладывалось в те самые 7 объектов
Да, конечно, согласен.
Но на практике так не работает, вероятно потому, что самим разработчикам это не так, чтобы очень сильно нужно.
Ну вот меня это очень расстраивает, хотя в физическом мире тоже по-разному, достаточно вспомнить всякие "рейтинги ремонтопригодности" и т.п. Но всё же там обычно компоненты относительно легко вынимаются из системы и спроектированы так, чтобы мы не лезли в их внутренности в обход интерфейса.
Можно написать программу именно так, как мы обсуждаем: каждый каталог на диске -- это "компонент", причём в одной папке будет не более 5-7 компонентов, и каждый компонент будет общаться только с непосредственными "родителями", "потомками" и "соседями". Надо попробовать сделать что-нибудь хотя бы среднего размера в таком стиле и посмотреть, что выйдет.
Но если я вижу подобного рода чужую программу, то начинается паника, т.к. уже догадываюсь, что буду постоянно нырять в самые глубины глубин. А про "сложно" -- ну да, the hardest problem is naming things.
Штука в том, что есть сайты, где раньше уголок был отмечен, а теперь нет. В качестве примера -- окно описания приложения на Appstore (appstoreconnect.apple.com). В нём всего пять строк (куда смотрит Apple?!), а теперь и растянуть нельзя.
Пользуясь случаем, хотел спросить об одной неприятности, которую заметил недавно, и не могу сказать, когда она появилась. Многострочные поля ввода (texarea) раньше везде можно было растягивать, перетаскивая мышкой правый нижний угол. А теперь нельзя, если поле маленькое -- страдай. Это by design или что-то сломалось?
На самом деле, Дейкстре, скорее всего, не повезло оказаться среди "хороших программистов на фортране которые могут писать на фортране на любом языке"
Насколько я понимаю, исходное высказывание не имело особо пафосного характера типа борьбы с мельницами или чего-то такого. Дейкстра начинает с туманного введения вроде такого: "я уже давно был уверен, что goto это плохо, но вот недавние разговоры заставили собраться с мыслями и изложить на бумаге..." Короче говоря, да, это совершенно современный формат для блог-поста типа "почему я бла-бла". Но, видимо, многим приходилось вступать в подобные дискуссии, и было проще сослаться на готовую статью, чем продумывать аргументацию.
(Не получается это на русский перевести адекватно)
Ну так это всё друг наш Аристотель придумал, и вообще отдельная дискуссия, насколько эти категории точно отражают ситуацию.
чтобы эти слои плодить, вместо того, чтобы думать в обратном направлении.
Я в последнее время на досуге обдумываю то, что уже упомянул в комментарии выше. Если вы пишете не FizzBuzz, а что-нибудь относительно большое, то рост количества компонентов перестаёт быть такой большой проблемой. Потому что если в энциклопедии один том, я могу её прочесть, а если двадцать -- то уже всё равно, двадцать или сорок, на первый план выходит организация. И ваше недовольство слоями состоит вызвано не их наличием, а тем, что вам приходится иметь с ними дело. То есть несмотря на всю архитектуру, мы всё равно видим все компоненты, и как-то приходится держать их в голове.
(Сорри за простыню, хорошо сократить -- тоже работа). Поголовно все книги об архитектуре говорят, например, что если объекты связаны в слишком плотную сеть (т.е. количество связей велико) -- это плохо, т.к. сложно связи держать в голове. Это очевидно, но мало кто пишет о том, что само наличие класса MyClass засоряет "ментальное" пространство имён: я не знаю, кто этот MyClass использует, и даже если количество фактических связей мало, количество потенциальных связей растёт с каждой новой сущностью.
Искусственные объекты реального мира инкапсулированы гораздо лучше. В микросхеме может быть масса транзисторов, но у меня не просто нет способа до них достучаться, но я даже могу не знать об их наличии -- чистый black box. Или какая-нибудь кофеварка: внутри масса сообщающихся механических частей, но для меня есть только отсек для зёрен, бак для воды и кнопки на панели. Даже если я залезу вовнутрь, то увижу, например, мельницу для зёрен, которая точно так же будет black-box'ом, и её внутренние части не засорят моё ментальное поле, пока я физически её не раскручу.
Вот мне кажется, что в идеале софт можно было бы устроить так. Однако на практике всё равно всё торчит наружу, и если автор даже засунул какой-то компонент на третий уровень структуры каталогов, всё равно это ничего не гарантирует.
Ну, мне кажется, тут надо разделять. Фраза "под предлогом тестабельности" мне не близка, потому что это не "предлог", а вполне себе внятно определённое и полезное свойство архитектуры. А вот дальнейшее -- ну да, более сложный инструмент требует более высокого уровня от разработчика. В идеале и имена внятные, и ответственность понятная, а главное -- это "матрёшечная" архитектура, при которой у нас в принципе немного связей между компонентами разного уровня.
С goto логика Дейкстры проста: в 99% случаев это вредно, поэтому лучше выпилить вообще. В наши времена никакое ядро линукса даже близко не стоит по количеству используемых goto с типичным кодом того времени, так что по факту всё более-менее ОК, и мы тут обсуждаем какие-то частности типа стоит ли выходить по goto из вложенного цикла. Это хороший знак: в целом с отказом никто не спорит, речь об отдельных моментах.
А с архитектурой вида "прокладка на прокладке сидит и прокладкой погоняет" непонятно, что делать, потому что тут и решения простого нет. От чего конкретно можно призвать отказываться? На сегодняшний день мне кажется, что практически во всех современных языках слабо развиты средства изоляции компонентов. То есть я бы в идеале хотел иметь возможность написать "матрёшку" -- чтобы компонент имел чёткий интерфейс, и жил на каком-то "этаже", общаясь исключительно с соседями на этаж выше и ниже. Но по факту мы имеем что-то вроде пакетов Java или Python, в которые можно залезть отовсюду, а сама их организация по подкаталогам тоже не очень удобна.
Я сам склоняюсь к "тащить и не пущать". Особенно в случае C++, где даже если вы очень грамотно ставите переход на конец функции (и в этом случае вроде бы это просто "хорошо структурированный break"), остаются проблемы, например, с выделением ресурсов, где конструктор чего-то сделал, а деструктор не сработал из-за goto и тому подобные приколы (иными словами, даже невинная конструкция типа a = b; может выделять ресурс где-то за кулисами).
Наверно, проще всего воспринимать ситуацию, описанную выше, как code smell. Грубо говоря, с какой радости у нас два цикла в рамках одной функции, да ещё с прыжками. Можно ведь, например, так:
Я после долгих раздумий пришёл вот к какому выводу. Если у вас в программе два-три-четыре экрана текста, то вообще не имеет значения, как всё это устроено. Это значит, что программа предназначена для того, чтобы её прочитали целиком за раз и поняли.
Если же вы пишете что-то относительно большое, то уже не имеет значения, у вас 500 функций или 1500 -- всё равно читающий не будет всё это за раз понимать, и стало быть, если вы опасаетесь засорения пространства имён, займитесь лучше хорошей организацией этого самого пространства.
Ну вот представьте себе что-то вроде библиотеки классов Java или Qt: вас очень волнует, сколько там реально функций? Их всё равно слишком много. Что вас должно беспокоить -- так это насколько удобно в системе ориентироваться.
Таким образом, если вы предполагаете, что система будет больше "размера на один укус", лучше организовывать её структурированно. Иначе вы можете получить худшее из двух миров: и функций будет слишком много на одно чтение, и каждая окажется слишком сложной для быстрого понимания.
Обратите внимание, что в ответе "завернуть метод и написать return" заключается больше, чем желание просто "победить недостаток языка", который не позволяет сделать break из вложенного цикла.
Вы хотите выйти из цикла, чтобы делать что-то ещё. А зачем?
Functions should do one thing. They should do it well. They should do it only.
(R. Martin. Clean Code, Ch. 3)
Нашли белый пиксель? Ну и прекрасно, работа функции должна на этом заканчиваться.
Да, но с другой стороны, существовал уже ALGOL 60, и велась работа над проектом ALGOL X (который станет ALGOL 68). Так что идеи о том, в какую сторону двигаться, активно обсуждались, а членами группы ALGOL были, в частности, Дейкстра и Вирт.
Не могу сходу ссылку привести, но в паре кликов отсюда (где описываются трюки похлеще здешних) говорилось, что отследить UB для компилятора -- это штука технически почти неосуществимая. Современный тулчейн типа llvm устроен так, что отдельные оптимизации и прочие трюки существуют во многом независимо и работают с промежуточными представлениями, которые уже очень далеко отстоят от исходного кода. Поэтому отделить "вот эту кашу, которая получилась из рукописного кода" от "вон той каши, что вышла из раскрытия макросов, ассемблерных вставок и всяких прагм" уже никак не выходит.
Вот тут была недавно ветка про электронные выборы, где мне досталось по первое число за то, что я склонялся к тому, что это хорошо. На что основная масса критиков говорила, что на бумажных выборах могут в теории прийти наблюдатели и всё разрулить, а то, что они по факту не приходят (см. Татарстан или Чечню), это неважно, потому что в теории могут. В данном случае я стану на эту сторону -- если люди голосуют так, они в своём праве, и мне неважно, им телевизор наплёл или ещё кто, так они хотят. Недопуск -- это другое дело, это как раз снижение базы.
Но это всё лирика, самое важное в другом. Вы как человек современного западного мира скорее всего представляете себе "победу общества над государством" как некую пастораль с мельницами и коровушками из книг Линдгрен. Если же посмотреть вокруг, на практике это куда чаще выражается в судах Линча, "убийствах чести", власти парамилитарных групп, "преступник скрылся в Дагестане" и т.п. Когда власти США под конвоем провожали чёрную девочку в когда-то белую школу в рамках уничтожения сегрегации -- это была победа государства над обществом, и вот скажите теперь, что вы в той ситуации были бы на стороне общества.
Здесь необходим баланс, но так человек устроен, что кому-то всегда кажется, что государства слишком много, а кому-то -- что слишком мало, и как бы окей, потому что никакого golden standard у нас всё равно нет.
Например?
Вот это отличная тема для дискуссии. Скажем, первая мировая война была развязана конкретными авторитарными правителями европейских стран при отсутствии каких-либо рычагов влияния на них со стороны людей. Крестьянский сын имел лишь одно право -- пойти на войну и умереть за короля. Формально да, войны развязаны государством, но современное общество ровно в борьбе с такого типа государствами (авторитарными монархиями) и появилось. То есть мы ровно с этим явлением и боремся.
Вот Маск пока ничего, а гугл что -- ну то же, что и Фейсбук. Бесконтрольное влияние на общество без каких-либо официальных возможностей с этим что-то делать. Государство и не делает пока ничего, но вы же прекрасно знаете о желании приравнять соцсети к СМИ, вот был бы интересный прецедент.
Мне этот аргумент не кажется сомнительным по довольно простой причине. Когда у вас натуральное хозяйство и вообще первобытное общество, то государство вроде бы и незачем. Картошка растёт, коровы доятся.
Однако с усложнением жизни появляются ситуации, когда оно само не срабатывает. Ну вот сегодня коронавирус, а до этого была Великая депрессия, например, или мировые войны. То есть довольно странно ожидать, что у нас тут с одной стороны Гугл и Маск, а с другой стороны государство, способное разве что развести руками -- ну да, мы можем вам участкового полицейского прислать, например. То есть государству тоже нужны какие-то рычаги для эффективной работы.
Ну это же абстрактный разговор или мне надо напомнить, что тогда соцопросы не проводились?
Мы тут не обсуждаем эти страны вообще. Есть Дания, есть США. И там, и тут имеется некий статус-кво, с которым люди мирятся. Далее обе страны вводят некую довольно схожую меру, а граждане реагируют по-разному.
Если сослаться на исходных авторов, они считают, что проблема в том, что ряд американских ведомств (как NSA) действительно слабо подконтрольны обществу, и поэтому люди действительно имеют основания опасаться, т.к. Гуантанамо и Сноуден, а воз и ныне там.
На это авторы говорят, что сила государства должна возрастать пропорционально способностям общества его контролировать. То есть да, и государство усиливается, и общество тоже. Скажем, расширение базы голосующих -- это про оно самое.
Вот если совсем кратко, то мне кажется, что нынешних компьютеров с головой хватает для нужд инди-разработчиков. Иными словами, MonoBehavior, C#, сборка мусора и прочие тормоза -- ну и ладно, сгодится. Бывает, появляется что-то жрущее процессор типа хитрых шейдеров или какой-то умной физики, чтобы волосы там или юбочка развевались красиво, но на этом всё. Поэтому разговоры про миллионы юнитов и летящих пуль и прочую голливудскую красоту -- это всё не для простых смертных. Могу ошибаться, конечно, но так мне видится.
Соответственно, затронутые автором проблемы -- это про AAA проекты фирм типа EA или UbiSoft, где как раз миллионы юнитов, графика как в блокбастере, вылизанный мир и т.д. и т.п. Ну так и пусть со всей этой радостью, гм, имеют дело, за такие-то деньги. Выдавим скупую слезу по их тяжёлой участи.
В данном случае это всё некоторый оффтопик, поэтому глубоко и не лезу. Но мы ведь в каком-то смысле воспринимаем государство, в котором выросли, как некоторое "статус-кво", относительно которого мы измеряем остальное. Для россиянина 2021 -- это "цифровой гулаг" относительно, не знаю, 2000го года, например. А для Спарты и даже СССР это было бы общество неслыханных свобод, так что надо хотя бы напоминать себе, что наша точка отсчёта по сути выбрана произвольно.
Вот просто в рамках дискуссии предлагаю вам такое соображение, почерпнутое из книги The Narrow Corridor. Там авторы пишут, что после 9/11 в США и в Дании примерно одинаково закрутили гайки в плане возможностей всяких силовых структур, и при этом в США было гораздо больше протестов и возмущений по этому поводу.
Авторы делают вывод, что это не потому, что датчанам всё норм, а потому что они гораздо больше доверяют своему правительству и видят прозрачность принимаемых решений и полную отчётность по результатам применения расширившейся власти.
То есть сильное государство с большими возможностями -- это не зло, это именно что большие возможности по решению проблем, это хорошо. А если вы беспокоитесь тенденций цифрового гулага, то это вопросы не к ковиду, а к тому, что некоторые государства устроены непрозрачно и неподконтрольно. Если японцы в целом доверяют своему государству, с чего опасаться гулага? Пусть боятся те, где власть перекошена, ну и мрут заодно от ковида.
Ну вот наше (японское) правительство бодро рапортует успехи. И я думаю, что успехи действительно очень значительные, если смотреть статистику. А методы очень просты -- изолированные локдауны в очагах инфекции + чёткое отслеживание путей распространения болезни. Истоки чуть ли не каждого заражения трассируются и все причастные изолируются.
Вообще, конечно, очень интересно -- всё-таки полноценный DSL язык с достаточно глубокой проработкой темы и явно не "на коленке" сделанный. Но штука специализированная, поэтому со стороны трудно предложить толковую реплику кроме "спасибо за статью". Но всё же слегка есть ощущение "начали за здравие..." Например, есть рассуждения о том, что в C++ с массивами не очень, нельзя выполнить глубокую оптимизацию вложенных циклов и т.п. Но в конечном итоге всё равно по бенчмаркам не выиграли же.
Ну то есть листинги на Питоне вас не смутили :) Аргументы я стараюсь воспроизводить аккуратно, формулировки могут отличаться. В оригинале -- "spread out in text space".
Да, конечно, согласен.
Ну вот меня это очень расстраивает, хотя в физическом мире тоже по-разному, достаточно вспомнить всякие "рейтинги ремонтопригодности" и т.п. Но всё же там обычно компоненты относительно легко вынимаются из системы и спроектированы так, чтобы мы не лезли в их внутренности в обход интерфейса.
Можно написать программу именно так, как мы обсуждаем: каждый каталог на диске -- это "компонент", причём в одной папке будет не более 5-7 компонентов, и каждый компонент будет общаться только с непосредственными "родителями", "потомками" и "соседями". Надо попробовать сделать что-нибудь хотя бы среднего размера в таком стиле и посмотреть, что выйдет.
Но если я вижу подобного рода чужую программу, то начинается паника, т.к. уже догадываюсь, что буду постоянно нырять в самые глубины глубин. А про "сложно" -- ну да, the hardest problem is naming things.
Штука в том, что есть сайты, где раньше уголок был отмечен, а теперь нет. В качестве примера -- окно описания приложения на Appstore (appstoreconnect.apple.com). В нём всего пять строк (куда смотрит Apple?!), а теперь и растянуть нельзя.
Пользуясь случаем, хотел спросить об одной неприятности, которую заметил недавно, и не могу сказать, когда она появилась. Многострочные поля ввода (texarea) раньше везде можно было растягивать, перетаскивая мышкой правый нижний угол. А теперь нельзя, если поле маленькое -- страдай. Это by design или что-то сломалось?
Насколько я понимаю, исходное высказывание не имело особо пафосного характера типа борьбы с мельницами или чего-то такого. Дейкстра начинает с туманного введения вроде такого: "я уже давно был уверен, что goto это плохо, но вот недавние разговоры заставили собраться с мыслями и изложить на бумаге..." Короче говоря, да, это совершенно современный формат для блог-поста типа "почему я бла-бла". Но, видимо, многим приходилось вступать в подобные дискуссии, и было проще сослаться на готовую статью, чем продумывать аргументацию.
Ну так это всё друг наш Аристотель придумал, и вообще отдельная дискуссия, насколько эти категории точно отражают ситуацию.
Я в последнее время на досуге обдумываю то, что уже упомянул в комментарии выше. Если вы пишете не FizzBuzz, а что-нибудь относительно большое, то рост количества компонентов перестаёт быть такой большой проблемой. Потому что если в энциклопедии один том, я могу её прочесть, а если двадцать -- то уже всё равно, двадцать или сорок, на первый план выходит организация. И ваше недовольство слоями состоит вызвано не их наличием, а тем, что вам приходится иметь с ними дело. То есть несмотря на всю архитектуру, мы всё равно видим все компоненты, и как-то приходится держать их в голове.
(Сорри за простыню, хорошо сократить -- тоже работа). Поголовно все книги об архитектуре говорят, например, что если объекты связаны в слишком плотную сеть (т.е. количество связей велико) -- это плохо, т.к. сложно связи держать в голове. Это очевидно, но мало кто пишет о том, что само наличие класса MyClass засоряет "ментальное" пространство имён: я не знаю, кто этот MyClass использует, и даже если количество фактических связей мало, количество потенциальных связей растёт с каждой новой сущностью.
Искусственные объекты реального мира инкапсулированы гораздо лучше. В микросхеме может быть масса транзисторов, но у меня не просто нет способа до них достучаться, но я даже могу не знать об их наличии -- чистый black box. Или какая-нибудь кофеварка: внутри масса сообщающихся механических частей, но для меня есть только отсек для зёрен, бак для воды и кнопки на панели. Даже если я залезу вовнутрь, то увижу, например, мельницу для зёрен, которая точно так же будет black-box'ом, и её внутренние части не засорят моё ментальное поле, пока я физически её не раскручу.
Вот мне кажется, что в идеале софт можно было бы устроить так. Однако на практике всё равно всё торчит наружу, и если автор даже засунул какой-то компонент на третий уровень структуры каталогов, всё равно это ничего не гарантирует.
Ну, мне кажется, тут надо разделять. Фраза "под предлогом тестабельности" мне не близка, потому что это не "предлог", а вполне себе внятно определённое и полезное свойство архитектуры. А вот дальнейшее -- ну да, более сложный инструмент требует более высокого уровня от разработчика. В идеале и имена внятные, и ответственность понятная, а главное -- это "матрёшечная" архитектура, при которой у нас в принципе немного связей между компонентами разного уровня.
С goto логика Дейкстры проста: в 99% случаев это вредно, поэтому лучше выпилить вообще. В наши времена никакое ядро линукса даже близко не стоит по количеству используемых goto с типичным кодом того времени, так что по факту всё более-менее ОК, и мы тут обсуждаем какие-то частности типа стоит ли выходить по goto из вложенного цикла. Это хороший знак: в целом с отказом никто не спорит, речь об отдельных моментах.
А с архитектурой вида "прокладка на прокладке сидит и прокладкой погоняет" непонятно, что делать, потому что тут и решения простого нет. От чего конкретно можно призвать отказываться? На сегодняшний день мне кажется, что практически во всех современных языках слабо развиты средства изоляции компонентов. То есть я бы в идеале хотел иметь возможность написать "матрёшку" -- чтобы компонент имел чёткий интерфейс, и жил на каком-то "этаже", общаясь исключительно с соседями на этаж выше и ниже. Но по факту мы имеем что-то вроде пакетов Java или Python, в которые можно залезть отовсюду, а сама их организация по подкаталогам тоже не очень удобна.
Я сам склоняюсь к "тащить и не пущать". Особенно в случае C++, где даже если вы очень грамотно ставите переход на конец функции (и в этом случае вроде бы это просто "хорошо структурированный break"), остаются проблемы, например, с выделением ресурсов, где конструктор чего-то сделал, а деструктор не сработал из-за goto и тому подобные приколы (иными словами, даже невинная конструкция типа a = b; может выделять ресурс где-то за кулисами).
Наверно, проще всего воспринимать ситуацию, описанную выше, как code smell. Грубо говоря, с какой радости у нас два цикла в рамках одной функции, да ещё с прыжками. Можно ведь, например, так:
Оно и читается лучше: если обе функции закончились хорошо, то эпилог, а ресурсы освобождаем в любом случае.
Я после долгих раздумий пришёл вот к какому выводу. Если у вас в программе два-три-четыре экрана текста, то вообще не имеет значения, как всё это устроено. Это значит, что программа предназначена для того, чтобы её прочитали целиком за раз и поняли.
Если же вы пишете что-то относительно большое, то уже не имеет значения, у вас 500 функций или 1500 -- всё равно читающий не будет всё это за раз понимать, и стало быть, если вы опасаетесь засорения пространства имён, займитесь лучше хорошей организацией этого самого пространства.
Ну вот представьте себе что-то вроде библиотеки классов Java или Qt: вас очень волнует, сколько там реально функций? Их всё равно слишком много. Что вас должно беспокоить -- так это насколько удобно в системе ориентироваться.
Таким образом, если вы предполагаете, что система будет больше "размера на один укус", лучше организовывать её структурированно. Иначе вы можете получить худшее из двух миров: и функций будет слишком много на одно чтение, и каждая окажется слишком сложной для быстрого понимания.
Обратите внимание, что в ответе "завернуть метод и написать return" заключается больше, чем желание просто "победить недостаток языка", который не позволяет сделать break из вложенного цикла.
Вы хотите выйти из цикла, чтобы делать что-то ещё. А зачем?
Нашли белый пиксель? Ну и прекрасно, работа функции должна на этом заканчиваться.
Да, но с другой стороны, существовал уже ALGOL 60, и велась работа над проектом ALGOL X (который станет ALGOL 68). Так что идеи о том, в какую сторону двигаться, активно обсуждались, а членами группы ALGOL были, в частности, Дейкстра и Вирт.
Не могу сходу ссылку привести, но в паре кликов отсюда (где описываются трюки похлеще здешних) говорилось, что отследить UB для компилятора -- это штука технически почти неосуществимая. Современный тулчейн типа llvm устроен так, что отдельные оптимизации и прочие трюки существуют во многом независимо и работают с промежуточными представлениями, которые уже очень далеко отстоят от исходного кода. Поэтому отделить "вот эту кашу, которая получилась из рукописного кода" от "вон той каши, что вышла из раскрытия макросов, ассемблерных вставок и всяких прагм" уже никак не выходит.