Имхо, выигрывает. В funcparserlib нет лишних управляющих структур (for/yield), которые есть в коде из статьи. Это значит, что без этих структур можно обойтись, и следовательно они не нужны.
И что-то мне подсказывает, что по 2 yield'а в каждой функции — не Python-way (это не выглядит просто).
Комбинаторные парсеры (пример выше) выглядят гораздо "изящнее", чем for'ы вместо последовательностей термов. (Если эти for'ы убрать, то и получатся комбинаторные парсеры. А так — "код в стиле барокко").
Рекурсивный спуск выглядит проще (но объёмнее).
И ещё есть всякие генераторы парсеров, которые должны работать быстрее.
Статья хорошо показывает, что парсер с нуля написать несложно, но я бы не рекомендовал использовать конкретно этот подход. Он избыточен и неочевиден.
Весьма странно видеть MPI и OpenMP как замену SIMD. Они не занимаются векторизацией.
OpenMP — это распараллеливание программы между потоками, и оно помогает задействовать совершенно другие возможности процессоров (многоядерность), чем SIMD (широкие АЛУ).
MPI (если речь идёт о Message Passing Interface) — это вообще про обмен сообщениями между процессами в кластере. Я бы не хотел видеть такое в стандарте языка общего назначения.
К слову, OpenMP-подход (т.е. расширение компилятора для поддержки потоков) сейчас слабо распространён в разных языках, хотя удобен для пользователя. Возможно, не очень хорошо/не очень удобно модифицировать компилятор для поддержки многопоточности, а написать библиотеку намного проще.
Чаще предпочтение отдаётся подходу с параллельным коллекциями. Но, как правило, это тоже не векторизация.
В своё время я пытался переупаковать HttpComponents с помощью maven shade и gradle на этапе сборки (не вышло, где-то использовалась рефлексия), а потом я увидел, что авторы HttpComponents (не от хорошей жизни) предоставляют отдельную сборку под android с другими названиями классов. Но этот вариант никак не подходил (я писал библиотеку, зависящую от HttpComponents), и пришлось отказаться от HttpComponents.
Это печально. Надо бы предусмотреть пункт в лицензии библиотек на случай подобного использования.
Google довольно часто руководствуется принципом "здесь и сейчас", игнорируя правила, и через некоторое время пользователи остаются наедине с негибкими решениями.
Навскидку:
Описанная ситуация с нестабильной версией HttpComponents (включить нестабильную библиотеку в ОС, и тем самым запретить её обновления без костылей? серьёзно?)
Ограничение 64К методов в .dex (конечно, этого хватит всем).
Отсутствие generic-ов в go (сойдёт и так, пока вам не понадобятся самописные коллекции).
Отказ от использования исключений в языках, в которых они есть (в их библиотеках на С++ и по инерции на Java).
Нестандартное для Java соглашение об именовании полей (префикс m).
В принципе, этого достаточно, чтобы подходить с осторожностью к использованию их библиотек/технологий.
Размер потребляемых ресурсов: памяти, процессорного времени, используемых ядер, необходимость или отсутствие доп. оборудования.
Если вы не смогли описать в интерфейсе эти параметры, это проблема конкретного случая. Опишите их в документации, если число ядер или время обработки — действительно часть интерфейса. Из невозможности полностью описать интерфейс средствами языка не следует вывод, что LSP неверен.
В пределе Вы не можете изменить свой код сразу после того как поднимите руки над клавиатурой.
Если вы лезете с клавиатурой прямо в продакшен, то да.
А на практике код можно менять как угодно, если вы в состоянии переписать все участки программы/инфраструктуры, на которые влияет изменение, так, чтобы клиенты не пострадали. OCP, если его применять, только минимизирует число изменений других частей.
В статье очень много максимализма, как уже говорилось выше. Эти принципы намного гибче, чем вам кажется. И SOLID действительно помогает поддерживать и развивать огромные системы.
Как я понял, этот?
В идеальном мире с автопилотами, никаких фур на встречке и обочин людей на обочинах автоматических дорог быть не должно. В случае серьёзного сбоя — да, жертв не избежать. Наверное, страдать должны в первую очередь нарушители правил, во вторую — имеющие отношение к транспорту (кто им пользуется, а не просто идёт мимо). Вопрос сложный.
Можно привести примеры безвыходных ситуаций, когда человек вообще ничего не контролирует, но получает вред здоровью (2 автопилота не поделили дорогу; либо 2 бензовоза столкнулись и взрывом зацепило пешеходов за ограждением). Но это сбои систем автопилотирования или недостатки инфраструктуры, которые нужно предотвращать.
Автопилот не должен ничего решать, он должен следовать непротиворечивому закону.
Лучше относиться к автопилотам как к бездумной полностью автоматической системе (или стихии), которая в 100% случаях способствует выживанию своих пассажиров, а разных личностей, нарушивших правила — как получится. Тогда никто в здравом уме не будет лезть под колёса, надеясь, что с ним всё будет в порядке. Сейчас мало кто лезет руками в циркулярную пилу, или шахту лифта, или гуляет по полю в грозу, так как ясно, чем это закончится.
Что делать с людьми, которые по каким-либо причинам себя не контролируют? Максимально затруднить доступ к автоматическим дорогам абсолютно всем, как это сделано с шахтами лифтов (возможно, достаточно забора на высокоскоростных участках и надземных переходов).
Если автопилот решает, а не убить ли ему пассажиров, это может быть использовано для преднамеренных убийств, ключик для принятия «нужных» решений так или иначе найдётся. Я бы не захотел пользоваться таким транспортом. Почему должны погибать пассажиры, если они не нарушали правил и вообще не имели контроля над ситуацией, а не те, кто контролировал ситуацию и правила нарушил?
Насколько я понял из вики, 1 MET — это скорость расхода кислорода в пассивном состоянии. В неделе 7*24*60=10080 минут, значит пассивные затраты были бы равны 10080 MET*мин за неделю. Даже размерность другая. Что-то здесь явно не так.
Это понятно, но в текущей формулировке есть противоречие «руководитель обязан наказать» — «наказывать нельзя». Выходит, что руководитель сам нарушит свой регламент, и по-хорошему должен будет себя наказать, а вдруг он такой «некоторый» человек, что его нельзя,…
п.17 особенно интересно смотрится в чеклисте с логическими «дырами».
Правила должны быть непротиворечивы, иначе принимать их — себе дороже.
> 5. Руководитель обязан наказать подчинённого, если тот нарушил установленные и доведённые до него правила.
> 23. Некоторых людей наказывать нельзя.
Список таких людей должен быть включён в регламенты? Иначе пункты противоречат друг другу.
А зачем mesh-сети, когда можно просто скачать 15МБ (или 150МБ, или 500МБ, если это область размером со страну) картографических данных из OpenStreetMap перед поездкой в удалённый регион? Вы не будете зависеть ни от провайдера, ни от «соседей», карты будут у вас хоть в степи. Невысокой скорости актуализации данных обычно достаточно. Это ответ на первые 2 пункта.
Конечно, имеет смысл использовать такую сеть для информации о пробках, если у вас нет интернет-роуминга. Но тогда эта mesh-сеть должна быть мировым стандартом, который поддерживают даже в тех местах, в которые вы так далеко заехали. Дома это не очень нужно — у всех мобильный интернет есть.
Получается, эта технология нужна очень небольшому числу пользователей, которые много путешествуют, нуждаются в сверхактуальной информации и не могут купить местную SIM-карту. А mesh-сеть может держаться на плаву, когда у неё много пользователей. Перспективы так себе.
Для больших объёмов нужны соответствующие скорости чтения/записи.
Вышеупомянутые 200ТБ Библиотеки Конгресса / 1 Мбит/с = 1562500000 с = 49.5 лет. Как минимум, нужно паралеллить чтение и запись.
Во-первых, дата-центрам будет сложно работать с жидким азотом. Это сложно организовать и с технической точки зрения, плюс довольно высокие затраты энергии на поддержание сверхнизких температур
Разве требуется так много азота? Для больших хранилищ размер установки наверно должен получиться меньше, чем размер требуемого числа HDD.
Имхо, выигрывает. В funcparserlib нет лишних управляющих структур (for/yield), которые есть в коде из статьи. Это значит, что без этих структур можно обойтись, и следовательно они не нужны.
И что-то мне подсказывает, что по 2 yield'а в каждой функции — не Python-way (это не выглядит просто).
Комбинаторные парсеры (пример выше) выглядят гораздо "изящнее", чем for'ы вместо последовательностей термов. (Если эти for'ы убрать, то и получатся комбинаторные парсеры. А так — "код в стиле барокко").
Рекурсивный спуск выглядит проще (но объёмнее).
И ещё есть всякие генераторы парсеров, которые должны работать быстрее.
Статья хорошо показывает, что парсер с нуля написать несложно, но я бы не рекомендовал использовать конкретно этот подход. Он избыточен и неочевиден.
И почему Python 2 ?
Весьма странно видеть MPI и OpenMP как замену SIMD. Они не занимаются векторизацией.
OpenMP — это распараллеливание программы между потоками, и оно помогает задействовать совершенно другие возможности процессоров (многоядерность), чем SIMD (широкие АЛУ).
MPI (если речь идёт о Message Passing Interface) — это вообще про обмен сообщениями между процессами в кластере. Я бы не хотел видеть такое в стандарте языка общего назначения.
К слову, OpenMP-подход (т.е. расширение компилятора для поддержки потоков) сейчас слабо распространён в разных языках, хотя удобен для пользователя. Возможно, не очень хорошо/не очень удобно модифицировать компилятор для поддержки многопоточности, а написать библиотеку намного проще.
Чаще предпочтение отдаётся подходу с параллельным коллекциями. Но, как правило, это тоже не векторизация.
Если фабрика может вернуть nullptr, вызов метода без проверки на nullptr не является "адекватным".
Класслоадер по-хорошему сначала должен искать стандартные классы (которые уже есть у его родителя), а потом — свои.
В своё время я пытался переупаковать HttpComponents с помощью maven shade и gradle на этапе сборки (не вышло, где-то использовалась рефлексия), а потом я увидел, что авторы HttpComponents (не от хорошей жизни) предоставляют отдельную сборку под android с другими названиями классов. Но этот вариант никак не подходил (я писал библиотеку, зависящую от HttpComponents), и пришлось отказаться от HttpComponents.
Это печально. Надо бы предусмотреть пункт в лицензии библиотек на случай подобного использования.
Google довольно часто руководствуется принципом "здесь и сейчас", игнорируя правила, и через некоторое время пользователи остаются наедине с негибкими решениями.
В принципе, этого достаточно, чтобы подходить с осторожностью к использованию их библиотек/технологий.
А почему вы считаете трупами большие, но работающие, развивающиеся и приносящие деньги системы?
Если вы не смогли описать в интерфейсе эти параметры, это проблема конкретного случая. Опишите их в документации, если число ядер или время обработки — действительно часть интерфейса. Из невозможности полностью описать интерфейс средствами языка не следует вывод, что LSP неверен.
Если вы лезете с клавиатурой прямо в продакшен, то да.
А на практике код можно менять как угодно, если вы в состоянии переписать все участки программы/инфраструктуры, на которые влияет изменение, так, чтобы клиенты не пострадали. OCP, если его применять, только минимизирует число изменений других частей.
В статье очень много максимализма, как уже говорилось выше. Эти принципы намного гибче, чем вам кажется. И SOLID действительно помогает поддерживать и развивать огромные системы.
В идеальном мире с автопилотами, никаких фур на встречке и
обочинлюдей на обочинах автоматических дорог быть не должно. В случае серьёзного сбоя — да, жертв не избежать. Наверное, страдать должны в первую очередь нарушители правил, во вторую — имеющие отношение к транспорту (кто им пользуется, а не просто идёт мимо). Вопрос сложный.Можно привести примеры безвыходных ситуаций, когда человек вообще ничего не контролирует, но получает вред здоровью (2 автопилота не поделили дорогу; либо 2 бензовоза столкнулись и взрывом зацепило пешеходов за ограждением). Но это сбои систем автопилотирования или недостатки инфраструктуры, которые нужно предотвращать.
Автопилот не должен ничего решать, он должен следовать непротиворечивому закону.
Лучше относиться к автопилотам как к бездумной полностью автоматической системе (или стихии), которая в 100% случаях способствует выживанию своих пассажиров, а разных личностей, нарушивших правила — как получится. Тогда никто в здравом уме не будет лезть под колёса, надеясь, что с ним всё будет в порядке. Сейчас мало кто лезет руками в циркулярную пилу, или шахту лифта, или гуляет по полю в грозу, так как ясно, чем это закончится.
Что делать с людьми, которые по каким-либо причинам себя не контролируют? Максимально затруднить доступ к автоматическим дорогам абсолютно всем, как это сделано с шахтами лифтов (возможно, достаточно забора на высокоскоростных участках и надземных переходов).
Если автопилот решает, а не убить ли ему пассажиров, это может быть использовано для преднамеренных убийств, ключик для принятия «нужных» решений так или иначе найдётся. Я бы не захотел пользоваться таким транспортом. Почему должны погибать пассажиры, если они не нарушали правил и вообще не имели контроля над ситуацией, а не те, кто контролировал ситуацию и правила нарушил?
Иногда такие странные вещи по причине обратной совместимости появляются.
п.17 особенно интересно смотрится в чеклисте с логическими «дырами».
Правила должны быть непротиворечивы, иначе принимать их — себе дороже.
> 23. Некоторых людей наказывать нельзя.
Список таких людей должен быть включён в регламенты? Иначе пункты противоречат друг другу.
Конечно, имеет смысл использовать такую сеть для информации о пробках, если у вас нет интернет-роуминга. Но тогда эта mesh-сеть должна быть мировым стандартом, который поддерживают даже в тех местах, в которые вы так далеко заехали. Дома это не очень нужно — у всех мобильный интернет есть.
Получается, эта технология нужна очень небольшому числу пользователей, которые много путешествуют, нуждаются в сверхактуальной информации и не могут купить местную SIM-карту. А mesh-сеть может держаться на плаву, когда у неё много пользователей. Перспективы так себе.
Вышеупомянутые 200ТБ Библиотеки Конгресса / 1 Мбит/с = 1562500000 с = 49.5 лет. Как минимум, нужно паралеллить чтение и запись.
Разве требуется так много азота? Для больших хранилищ размер установки наверно должен получиться меньше, чем размер требуемого числа HDD.