Ну именно в случае MS у них есть достаточная сила форсировать переход на passkeys как минимум для тех групп, которые считаются ими одновременно vulnerable (каак етта паа рюски - подверженные? незащищённые?) и чей взлом будет дорого стоить - а это сотрудники крупных корпораций. Заставят накупить физических ключей (или хотя бы ставить приложения на телефоны) и авторизоваться ими, отработают подходы и далее будут делать то же с домохозяйками. В это я вполне верю. Я не говорю, что верю (пример с W10 - да, помню, хорош), но хотя бы частично они это будут вводить. И, возможно, это даже хорошо. Не будет пароля "Маша1952" на всём подряд.
Ваша мысль понятна, но такая надменность без упоминания, например, Yescrypt, который сейчас предпочитается массой дистрибутивов (а Bcrypt, в среднем, считается уже устарелым), или факта, что "пароль по sha-512" в юниксовом crypt это не голый SHA-512, а некий метод его применения туеву хучу тысяч раз - показывает, что и вам лучше освежить знания.
Со спецсимволами в пароле есть ещё проблема: на других раскладках клавиатуры можно просто не найти, где набирается какой-нибудь '#' или '/'. И если для латиницы ещё более-менее есть шанс вспомнить считалочку QWERTYUIOP..., то для прочих символов - ой.
Далее они вытаскивают из него диск и быстренько получают все мои ключи и логинятся ко всем моим серверам. Всё, конец истории.
На ssh ключи можно навешивать свои пароли (они там зовутся passphrase), и если ваш лаптоп получили без вас, а пароль был установлен на ключе, то они ничего не смогут. А если с вами, то уже без разницы, будете вы выдавать пароли напрямую к серверу или к ключам, когда паяльник уже нагрет.
Зато, если вас утащили без лаптопа, то даже с passphrases без ключа они не доберутся.
Можете мне рассказать, в каком месте ssh-ключи увеличили мою безопасности?
Вот в этом месте и увеличили. Такой себе 2FA, хоть и полностью со стороны клиента.
непровославный ГитХаб уже давно от паролей отказался при работе с репозиториями, только ключи.
Пароли там есть, но они называются токенами, имеют вид ghp_Длинна1Стр0каБуквИЦифр и их надо специально создавать. У меня такие есть, использую, где ssh ключ не подходит.
Может, Git и не идеальный, но лучше ничего пока не придумали.
Именно что переписка старого, но ещё не вошедшего в публичные ветки, в нём сделана лучше всего из всех аналогов; я бы даже сказал, в нём единственном она сделана хоть как-то нормально. И по процессам в том же LKML это хорошо видно. Если что-то сделано как цепочка коммитов и в какой-нибудь седьмой версии оно принято - то там коммиты и атомарные, и хорошо описанные.
А вот к вопросу о "сторителлинге" это имеет косвенное отношение - если не противоположное. Рассказывать на уже почищенной истории это, конечно, много лоска, но даёт ложное ощущение, что у авторов таких историй всё получается с первого раза и в шоколаде. А это отпугивает тех, кто потом сталкивается с реальными сложностями, после первой пары шишек от граблей. Если рассказывать, то вместе со всеми запутанностями, отступлениями и повторными наступлениями, результатом с 10-й (в лучшем случае) попытки - то есть как раз красивая история вредна, а нужна честная.
(Вариант HOWTO по финальному результату - это тоже нужно, но это не сторителлинг. Но я в такие хаутушки добавляю, по своему опыту, все существенные грабли, по которым я потоптался.)
Хм, таки я ещё не видел тут статей в стиле "ответ на полемику" с цитатами и своими комментариями. Интересно. В других местах бывало, но там часто отделение ветки обсуждения в отдельную тему.
По отдельным пунктам:
Настоящим ООП языком был и остается только ST.
Это очень частая позиция, но, с учётом того, сколько ООП занимает в современном программировании, напоминает позицию типа "вот сосна - настоящее дерево, а эта ваша трава - какая-то новомодная ересь". Я предпочитаю говорить про ООП на активных объектах (Simula, Smalltalk, все виды эмуляции на акторах) и ООП на пассивных объектах (вся прочая масса C++, Java, C#, Object Pascal, Objective-C, Swift итд итп). И ООП-П занимает настолько важную роль в современном программировании, что его игнорирование тупо неконструктивно.
Кроме того в 90-е из‑за экономического коллапса начала рушиться ЕС ЭВМ, причем лавинообразно. Это привело к тому что получился разрыв в передачи опыта программирования и вообще отношения к компьютерам от высокопрофессиональных МФ‑щиков к начинающим ПК‑шникам.
Ну, экономические задачи сильно не меняются от того, считать их на ЕСке, СМке или персоналке. Из программистов, больша́я часть таки занималась экономическими задачами, а там смена платформы не дала критического разрыва. Уже в 80-х были и персоналки современного типа, и их предшественники. Когда к нам на кафедру пришла Электроника-85 с 512кБайт оперативки, как у ЕС-1022, которую мы тоже использовали, стало понятно, что ЕСки долго не продержатся и без развала СССР. Даже с 10-летним отставанием от мирового прогресса.
Так что "МФ-щики", которые не встроились - не встроились потому, что уже закостенели. Да, по-своему жалко. Но в IT кто не переучивается постоянно - тот вылетает.
МФ, которых в России нет от слова совсем, это монополия ИБМ.
Большинство задач решаются и без них. И даже те задачи, которые сейчас в основном решаются на SystemZ с коболом наперевес, могли бы быть решены альтернативными средствами не хуже. Но имеем закостенение экосистемы. Да, некоторые свойства самого железа IBM способствуют задаче, но и их повторить не проблема (а если с IBM что-то случится - то повторят сразу десятками).
Кстати, насчёт "совсем нет" послушайте соседа @SpiderEkb, он вполне себе в России, насколько рассказывает:)
В случае ассемблера очень чистый вариант неопределённого поведения это нарушение межпроцессорной (в общем смысле, включая ядра и харты) синхронизации. Не сделали когда нужно store-with-release вместо простого store, получили, что другая сторона видит фигню (часть данных не записалась, нарушение инвариантов) или своя сторона прочитала аналогичную фигню.
Бывают ещё недоопределённые команды. Например, BSF, BSR в x86 при нуле на входе могут формально вернуть что угодно. Но в терминах C/C++ это не undefined, а unspecified behavior.
Хуже то, что автор оправдывает наплевательство авторов компиляторов на проблемы программистов, когда сам факт нарушения невозможно отследить из-за сложности кода и интерференции эффектов. Например, переполнение знакового при умножении на константу, когда эта константа определена за тридевять модулей. Изменение размера типа целого. Ещё можно много вариантов придумать. Как сказал один деятель на RSDN, перефразируя Маркса, "нет такой подлости и низости, на которую бы не пошли авторы GCC и Clang ради очередных 2% в никому не нужном синтетическом тесте". Вместо этого и, например, рассказов типа "а вы выключите оптимизацию", надо было дать возможность контекстно управлять наиболее критичными случаями UdB, как переполнения и алиасинг. Синтаксические механизмы для этого давно есть.
Для раутеров всё совсем не так, чем толще, тем больше специфика. Ещё в 1990-х, Cisco Catalyst 19xx серий как раз умел начинать раутинг ещё по не до конца полученному адресу. То же умели 3comʼы примерно тех же времён, модели не помню, но мне на курсах это рассказывали.
И никто процессоры общего пользования в линейные процессоры карт не ставит (пардон, и там и тут "процессоры", но идея должна быть понятна), там специализированные ASICʼи с табличной логикой для быстрого разбрасывания, и чем толще раутер, тем эти процессоры "толще" и специальнее. Им как раз вписать принятие решения по неполному адресу просто и полезно. Например, такой процессор в раутере Core-уровня не будет из IPv6 адреса разбирать что-то дальше первых 4 байт (октетов), на основе принципа, что PA и PI получают блоки /32; если нужно хотя бы по 6 байтам, то это уже не Core, а Distribution тип железки. А чтобы по последним 8 - так это только на конкретном собственном интерфейсе уже финального хопа.
Так что в случае процессоров общего пользования вы, конечно, были бы правы, но именно для сетевой маршрутизации - нет, советую "изучить матчасть" (™).
1. В достаточно "толстом" раутере, да, может быть кадр принят целиком для проверки чексуммы, но этим занимается тупой ASIC на плате. А дальше включается логика раутинга, и вот в ней даже внутренние передачи между процессорами карт и/или центральными раутерными (это разные!) могут подчиняться логике опознания по началу адреса. Поэтому и IPv4, и IPv6 адреса представлены как BE, и это не хотели менять при создании v6.
2. Вполне может быть "оптимистичная" логика, когда кадр передаётся на выход ещё не принятый до конца, но если обнаруживается, что битый, то передача прерывается. Тут уже от вендора зависит. Я помню с ISPшных времён, что Cisco где-то при переходе от 19xx к 25xx, 35xx и т.п. это отменяла, оставив только store-and-forward, а CatOSʼные каталисты вообще этого не умели изначально, но что у других вендоров - ХЗ, могли и применить.
В целом, да, в большинстве случаев, скорее всего, сейчас тотальный store-and-forward, при котором уже неважно, но на 100% я не буду ручаться.
В Windows все совсем не так - там есть стабильный интерфейс между ядром и драйверами, который не меняется десятилетиями.
Он менялся несколько раз в ключевых подсистемах.
В Linux же часто для поддержки нового оборудования нужно пересобирать ядро, а бинарная совместимость с драйверами регулярно ломается, требуя пересборки и драйверов тоже.
Задача сохранения совместимости тут возложена на авторов дистрибутивов, которые держат один интерфейс на несколько версий в течение заметного периода (5-10 лет).
В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11.
Ага, мы-то знаем, что такое PDP endian :)) У PDP-11 сам LE заметно маскировался восьмеричными форматами для человека, и плотным упором на 16-битные значения. Что там слегка "под капотом" LE, тогда, конечно, знали, но прямого внимания не было, в отличие от x86, где уже на уровне машкодов побайтное представление давало, что LE просто бросалось в глаза, как сердитая кошка.
но определённо сыграли такую роль
Обсуждаемый RISC-V как раз действует по принципу "всё, о чём у нас нет своего твёрдого мнения, делаем, как в x86". Это хорошо видно по, например, организации виртуальной памяти.
Это если они влезают в монитор. Вероятно, у вас 200% зрение. У меня оно "так себе", и я не могу поместить в один экран на постоянную, чтобы работать с ним, более, условно, 30 строк. Конечно, кто-то вспомнит "дядюшку Боба", но функции с блоками на 50-100-200 строк реально бывают, хоть и мало. И вот тут оказывается, что, особенно когда у тебя одновременно закрывается несколько блоков, найти, где они начались - уже квест.
А с языком, где {} (и тем более они обязательны - Go, Rust, много других современных; или C/C++ с форсированной политикой всегда делать блоки, как я всем рекомендую) - перейти к парной скобке это тривиально.
А ещё, когда ты вставляешь блок кода из другого места, IDE с Питоном очень часто ошибается в выборе нужного отступа. Имея же скобки {} или хотя бы then-end, else-end, do-end, etc., такой проблемы никогда не будет.
Поэтому я при прочих равных против выделения отступами и за обязательные скобки блоков кода (лучше символами {}, но и словами тоже пойдёт).
в функциях ты просто физически ощущаешь локальное пространство имен.
И снова - если вся функция влезла в экран. Причём со всеми вложенными, если там есть замыкания.
Кодер быстро приходит к тому что вложенности >2 быть не должно, и язык старательно этому учит.
Ага, тогда вложенность переносится в создание иначе нахер никому не нужных функций с отдельными именами. Причём если в каком-нибудь C++ можно их помечать inline и компилятор тогда их усиленно встроит, в Python это приводит к замедлению "на ровном месте".
Есть области где разум пробелов окончательно победил. Я про эволюцию csv - ini - kv - xml - json - yaml - toml.
Да, я в курсе про YAML (не знаю, зачем вы вспомнили TOML). У него, по сути, те же проблемы -это если не считать того, что формат и в других аспектах чудовищно сложен и запутан - так что он скорее контрпример. JSON с некоторыми облегчениями типа финальной запятой и комментариями, и принудительным форматированием тут был бы полезнее.
Это крайне странное утверждение, учитывая абсолютно динамический характер Python:
перепечатать (не прерывая отладки) любую строку и повторно ее выполнить
Я делал такое во встроенном отладчике. Именно динамический характер интерпретатора позволяет сделать вообще всё: пропустить строку, выполнить строку дважды, выполнить её 100 раз, изменить и выполнить - сколько угодно. Чуть больше надо постараться (видел отладчик с таким, не помню уже названия) модифицировать код на ходу, так, чтобы дальше выполнялся модифицированный. Всё это делается, никакого VBA не нужно.
отмотать выполняемую строку как угодно далеко назад/вперед и выполнить код
Вот тут не уверен, что вы имеете в виду. Если просто выполнить код из любой строки, то тоже можно. Если сделать откат состояния программы назад, то я такого не видел, но сомневаюсь, что и с VBA такое есть.
VBA хоронят с момента появления, но он упорно не мрет и живет в рейтингах.
Только для среды Windows, наверно. У меня 99+% всей работы в Unix, в основном в Linux, я его не вижу и про него не помню. Ну да, где-то на другой планете такое есть, только непонятно, зачем туда летать.
По этой вашей странной логике в топе должен быть и Ruby.
У Ruby роль {} реализована точно так же, "скобками", которые заканчиваются словом end. Оппонент недостаточно чётко выразился, я понимаю, что он имел в виду, хоть и не согласен.
что многое говорит об "любви" разработчиков к отступам.
Я добавлю, что отступы как средство группировки неудобны для поиска границ блоков (особенно если заканчивается несколько блоков) и для ручного рефакторинга в IDE или просто в редакторах. Не знаю, сколько ещё Python будет их держать (или вместо него не придёт другое аналогичное средство), но регулярно это задалбывает.
Плюс, RISC-V позволяет иметь (и они существуют) проприоретарные расширения + некоторые наборы инструкций были реализованы до стандартизации и выглядят "почти также, но не так".
Всю эту проприетарщину не загоняют в код ядра. Могут в отдельные драйверы, не более.
Делает невозможным предсказать запустится ли такой софт у потребителя, а если запустится, то с какой производительностью.
У кастомного процессора под конкретную железку - потребитель один и чётко определён.
Если же кому-то продадут лаптоп с убунтой, там будут совершенно конкретные наборы особенностей - грубо говоря, RV64GV.
Читать мануал по ISA действительно страшновато, но надо уметь понимать, читая его, что будет в конкретном случае. И есть отдельно спеки на "профили", вот эти профили и надо смотреть, а не каждое какое-нибудь ZabcdTRex20Reptile+.
CPU общего назначения на ней не изобрести
Давно сделали. Но потребность рынка не сформировалась, поэтому надо явно искать, где купить.
У меня уже второй год работает. Некоторые требуют настоящие пароли чаще менять:)
Ну именно в случае MS у них есть достаточная сила форсировать переход на passkeys как минимум для тех групп, которые считаются ими одновременно vulnerable (каак етта паа рюски - подверженные? незащищённые?) и чей взлом будет дорого стоить - а это сотрудники крупных корпораций. Заставят накупить физических ключей (или хотя бы ставить приложения на телефоны) и авторизоваться ими, отработают подходы и далее будут делать то же с домохозяйками. В это я вполне верю.
Я не говорю, что верю (пример с W10 - да, помню, хорош), но хотя бы частично они это будут вводить. И, возможно, это даже хорошо. Не будет пароля "Маша1952" на всём подряд.
Или /etc/master.passwd на BSD системах, который доступен только руту. /etc/passwd делается из него вырезанием ряда полей.
Или /etc/tcb/$username/shadow при использовании соотв. механизма (ряд линуксовых дистрибутивов), по файлику на юзера.
Есть ещё вариант с сетевыми хранилищами, как LDAP, YP/NIS, NIS+...
В общем, да, в /etc/passwd хэшей больше нет :)
Судя по заявлениям организаций типа Microsoft, пароли вообще будут анахронизмом, или средством только опытных ITшников.
Ваша мысль понятна, но такая надменность без упоминания, например, Yescrypt, который сейчас предпочитается массой дистрибутивов (а Bcrypt, в среднем, считается уже устарелым), или факта, что "пароль по sha-512" в юниксовом crypt это не голый SHA-512, а некий метод его применения туеву хучу тысяч раз - показывает, что и вам лучше освежить знания.
Со спецсимволами в пароле есть ещё проблема: на других раскладках клавиатуры можно просто не найти, где набирается какой-нибудь '#' или '/'. И если для латиницы ещё более-менее есть шанс вспомнить считалочку QWERTYUIOP..., то для прочих символов - ой.
На ssh ключи можно навешивать свои пароли (они там зовутся passphrase), и если ваш лаптоп получили без вас, а пароль был установлен на ключе, то они ничего не смогут. А если с вами, то уже без разницы, будете вы выдавать пароли напрямую к серверу или к ключам, когда паяльник уже нагрет.
Зато, если вас утащили без лаптопа, то даже с passphrases без ключа они не доберутся.
Вот в этом месте и увеличили. Такой себе 2FA, хоть и полностью со стороны клиента.
Пароли там есть, но они называются токенами, имеют вид ghp_Длинна1Стр0каБуквИЦифр и их надо специально создавать. У меня такие есть, использую, где ssh ключ не подходит.
Может, Git и не идеальный, но лучше ничего пока не придумали.
Именно что переписка старого, но ещё не вошедшего в публичные ветки, в нём сделана лучше всего из всех аналогов; я бы даже сказал, в нём единственном она сделана хоть как-то нормально. И по процессам в том же LKML это хорошо видно. Если что-то сделано как цепочка коммитов и в какой-нибудь седьмой версии оно принято - то там коммиты и атомарные, и хорошо описанные.
А вот к вопросу о "сторителлинге" это имеет косвенное отношение - если не противоположное. Рассказывать на уже почищенной истории это, конечно, много лоска, но даёт ложное ощущение, что у авторов таких историй всё получается с первого раза и в шоколаде. А это отпугивает тех, кто потом сталкивается с реальными сложностями, после первой пары шишек от граблей. Если рассказывать, то вместе со всеми запутанностями, отступлениями и повторными наступлениями, результатом с 10-й (в лучшем случае) попытки - то есть как раз красивая история вредна, а нужна честная.
(Вариант HOWTO по финальному результату - это тоже нужно, но это не сторителлинг. Но я в такие хаутушки добавляю, по своему опыту, все существенные грабли, по которым я потоптался.)
Хм, таки я ещё не видел тут статей в стиле "ответ на полемику" с цитатами и своими комментариями. Интересно. В других местах бывало, но там часто отделение ветки обсуждения в отдельную тему.
По отдельным пунктам:
Это очень частая позиция, но, с учётом того, сколько ООП занимает в современном программировании, напоминает позицию типа "вот сосна - настоящее дерево, а эта ваша трава - какая-то новомодная ересь". Я предпочитаю говорить про ООП на активных объектах (Simula, Smalltalk, все виды эмуляции на акторах) и ООП на пассивных объектах (вся прочая масса C++, Java, C#, Object Pascal, Objective-C, Swift итд итп). И ООП-П занимает настолько важную роль в современном программировании, что его игнорирование тупо неконструктивно.
Ну, экономические задачи сильно не меняются от того, считать их на ЕСке, СМке или персоналке. Из программистов, больша́я часть таки занималась экономическими задачами, а там смена платформы не дала критического разрыва. Уже в 80-х были и персоналки современного типа, и их предшественники. Когда к нам на кафедру пришла Электроника-85 с 512кБайт оперативки, как у ЕС-1022, которую мы тоже использовали, стало понятно, что ЕСки долго не продержатся и без развала СССР. Даже с 10-летним отставанием от мирового прогресса.
Так что "МФ-щики", которые не встроились - не встроились потому, что уже закостенели. Да, по-своему жалко. Но в IT кто не переучивается постоянно - тот вылетает.
Большинство задач решаются и без них. И даже те задачи, которые сейчас в основном решаются на SystemZ с коболом наперевес, могли бы быть решены альтернативными средствами не хуже. Но имеем закостенение экосистемы. Да, некоторые свойства самого железа IBM способствуют задаче, но и их повторить не проблема (а если с IBM что-то случится - то повторят сразу десятками).
Кстати, насчёт "совсем нет" послушайте соседа @SpiderEkb, он вполне себе в России, насколько рассказывает:)
В случае ассемблера очень чистый вариант неопределённого поведения это нарушение межпроцессорной (в общем смысле, включая ядра и харты) синхронизации. Не сделали когда нужно store-with-release вместо простого store, получили, что другая сторона видит фигню (часть данных не записалась, нарушение инвариантов) или своя сторона прочитала аналогичную фигню.
Бывают ещё недоопределённые команды. Например, BSF, BSR в x86 при нуле на входе могут формально вернуть что угодно. Но в терминах C/C++ это не undefined, а unspecified behavior.
Хуже то, что автор оправдывает наплевательство авторов компиляторов на проблемы программистов, когда сам факт нарушения невозможно отследить из-за сложности кода и интерференции эффектов. Например, переполнение знакового при умножении на константу, когда эта константа определена за тридевять модулей. Изменение размера типа целого. Ещё можно много вариантов придумать. Как сказал один деятель на RSDN, перефразируя Маркса, "нет такой подлости и низости, на которую бы не пошли авторы GCC и Clang ради очередных 2% в никому не нужном синтетическом тесте". Вместо этого и, например, рассказов типа "а вы выключите оптимизацию", надо было дать возможность контекстно управлять наиболее критичными случаями UdB, как переполнения и алиасинг. Синтаксические механизмы для этого давно есть.
Для раутеров всё совсем не так, чем толще, тем больше специфика.
Ещё в 1990-х, Cisco Catalyst 19xx серий как раз умел начинать раутинг ещё по не до конца полученному адресу. То же умели 3comʼы примерно тех же времён, модели не помню, но мне на курсах это рассказывали.
И никто процессоры общего пользования в линейные процессоры карт не ставит (пардон, и там и тут "процессоры", но идея должна быть понятна), там специализированные ASICʼи с табличной логикой для быстрого разбрасывания, и чем толще раутер, тем эти процессоры "толще" и специальнее. Им как раз вписать принятие решения по неполному адресу просто и полезно. Например, такой процессор в раутере Core-уровня не будет из IPv6 адреса разбирать что-то дальше первых 4 байт (октетов), на основе принципа, что PA и PI получают блоки /32; если нужно хотя бы по 6 байтам, то это уже не Core, а Distribution тип железки. А чтобы по последним 8 - так это только на конкретном собственном интерфейсе уже финального хопа.
Так что в случае процессоров общего пользования вы, конечно, были бы правы, но именно для сетевой маршрутизации - нет, советую "изучить матчасть" (™).
Не.
1. В достаточно "толстом" раутере, да, может быть кадр принят целиком для проверки чексуммы, но этим занимается тупой ASIC на плате. А дальше включается логика раутинга, и вот в ней даже внутренние передачи между процессорами карт и/или центральными раутерными (это разные!) могут подчиняться логике опознания по началу адреса. Поэтому и IPv4, и IPv6 адреса представлены как BE, и это не хотели менять при создании v6.
2. Вполне может быть "оптимистичная" логика, когда кадр передаётся на выход ещё не принятый до конца, но если обнаруживается, что битый, то передача прерывается. Тут уже от вендора зависит. Я помню с ISPшных времён, что Cisco где-то при переходе от 19xx к 25xx, 35xx и т.п. это отменяла, оставив только store-and-forward, а CatOSʼные каталисты вообще этого не умели изначально, но что у других вендоров - ХЗ, могли и применить.
В целом, да, в большинстве случаев, скорее всего, сейчас тотальный store-and-forward, при котором уже неважно, но на 100% я не буду ручаться.
Он менялся несколько раз в ключевых подсистемах.
Задача сохранения совместимости тут возложена на авторов дистрибутивов, которые держат один интерфейс на несколько версий в течение заметного периода (5-10 лет).
Нет, как раз раньше, причём даже 8008. https://stackoverflow.com/a/36263273/
Ага, мы-то знаем, что такое PDP endian :))
У PDP-11 сам LE заметно маскировался восьмеричными форматами для человека, и плотным упором на 16-битные значения. Что там слегка "под капотом" LE, тогда, конечно, знали, но прямого внимания не было, в отличие от x86, где уже на уровне машкодов побайтное представление давало, что LE просто бросалось в глаза, как сердитая кошка.
Обсуждаемый RISC-V как раз действует по принципу "всё, о чём у нас нет своего твёрдого мнения, делаем, как в x86". Это хорошо видно по, например, организации виртуальной памяти.
Это если они влезают в монитор. Вероятно, у вас 200% зрение. У меня оно "так себе", и я не могу поместить в один экран на постоянную, чтобы работать с ним, более, условно, 30 строк. Конечно, кто-то вспомнит "дядюшку Боба", но функции с блоками на 50-100-200 строк реально бывают, хоть и мало. И вот тут оказывается, что, особенно когда у тебя одновременно закрывается несколько блоков, найти, где они начались - уже квест.
А с языком, где {} (и тем более они обязательны - Go, Rust, много других современных; или C/C++ с форсированной политикой всегда делать блоки, как я всем рекомендую) - перейти к парной скобке это тривиально.
А ещё, когда ты вставляешь блок кода из другого места, IDE с Питоном очень часто ошибается в выборе нужного отступа. Имея же скобки {} или хотя бы then-end, else-end, do-end, etc., такой проблемы никогда не будет.
Поэтому я при прочих равных против выделения отступами и за обязательные скобки блоков кода (лучше символами {}, но и словами тоже пойдёт).
И снова - если вся функция влезла в экран. Причём со всеми вложенными, если там есть замыкания.
Ага, тогда вложенность переносится в создание иначе нахер никому не нужных функций с отдельными именами. Причём если в каком-нибудь C++ можно их помечать inline и компилятор тогда их усиленно встроит, в Python это приводит к замедлению "на ровном месте".
Есть области где разум пробелов окончательно победил. Я про эволюцию csv - ini - kv - xml - json - yaml - toml.
Да, я в курсе про YAML (не знаю, зачем вы вспомнили TOML). У него, по сути, те же проблемы -это если не считать того, что формат и в других аспектах чудовищно сложен и запутан - так что он скорее контрпример. JSON с некоторыми облегчениями типа финальной запятой и комментариями, и принудительным форматированием тут был бы полезнее.
Это крайне странное утверждение, учитывая абсолютно динамический характер Python:
Я делал такое во встроенном отладчике. Именно динамический характер интерпретатора позволяет сделать вообще всё: пропустить строку, выполнить строку дважды, выполнить её 100 раз, изменить и выполнить - сколько угодно. Чуть больше надо постараться (видел отладчик с таким, не помню уже названия) модифицировать код на ходу, так, чтобы дальше выполнялся модифицированный. Всё это делается, никакого VBA не нужно.
Вот тут не уверен, что вы имеете в виду. Если просто выполнить код из любой строки, то тоже можно. Если сделать откат состояния программы назад, то я такого не видел, но сомневаюсь, что и с VBA такое есть.
Только для среды Windows, наверно. У меня 99+% всей работы в Unix, в основном в Linux, я его не вижу и про него не помню. Ну да, где-то на другой планете такое есть, только непонятно, зачем туда летать.
Отличная сводка, спасибо:)
У Ruby роль {} реализована точно так же, "скобками", которые заканчиваются словом end. Оппонент недостаточно чётко выразился, я понимаю, что он имел в виду, хоть и не согласен.
Я добавлю, что отступы как средство группировки неудобны для поиска границ блоков (особенно если заканчивается несколько блоков) и для ручного рефакторинга в IDE или просто в редакторах. Не знаю, сколько ещё Python будет их держать (или вместо него не придёт другое аналогичное средство), но регулярно это задалбывает.
Всю эту проприетарщину не загоняют в код ядра. Могут в отдельные драйверы, не более.
У кастомного процессора под конкретную железку - потребитель один и чётко определён.
Если же кому-то продадут лаптоп с убунтой, там будут совершенно конкретные наборы особенностей - грубо говоря, RV64GV.
Читать мануал по ISA действительно страшновато, но надо уметь понимать, читая его, что будет в конкретном случае. И есть отдельно спеки на "профили", вот эти профили и надо смотреть, а не каждое какое-нибудь ZabcdTRex20Reptile+.
Давно сделали. Но потребность рынка не сформировалась, поэтому надо явно искать, где купить.