From df85df9cd875f95146de87d6574eda250bf4438b Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Tue, 17 Jun 2025 22:42:18 +0300 Subject: [PATCH] =?utf8?q?=D0=9F=D0=BE=D1=87=D0=B5=D0=BC=D1=83=20=D0=BC?= =?utf8?q?=D1=8B=20=D1=85=D1=80=D0=B0=D0=BD=D0=B8=D0=BC=20=D0=BA=D0=BE?= =?utf8?q?=D0=B4=20=D0=B2=20=D1=82=D0=B5=D0=BA=D1=81=D1=82=D0=BE=D0=B2?= =?utf8?q?=D1=8B=D1=85=20=D1=84=D0=B0=D0=B9=D0=BB=D0=B0=D1=85=3F?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit https://habr.com/ru/articles/918512/ приходится использовать кодировки. Существует много вариантов: UTF-8 или UTF-16; с BOM или без него; CR, LF или CRLF; little-endian или big-endian. К сожалению, мир не смог договориться об одном стандарте, поэтому то и дело приходится сталкиваться с проблемами: испорченные диффы, ошибки в тулзах, проблемы с копированием, нечитаемый текст на фронте. Вообще то договорился: UTF-8. Никаких BOM, никаких endiannes. Только Microsoft (ну и Apple наверняка) принципиально будет плевать на совместимость и будет делать лишь бы чтобы отличалось от других. Перестань использовать дерьмо от Microsoft и никаких испорченных diff, проблем с копированием и подобного. почему мы должны заботиться о пустых строках, табуляции или пробелах, ограничениях по длине строк и других несущественных деталях? Не должны, поэтому есть средства автоформатирования. Текст тут мало чем мешает. Зачем нам имена файлов и ограничения с ними связанные? Ну... давайте иметь мена таблиц и колонок и ограничения с ними связанные? Разве это удобно использовать двухбуквенные расширения для указания используемого языка? Нет, не удобно. А кто так делает? Может не надо использовать того кто так делает? А ограничения на глубину вложенности каталогов или inotify watch limit? Так не делай безумства. Или предложение по замене на ограничения вложенности в другом формате? Или вот мы запускаем код в докере, а контейнер не видит изменения файлов на хосте, куда это годится? Так не запускай его там или разберись как оно работает. Если не понимаешь, то может перестанешь использовать чёрный ящик? А еще мы работаем на разных файловых системах, и они предоставляют нам разные функции. Чувствительность к регистру или нет? Жесткие и символические ссылки. Права доступа. Атрибуты. Все эти особенности не имеют отношения к нашему коду, по крайней мере, вы обычно не можете прочитать о них в спецификации вашего языка. Действительно, (почти) всё это не имеет отношение к коду. Так что причём тут это. А работать с ФС придётся. Или перестань использовать зоопарк ФС. Поэтому иногда IDE тупит во время загрузки проекта. Ну так перестань использовать его. Кэшируй AST и метаинформацию. Используй адекватные по сложности парсинга языки. Автор же перечисляет JavaScript, Web. Короче, автор предлагает из-за убогости и идиотичности используемых им инструментов, вообще перейти на бинарные форматы, БД, чтобы ещё больше было несовместимости, несостыковок и невозможности инструментам взаимодействовать друг с другом. Если уж, как заявляет автор, мир не смог договориться о CR/LF и BOM-ах с UTF-ами, то как можно будет договориться о гораздо более сложных вещах? Писать хоть на JS, хоть на Java можно в принципе и в Nano, и в IDE и в Vim/Emacs. А теперь у нас будет ровно один/два инструмента, один хуже другого, без возможности написать свой из-за лютой переусложнённости. Производительность и сокращение выбросов CO2 Перестань писать на JS и запускать IDE -- конец глобальному потеплению. Всё это такой же дебилизм, как идея использовать бинарные журналы в systemd/journald (ведь нельзя же, видимо, индексировать текстовые файлы, только бинари, и плевать что там нет целостности журнала). -- 2.51.0