Comments 45
достигают точки гниения (enshittification)
Как мягко перевели-то
Скорее всего подойдет "изговниться", возвратная форма словарного глагола изговнить
о как, оказывается, литературно "-ить", а в простонародье слышал, как правило, "-ять"
век живи - век учись
о как, оказывается, литературно "-ить", а в простонародье слышал, как правило, "-ять"
"-ить" - это просто совершенная форма, т.е. процесс уже состоялся, премии выданы, исполнители отдыхают и делятся впечатлениями. А "-ять", это несовершенная форма, когда процесс в самом разгаре, исполнители по уши в ... в работе.
Пока читал, пришёл в голову вариант «точка всратификации» — т.е. после которой софт становится всратым в плохом смысле этого слова. И звучит так же всрато, как исходный термин на английском %)
Суть статьи часто сводят к аббревиатуре DOTADIW, или «Do One Thing And Do It Well» («Делайте что-то одно и делайте это хорошо»).
Я вспоминаю один старый шуточный рассказ про альтернативную реальность, где победил коммунизм, а Билл Гейтс работал в советской шарашке. И они в следующей версии Единой Операционной Системы собирались удалить команду Copy, потому что нарушала этот принцип, ведь можно было обойтись командами Move и Delete.
Исходный манифест, да и сама "философия юникс" годятся исключительно для программ с интерфейсом командной строки.
Слишком велики накладные расходы, слишком далеко пакетное выполнение от требующегося в большинстве случаев мягкого реалтайма.
Давно пора ограничить применения идеологии только теми местами где она уместна.
А где там пакетное?
Как думаете, сколько времени потребуется на выполнение вот этого?)
sleep 1 | sleep 1 | sleep 1 | sleep 1Ответ, в принципе, интуитивно очевиден, иначе бы не было вопроса,
но всё же...
За одну секунду (+ накладные расходы), т.к. все программы в конвейере запускаются одновременно, а их "последовательное" выполнение, которое, как я предполагаю, и имеется ввиду под "пакетным" в вашем ответе -- это исключительно психологическая иллюзия, т.к. вторая программа попросту ждёт ввода от первой.
Чем не мягкий реалтайм?)
cat main.rs | grep "^\s*fn\s" | wc -l
На больших файлах так делать не надо т.к. конвейер гарантированно работает медленнее, чем чтение файла самой утилитой grep.
grep -c "^\s*fn\s" main.rs
"гибкость vs производительность" в чистом виде
по классике, положено делать всё сначала гибко, а потом там (и только там), где тормозит не совместимо с продакшеном - оптимизировать
p.s. это, конечно, сарказм. сам считаю конвейеры хорошим примером красивой, но далеко не универсальной абстракцией, как раз хорошо иллюстрирующей ущербность принципа DOTADIW
p.p.s. в нулевые после Perl много увлекался bash и потоковой обработкой через анонимные pipe'ы, это у которых вот такой синтаксис: >( | | )
так вот начиная с определенной сложности кода и объемов данных bash банально начинал нестабильно работать, вылезали проблемы с гонками, пропусками строк и тп бред (в основном это про ситуации где приходилось на каждую строку ввода стартовать цепочку процессов, где-то что-то не справлялось с очень часто стартующими и умирающими пачками процессов и возникали оборванные pipe'ы, хотя там просто обработка текста шла и падать нечему было)
в итоге красиво разбитые на потоковые микро-утилиты логики пришлось затаскивать обратно в Perl, где всё работало стабильно и быстро
Так а чем использование чистого grep -c не гибкость???
Тут просто пример сделан человеком, который или умышленно делал кривой пример, либо не знает как правильно пользоваться gnu тулз, чтобы минимизировать количество пайпов.
так вот начиная с определенной сложности кода и объемов данных bash банально начинал нестабильно работать
Нет у баша нестабильности от определенной сложности кода. Есть нестабильность, вызванная кривым кодом, в котором не предусмотрели поведение при ошибках или эксепшенах.
Да, у шелл скриптов не хватает полезных конструкций, но вот называть его нестабильным - это просто неправильно.
Ну и сравнивать обработку в баш (который в принципе не любит обрабатывать текст сам, любит вызывать внешние gnu tools), с перлом, который собственно был создан для обработки текста.. Понятно что перл лучший выбор в данном случае.
Использование cat с одним файлом (без конкатенации) с последующей передачей в пайп является плохой привычкой. Команда cat сделана для конкатенации.
Каждый раз, когда вы пишете cat ... | grep ... - в мире умирает один котик. (c)
Да там ещё и регулярка пробелы проверяет, а не границы слов. Так что автор тот ещё советчик. Ну а если хочется скорости, то проще вовсе ripgrep поставить и получить x5 на ровном месте на тех же кверях.
К сожалению, как и в случае с большинством манифестов, этот идеал не выдержал столкновения с реальностью. Программы для Unix могут общаться только в одном направлении и только при помощи отправки потоков текста. Модель имела определённый смысл в терминальной среде, но так и не совершила успешного перехода в десктопные операционные системы. Поэтому популярные современные программы наподобие Photoshop и Word максимально «покрыты коркой сомнительных фич».
Тут прям провокационное заявление с неправильной терминологией.
Во-первых программы для юникс могут общаться не только при помощи отправки потоков (есть еще и аргументы).
Во-вторых не совсем понятно почему современная десктопная операционная внезапно лишается терминала а еще точнее интерфейса с командной строкой.
Если сравнивать GUI программу и CLI, то тут да - передать информацию из одной гуишной программой в другую крайне сложно, ибо нужно всегда согласовывать тип данных. В консоли работаешь с текстом, который в большинстве случаев поддается простой обработке. Да и современные способы работы с текстом только расширяют возможности (запросы в базу из консоли, работа с JSON/YAML)
И манифест ОТЛИЧНО выдержал столкновение с реальностью, ибо он отлично работает для бесплатных open source продуктов, которые могут поддерживаться нерегулярно, контрибьюторы меняются. В этих случаях, зачастую адаптировать привычный простой инструмент под новую версию ОС займет немного времени, в отличие от комбайна с кучей разноплановых фич (которые требуют множество разноплановых зависимостей).
Тут я категорически не согласен с тем, что манифест каким-то образом устарел.
Просто понятно, что его нет смысла применять к крупным комбайнам типа фотошопа или оффиса, да и вообще крупным корпоративным продуктам.
Спасибо!
Хорошая статья. Раскрыли тему с разных сторон. Думал в конце приведете свое высказывание: "Делай хорошо одно и умей взаимодействовать с другими, не создавая проблем".
Ценю, что вы умеете излагать просто и доходчиво.
Пользуясь случаем хотел бы спросить какой-нибудь полезной литературы, как научиться проектировать приложения навроде Obsidian, с модулями и плагинами.
Obsidian такой себе пример, поделка на электроне
Из популярных программ Adobe Indesign сделан как микроядро, расширяемое плагинами
В каком-то смысле это и принцип Шерлока Холмса )
По своей сути Obsidian — это редактор markdown. И он справляется с этой задачей хорошо. Но его настоящая магия заключается в экосистеме плагинов. Плагины Obsidian не ограничиваются включением боковых панелей и добавлением новых элементов меню, они могут добавлять новую функциональность «холсту», на котором редактируется и потребляется контент. Уже написаны плагины, позволяющие встраивать код, генерировать индексы и даже интегрировать большие языковые модели напрямую в обычный процесс написания текстов. Сабреддит Obsidian похож на сообщество водителей грузовиков, хвастающихся своими машинами.
Сабреддит Obsidian похож на помойку, в которой в общем случае очень сложно найти нужную тебе фичу, потому что плагины то не работают с последней версией обсидиана, то делают что-то не то, что нужно тебе, то работают на десктопе, но ломаются на мобилке, то работают, но ломаются после обновления, то еще что-то.
Что неудивительно — их разрабатывают непрофессиональные разработчики, тестирующие только свой узкий кейс в своем окружении.
В итоге чтобы добавить к базовому обсидиану нужную тебе фичу, приходится тратить кучу времени, и хорошо, если не фиксить баг в нужном тебе плагине, и это так геморройно, что проще пользоваться ванильным. Для гиков, может и прикольно, но я, блин, просто хочу пользоваться инструментом и с этой точки зрения реализация этих фич внутри базовой программы, пусть и не такая крутая, но зато тестированная, отлаженная и синхронизированная с основной кодовой базой, мне нравится гораздо больше.
При всей наивности подхода проблема крайне сложная.
Вообще как то редко слышатся истории что из продукта что-то удалили за ненадобностью.
По сути весь софт движется к точке невозврата - жирнее, тормознутее, багованнее, больше, сложнее.
И не всегда это нужно пользователю.
И простого решения не видно, опять же, это противоречит целям бизнеса.
Занятно, что решения тоже есть, пусть и не идеалььные. Мы этого не осознаем, но платформы типа ОС (сама концепция программы), браузеры и прочие виртуальные машины - это средства, частично снимающие остроту проблемы.
Да где ж там редко? Это одна из самых распространённых пользовательских жалоб, что продукт порезали с апдейтом.
В мире Linux, где слова "вертикальная совместимость" являются страшным ругательством, это вообще дело обычное - удалить один компонент, ибо его стало сложно поддерживать, и заменить "альтернативой", более глючной и не поддерживающей и половины функционала исходного компонента.
Но и в виндовых продуктах, включая даже саму Windows, поубирать часть фич постоянно умудряются.
Да что далеко за примером ходить, даже Хабр при переходе на новый дизайн лишился кучи полезных фич, которые чем-то заменять никто и не собирается.
Прекрасная идея Кернигана и Пайка так никогда и не дала плодов.
Разве? Дала, еще даже до публикации манифеста. Консоль и её трубы не просто популярны, а даже главный конкурент выпустил свой, "power" shell...
Терминал Unix не захватил в одночасье весь мир
Ну, как сказать, как сказать. Когда-то лично даже и не предполагал, что 2023 году, со всем этим вашим девопсом, умение в bash будет цениться и оплачиваться НАСТОЛЬКО хорошо.
Консоль и её трубы не просто популярны, а даже главный конкурент выпустил свой, "power" shell...
Справедливости ради, консоль с трубами у главного конкурента были с момента первых версий MS DOS, и с тех пор никуда не девались.
умение в bash будет цениться и оплачиваться НАСТОЛЬКО хорошо
Ни баш, ни пауершелл, это не про манифест Кернигана и Пайка. У них там было про атомарность функционала, а не про запуск консольных приложений-октопусов.
А мне сразу вспомнился виндовый Total Commander: весьма удобный, легковесный, гибко конфигурируемый комбайн, с тонной плагинов.
Для подсчёта количества функций в файле Rust можно выполнить такую команду
И тут вдруг мы попадаем на многострочный комментарий или многострочный строковый литерал, в котором случайно есть такая подстрока - и всё летит к чертям.
Ещё посоветуйте HTML регекспами парсить...
Или сколько "старых добрых" bash-скриптов сломают себе шею на именах файлов с пробелами.
Если бы только с пробелами! Проблемы может создать и восклицательный знак, и слэш, и попавшиеся в неподходящем месте символы ~, #, =, и кавычки. И это ещё только имена файлов! Когда речь идёт о путях, там всё ещё печальнее, и способов зафейлиться на ровном месте намного больше.
Подавляющее большинство граблей при работе с Bash вызваны именно его отвратительной работой со строками (подстановка). Как ни старайся, сколько ни предусматривай особых ситуаций, а рано или поздно при обработке большого количества файлов всё равно попадётся нечто такое, что сломает скрипт.
Поэтому если нужно быстро и просто сделать что-то такое, что будет работать на сотнях тысяч файлов и гарантированно не зафейлится при подстановке/конкатенации - в топку Bash, берём Python и пишем скрипт на нём, благо консольные утилиты из Python без проблем запускаются.
если нужно быстро и просто сделать что-то такое...
что сможет хоть как-нибудь адекватно и удобоваримо прожевать ошибку и указать на место в котором она случилась, а не сдохнуть в процессе вывалив exitcode 1 где-то в дебрях субшелла, берём Питон.
Нет, можно конечно и на баше добиться чего-то отдаленно похожего, но зачем?
Керниган и Пайк были правы: делай что-то одно и делай это хорошо