"Хотим искать кратчайшие в евклидовой метрике пути в лабиринте на квадратной сетке где можно ходить на 8 соседей, при этом погрешности недопустимы. Для этого берём любой алгоритм поиска кратчайшего пути, длину представляем в виде суммы целой части с частью содержащей квадратный корень в качестве множителя, учимся сравнивать представленные таким образом числа - для этого группируем целые части и части с корнями и сравниваем их квадраты." Это всё содержание статьи. Какой смысл несет остальная псевдоматематически-формальная вода?
Нет, не странно. Во-первых, тесты не обязательно запускать на железке. Нормальный код абстрагирован от io как минимум в целях переносимости, и можно мокнув оное протестировать всю логику прошивки локально. Если нет, то всё равно всегда есть части кода которые можно тестировать обособленно. Во-вторых, микроконтроллеры это уже давно не avrки с 512 байт памяти, уж функция с простынёй ассертов туда влезет всегда.
Любая инвертированная логика неинтуитивна, а for..else скорее всего задумывался для прямолинейной логики поиска, которая выглядит вполне логично:
for x in iterable:
if predicate(x):
break
else:
raise NotFoundException()
# work with x
И я бы даже предпочёл её более современному функциональному коду, который в питоне получается отвратителен:
if (x := next(filter(predicate, iterable)), None) is None:
raise NotFoundException()
if (x := next((i for i in iterable if predicate(i)), None) is None:
raise NotFoundException()
try:
x = next(filter(predicate, iterable))
except StopIteration:
raise NotFoundException()
from more_itertools import first_true # лучше, но нужен внешний модуль
if (x := first_true(iterable, pred=predicate)) is None:
raise NotFoundException()
Сомнительная фича, как минимум требующая намного больше логики для правильной реализации. Например, что если изображение с высоким качеством уже закэшировано, зачем качать заново низкокачественное.
Нет, ценность именно (на самом деле только) в коммьюнити. В git хостинг репозиториев ценности не имеет, потому что git распределённый и любой клон сам себе хостинг, а равнозначные зеркала тиражируются элементарно, даже при полной потере сетевой связности. Ценность GH в том что только туда можно отправить PR который будет принят в основную ветку, только туда можно открыть issue который будет обработан и свой проект залитый туда будет иметь максимальную видимость среди пользователей и контрибуторов. Повторить это в изолированном местячковом сервисе невозможно физически.
Нет никакого смысла стремиться к тому чтобы код был похож на код стандартных библиотек Python, уж скорее есть смысл в обратном. Удобно и правильно писать на полноценном идиоматичном C++, а сишная прослойка между ним и питоновским API будет очень тонкой и ограниченной конвертацией аргументов и возвращаемых значений между PyObject и плюсовыми типами. В случае же когда код модуля вынужден оперировать PyObject'ами, я вообще считаю преступлением писать руками простыни Py_INC/DEC/XDECREF'ов вместо того чтобы обернуть PyObject в плюсовый класс с поддержкой move semantics и явной передачей владения/заимствованием и писать на нем лаконичный, понятный и безопасный код.
Это только от безысходности, когда системного пакетного менеджера нет. А когда он есть и из него ставятся и система, и приложения, и инструменты, и библиотеки всех языков сразу (что особенно важно в местах их пересечения, например питоновских биндингов к плюсовым библиотекам), нет никакого смысла иметь ещё один, ограниченный и вдобавок привязанный к какой-то IDE, когда у меня, во-вторых, другая IDE, а во-первых, IDE для сборки вообще не нужна. Сборка это `git clone && cmake|meson && ninja` плюс упомянутая установка зависимостей.
А при чем тут "зависимости для вашего кода" и пакетный менеджер ОС мне не совсем понятно.
Я думаю, имелась в виду возможность использовать при разработке библиотеки установленные в систему. `apt|rpm|pkg|... install opencv ffmpeg curl boost qt6`, и всё - можно собирать код использующий эти библиотеки.
Мне кажется, или в приведенном коде CERN httpd переполнение буфера при попытке раздать файл размером 100 десятичных гигабайт? Такой исторический код надо закопать и никогда на него не смотреть - это совсем другие языки (даже если это C), совсем другие требования, другая экспертиза. По современным меркам это один сплошной антипаттерн.
Я бы для этой задачи взял coastlines (а возможно и другие данные) из openstretmap, посчитал бы по ним distance field и определял бы зум за один (ну или 4 если хочется плавно) лукап. В общем виде это только так и решается, потому что если в качестве подложки использовать спутник, с одной стороны вода будет неоднородной, с другой - на сплошной лес тоже неинтересно смотреть.
Посыл статьи понял как негодование покушением на собственную незаменимость. К дискуссии по сути она не располагает, потому что вы сходу ставите диагнозы.
Как исключения вам помогут? Максимум у вас код в проде упадет где-то, вы это залогируете из эксепшена, и потом в этом месте добавите логику для фикса бага. Но данные уже не вернуть.
В go/rust вы сразу знаете все места где у вас упадет код, и в зависимости от контекста и важности функции, сразу можете корректно обработать этот случай.
Вообще-то исключения и коды ошибок функционально эквивалентны - всё что можно сделать одним инструментом можно сделать другим. Разница только в синтаксисе и, естественно, реализации. А синтаксис у исключений лучше по той простой причине что они прокидываются выше по стеку вызовов неявно. Дело в том что мест в коде которые могут завершиться неуспехом много, а мест где по этому поводу можно предпринять какие-то осмысленные действия - мало, поэтому в подавляющем большинстве мест обработки ошибок они просто прикидываются выше. Делать это явно - неблагодарная рутинная работа, и в результате получается раздутый код в котором за обработкой ошибок не видно реальной логики. Выше есть замечательный пример из ядра, он на четверть состоит из обработки ошибок. В rust эту проблему нивелировали до предела позволив прокидывать ошибки одним !, но по мне так даже это слишком много - визуальный шум и необходимость низачем держать в голове вызовы которые могут вернуть ошибку никуда не исчезли.
Пример - загрузка файла в каком-нибудь офисе. Нужно открыть собственно файл, прочитать, раз'zip'овать, распарсить xml, переложить во внутреннее представление, при этом только в парсинге xml может быть куча разных типов ошибок. Но сделать мы с этим ничего не можем - файл в любом случае битый. Структура кода будет одна - последовательность вызовов реализующая шаги загрузки, и обработка ошибки в одном месте где мы просто говорим "не шмогла". При желании обрабатываем конкретные типы ошибок с дополнительной информацией и говорим "не шмогла потому что в foo.xml не закрыт тэг <foo> в строке 79". Так вот код загрузки может быть либо кодом загрузки, либо кодом загрузки перемешанным с прокидыванием ошибок. Лучше однозначно первое.
Есть, но я же отвечал на комментарий про забор. Проходная там стандартная вахтёрская для галочки - первый день когда приехал на конференцию попросили паспорт, потом толпа ходила туда-сюда курить, никто уже ничего не контролировал, как и весь второй день. И кажется что если бы кто-то пошёл гулять по зданию, никто бы не заметил. Но не знаю, может там автоматчики в другом корпусе запрятаны.
"Хотим искать кратчайшие в евклидовой метрике пути в лабиринте на квадратной сетке где можно ходить на 8 соседей, при этом погрешности недопустимы. Для этого берём любой алгоритм поиска кратчайшего пути, длину представляем в виде суммы целой части с частью содержащей квадратный корень в качестве множителя, учимся сравнивать представленные таким образом числа - для этого группируем целые части и части с корнями и сравниваем их квадраты." Это всё содержание статьи. Какой смысл несет остальная псевдоматематически-формальная вода?
Просто не читайте "блоги компаний".
Нет, не странно. Во-первых, тесты не обязательно запускать на железке. Нормальный код абстрагирован от io как минимум в целях переносимости, и можно мокнув оное протестировать всю логику прошивки локально. Если нет, то всё равно всегда есть части кода которые можно тестировать обособленно. Во-вторых, микроконтроллеры это уже давно не avrки с 512 байт памяти, уж функция с простынёй ассертов туда влезет всегда.
Любая инвертированная логика неинтуитивна, а for..else скорее всего задумывался для прямолинейной логики поиска, которая выглядит вполне логично:
И я бы даже предпочёл её более современному функциональному коду, который в питоне получается отвратителен:
Потому что assignment expressions появились ещё в 3.8?
В какой-то момент игрался с termux, запустил там vim и понял что он на порядок удобнее штатных контролов для редактирования текста.
Сомнительная фича, как минимум требующая намного больше логики для правильной реализации. Например, что если изображение с высоким качеством уже закэшировано, зачем качать заново низкокачественное.
Совсем не обязательно. Достаточно атаковать расшаренную с кем-то страницу.
Комьюнити нельзя создать, оно само возникает вокруг проектов.
Нет, ценность именно (на самом деле только) в коммьюнити. В git хостинг репозиториев ценности не имеет, потому что git распределённый и любой клон сам себе хостинг, а равнозначные зеркала тиражируются элементарно, даже при полной потере сетевой связности. Ценность GH в том что только туда можно отправить PR который будет принят в основную ветку, только туда можно открыть issue который будет обработан и свой проект залитый туда будет иметь максимальную видимость среди пользователей и контрибуторов. Повторить это в изолированном местячковом сервисе невозможно физически.
Нет никакого смысла стремиться к тому чтобы код был похож на код стандартных библиотек Python, уж скорее есть смысл в обратном. Удобно и правильно писать на полноценном идиоматичном C++, а сишная прослойка между ним и питоновским API будет очень тонкой и ограниченной конвертацией аргументов и возвращаемых значений между PyObject и плюсовыми типами. В случае же когда код модуля вынужден оперировать PyObject'ами, я вообще считаю преступлением писать руками простыни Py_INC/DEC/XDECREF'ов вместо того чтобы обернуть PyObject в плюсовый класс с поддержкой move semantics и явной передачей владения/заимствованием и писать на нем лаконичный, понятный и безопасный код.
Это только от безысходности, когда системного пакетного менеджера нет. А когда он есть и из него ставятся и система, и приложения, и инструменты, и библиотеки всех языков сразу (что особенно важно в местах их пересечения, например питоновских биндингов к плюсовым библиотекам), нет никакого смысла иметь ещё один, ограниченный и вдобавок привязанный к какой-то IDE, когда у меня, во-вторых, другая IDE, а во-первых, IDE для сборки вообще не нужна. Сборка это `git clone && cmake|meson && ninja` плюс упомянутая установка зависимостей.
Это зависит от репозитория. Где-то они не разделяются, где-то нужно добавить -devel суффиксы.
Я думаю, имелась в виду возможность использовать при разработке библиотеки установленные в систему. `apt|rpm|pkg|... install opencv ffmpeg curl boost qt6`, и всё - можно собирать код использующий эти библиотеки.
Мне кажется, или в приведенном коде CERN httpd переполнение буфера при попытке раздать файл размером 100 десятичных гигабайт? Такой исторический код надо закопать и никогда на него не смотреть - это совсем другие языки (даже если это C), совсем другие требования, другая экспертиза. По современным меркам это один сплошной антипаттерн.
Я бы для этой задачи взял coastlines (а возможно и другие данные) из openstretmap, посчитал бы по ним distance field и определял бы зум за один (ну или 4 если хочется плавно) лукап. В общем виде это только так и решается, потому что если в качестве подложки использовать спутник, с одной стороны вода будет неоднородной, с другой - на сплошной лес тоже неинтересно смотреть.
Посыл статьи понял как негодование покушением на собственную незаменимость. К дискуссии по сути она не располагает, потому что вы сходу ставите диагнозы.
Вообще-то исключения и коды ошибок функционально эквивалентны - всё что можно сделать одним инструментом можно сделать другим. Разница только в синтаксисе и, естественно, реализации. А синтаксис у исключений лучше по той простой причине что они прокидываются выше по стеку вызовов неявно. Дело в том что мест в коде которые могут завершиться неуспехом много, а мест где по этому поводу можно предпринять какие-то осмысленные действия - мало, поэтому в подавляющем большинстве мест обработки ошибок они просто прикидываются выше. Делать это явно - неблагодарная рутинная работа, и в результате получается раздутый код в котором за обработкой ошибок не видно реальной логики. Выше есть замечательный пример из ядра, он на четверть состоит из обработки ошибок. В rust эту проблему нивелировали до предела позволив прокидывать ошибки одним
!, но по мне так даже это слишком много - визуальный шум и необходимость низачем держать в голове вызовы которые могут вернуть ошибку никуда не исчезли.Пример - загрузка файла в каком-нибудь офисе. Нужно открыть собственно файл, прочитать, раз'zip'овать, распарсить xml, переложить во внутреннее представление, при этом только в парсинге xml может быть куча разных типов ошибок. Но сделать мы с этим ничего не можем - файл в любом случае битый. Структура кода будет одна - последовательность вызовов реализующая шаги загрузки, и обработка ошибки в одном месте где мы просто говорим "не шмогла". При желании обрабатываем конкретные типы ошибок с дополнительной информацией и говорим "не шмогла потому что в foo.xml не закрыт тэг <foo> в строке 79". Так вот код загрузки может быть либо кодом загрузки, либо кодом загрузки перемешанным с прокидыванием ошибок. Лучше однозначно первое.
Вы, верно, шутите? RAII или defer.
Есть, но я же отвечал на комментарий про забор. Проходная там стандартная вахтёрская для галочки - первый день когда приехал на конференцию попросили паспорт, потом толпа ходила туда-сюда курить, никто уже ничего не контролировал, как и весь второй день. И кажется что если бы кто-то пошёл гулять по зданию, никто бы не заметил. Но не знаю, может там автоматчики в другом корпусе запрятаны.