Заметки и переводы

Различие в культурах Unix и Windows

2022-09-12

andpop

Linux

Глава 13 “Бикультурализм” из книги Д. Спольски “Джоэл о программировании”

К данному моменту у Windows и UNIX функционально стало больше сходства, чем различий. Здесь и там поддерживаются одни и те же основные метафоры программирования, от командной строки до GUI и веб-серверов; они построены вокруг примерно одной и той же совокупности системных ресурсов, включая почти идентичные файловые системы, память, сокеты, процессы и потоки. Базовый набор сервисов каждой из этих операционных систем почти не ограничивает разнообразия создаваемых приложений.

Остались лишь культурные различия. Да, мы все принимаем пищу, но они там деревянными палочками едят сырую рыбу с рисом, а мы здесь едим руками куски молотой коровы на хлебе. Культурные различия не означают, что американские желудки не могут переваривать суши или что японские желудки не могут переварить биг-мак, и не означают также, что не может быть множества американцев, которые едят суши, или множества японцев, которые едят бургеры, но они означают, что у американца, впервые спустившегося по трапу самолета в Токио, возникает ошеломляющее чувство, что это место необычно, и никакое философствование о том, что в глубине мы все одинаковы, мы любим, работаем, поем и умираем, не может отменить того обстоятельства, что американцы и японцы никогда не смогут понастоящему привыкнуть к тому, как устроены туалеты в другой стране.

Каковы культурные различия между программистами UNIX и Windows? Есть много деталей и тонкостей, но по большей части они сводятся к одному: в культуре UNIX ценится код, который полезен другим программистам, а в культуре Windows ценится код, который полезен непрограммистам. Конечно, это большое упрощение, но ведь это действительно большая разница, для кого мы программируем – для программистов или конечных пользователей! Все остальное – комментарии.

Нередко провоцирующий полемику Эрик С. Рэймонд (Eric Raymond) написал большую книгу под названием «The Art of UNIX Programming» (Addison-Wesley, 2003), подробно исследовав в ней эту культуру. Можно купить бумажное издание и прочесть его либо, если взгляды и принципы Рэймонда слишком «антиидиотарны» для вас и вы не хотите платить ему денег, почитайте ее в Интернете бесплатно, сохранив уверенность, что автор не получит от вас ни копейки за свой тяжелый труд.

Рассмотрим простой пример. В культуре программирования под UNIX высоко ценятся программы, которые могут вызываться из командной строки, принимать аргументы, контролирующие самые различные аспекты их поведения, и результат работы которых может быть получен в виде регулярно форматированного обычного текста, доступного для чтения машиной. Такие программы ценятся, потому что программистам легко включать их в другие программы или более крупные программные системы. Один маленький пример: в культуре UNIX есть важная ценность, которую Рэймонд называет «молчание – золото», означающая, что, если программа успешно выполнила в точности то, что вы ей сказали, она не должна вообще ничего выводить. Неважно, что вы сделали – ввели команду из 300 символов для создания файловой системы, или скомпилировали и установили сложный программный пакет, или отправили пилотируемый космический корабль на Луну. Если выполнение прошло успешно, считается, что не надо выводить ничего. Если снова появляется подсказка командной строки, пользователь заключает из этого, что все OK.

Это важная ценность в культуре UNIX, потому что вы программируете для других программистов. Как отмечает Рэймонд, «болтливые программы обычно плохо взаимодействуют с другими программами». Напротив, в культуре Windows вы программируете для тетушки Мардж, и тетушку Мардж можно оправдать, если она считает, что программу, которая ничего не вывела, потому что успешно отработала, нельзя отличить от программы, которая ничего не вывела, потому что произошел сбой, или программы, которая ничего не вывела, потому что не поняла ваш запрос.

Аналогично в культуре UNIX ценятся программы, не выходящие из текстового режима. Там недолюбливают GUI, если не считать раскраски, явно нанесенной поверх текстового режима, и не любят двоичные форматы файлов. Это вызывается тем, что программировать взаимодействие с текстовым интерфейсом гораздо проще, чем, скажем, взаимодействие с GUI, что почти невозможно делать в отсутствие некоторых прочих условий, типа встроенного языка сценариев.

Здесь мы снова сталкиваемся с тем, что культура UNIX ценит код, полезный другим программистам, что редко бывает целью при программировании в Windows . Это не значит, что все UNIX-программы разрабатываются исключительно для программистов. Далеко не так. Но культура ценит то, что полезно программистам, и этим кое-что объясняется.

Предположим, что у нас есть UNIX-программист и Windows-программист и оба они получили задание создать одинаковое приложение для конечного пользователя. UNIX-программист создаст базовое приложение командной строки или с текстовым интерфейсом и, может быть, с некоторым опозданием и нехотя построит GUI над этим базовым приложением. В результате основные операции этого приложения станут доступны другим программистам, которые смогут вызывать программу из командной строки и получать ее результаты в текстовом виде.

Программист Windows скорее всего начнет с GUI и, может быть, с некоторым опозданием добавит язык сценариев, автоматизирующий действие GUI. Это естественно для культуры, в которой 99,999% пользователей никоим образом не являются программистами и не испытывают желания стать ими.

Есть большая группа Windows-программистов, которые пишут код преимущественно для других программистов: это собственно команда Windows внутри Microsoft. Они стремятся к тому, чтобы создать API для вызова из языка C, реализующий функциональность, а затем создавать GUI приложения, обращающиеся к этому API. Любое действие, которое можно осуществить из интерфейса пользователя Windows, можно выполнить также через интерфейс программирования, вызываемый практически из любого языка программирования.

Например, собственно Microsoft Internet Explorer представляет собой лишь крошечную программу размером 89 Кбайт, служащую оболочкой для десятков очень мощных компонентов, свободно доступных квалифицированным Windows-программистам и в большинстве своем обладающих гибкостью и мощью. К сожалению, поскольку программистам недоступен исходный код этих компонентов, последние можно использовать только такими способами, которые были предварительно рассмотрены и разрешены разработчиками компонент в Microsoft, что не всегда может удовлетворить другого программиста. Кроме того, иногда обнаруживаются ошибки, в которых обычно виноват тот, кто обращается к API, и которые трудно или невозможно отладить в отсутствие исходного кода.

Тенденция UNIX-культуры предоставлять исходный код делает ее средой, для которой легче разрабатывать приложения. Любой разработчик приложений для Windows может рассказать вам, как он потратил четыре дня на исправление ошибки, потому что полагал, что объем памяти, возвращаемый функцией LocalSize, будет таким же, как размер памяти, которую он изначально запросил в LocalAlloc, или про какую-нибудь другую ошибку, которую он исправил бы в десять минут, будь ему доступен исходный код библиотеки. В качестве иллюстрации Рэймонд сочиняет занятную историю, в которую вполне может поверить всякий, кто имел дело с библиотеками в двоичном формате.

Теперь вы видите, в чем суть этих религиозных споров. UNIX лучше, потому что при отладке можно зайти в библиотеки. Windows лучше, потому что тетушка Мардж может увидеть подтверждение того, что ее почта действительно отправлена. На самом деле ни та, ни другая системы не лучше. В них просто разные системы ценностей.

В UNIX главная ценность – облегчить жизнь другим программистам, а в Windows главная ценность – облегчить жизнь тетушке Мардж.

Рассмотрим еще одно культурное различие. Рэймонд пишет: «Классическая документация UNIX пишется телеграфным стилем, но она полная… Этот стиль предполагает активного читателя, способного сделать очевидные и неупомянутые выводы из сказанного и обладающего достаточной уверенностью в себе, чтобы доверять этим выводам. Внимательно читайте каждое слово, потому что едва ли вам дважды станут повторять одно и то же». Боже мой, подумал я, ведь фактически он рекомендует молодым программистам продолжать писать никому не понятные страницы руководства.

С конечными пользователями такое не проходит. Рэймонд может называть это «сверхупрощающим высокомерием», но в культуре Windows признано, что конечные пользователи не любят читать, и если они снизойдут до того, чтобы прочесть вашу документацию, то прочтут только самое необходимое, и вам придется давать объяснения еще и еще раз… Отличительной чертой хорошего файла подсказки Windows является то, что средний читатель может изучать любую тему в отдельности, для чего ему не требуется знание каких-либо других тем.

Как же получилось, что базовые ценности оказались разными? Это еще одно достоинство книги Рэймонда: он уходит глубоко в историю и эволюцию UNIX и вооружает молодых программистов знанием всего исторического опыта культуры, начиная с 1969 года. Когда создавалась UNIX и формировались ее культурные ценности, конечного пользователя не существовало. Компьютеры были дороги, процессорное время было дорого, и знания о компьютерах сводились к тому, как программировать. Неудивительно, что образовавшаяся культура ценила то, что было полезно другим программистам.

Напротив, Windows создавалась с единственной целью: с выгодой продать как можно больше экземпляров. Мириады экземпляров. «Компьютер на каждом рабочем столе и в каждом доме» – вот что было прямой задачей разработчиков Windows, определяло их повестку дня и базовые ценности. Легкость использования непрограммистами была единственным способом получить доступ на каждый рабочий стол и в каждый дом, и потому «юзабилити Uber alles» стало культурной нормой. Программисты как целевая группа рассматривались на самом последнем месте.

Культурный раскол настолько глубок, что UNIX, по сути, никогда не претендовала на настольные системы. Тетушка Мардж фактически не сможет пользоваться UNIX, а неоднократные попытки создать для UNIX красивый интерфейс, с которым тетушка Мардж сможет работать, полностью провалились, потому что эти попытки делались программистами, насквозь пропитанными UNIX-культурой.

Например, UNIX поддерживает принцип разделения политики и механизма, исторически идущий от разработчиков X. Он прямо привел к расколу в пользовательских интерфейсах; договориться во всех деталях о том, каким должен быть UI настольной машины, толком никогда не могли, и считается, что это нормально, потому что в этой культуре ценится разнообразие. А вот для тетушки Мардж совершенно неприемлемо использовать в разных программах разные интерфейсы для копирования и вставки.

Вот таково положение через 20 лет после того, как разработчики UNIX начали попытки приладить к своим системам приличный интерфейс пользователя, когда глава крупнейшего поставщика Linux высказывает мнение, что домашним пользователям следует работать в Windows. Я слышал утверждения экономистов о том, что Кремниевую долину невозможно было бы воспроизвести, скажем, во Франции, потому что французская культура так жестоко наказывает неудачников, что предприниматели стараются не рисковать. Возможно, то же справедливо в отношении Linux: она может никогда не стать настольной операционной системой, потому что в ее культуре ценятся вещи, препятствующие этому.

Доказательством служит OS X: компания Apple все-таки создала UNIX для тетушки Мардж, но только потому, что инженеры и менеджеры Apple были прочно связаны с культурой конечного пользователя (которой я захватнически присвоил название «культуры Windows», хотя исторически она возникла в Apple). Они отказались от фундаментальной нормы культуры UNIX – построения вокруг интересов программиста. Они даже переименовали главные каталоги – полная ересь! – и стали употреблять обычные английские слова, например «applications» и «library» вместо «bin» и «lib».

Рэймонд делает попытку сравнить и противопоставить UNIX и другие операционные системы, и это самая слабая часть прекрасной в остальных отношениях книги, потому что он не знает предмета, о котором ведет речь. Как только он заговаривает о Windows, обнаруживается, что источником его знаний программирования для Windows оказываются по большей части газеты, а не опыт программирования в Windows. Ну и пусть, он – не Windows-программист, и простим ему это. Как это характерно для человека, глубоко знающего одну культуру, он знает, что ценится в его культуре, но плохо различает те части его культуры, которые универсальны (убиение старушек, аварийное завершение программ: всегда плохо), и те, которые относятся только к программированию для программистов (сырая рыба, аргументы командной строки: смотря для кого).

Есть очень много монокультурных программистов, которые, как типичный американский парень, никогда не выезжавший за пределы Сент-Пол, штат Миннесота, не ощущают разницы между ценностями, принадлежащими некой культуре, и базовыми человеческими ценностями. Я очень часто встречал UNIX-программистов, издевавшихся над программированием в Windows и считавших Windows варварством и глупостью. Рэймонд слишком часто попадает в ловушку пренебрежительного отношения к ценностям других культур без учета их истоков. Такой фанатизм довольно редко встречается среди программистов Windows, которые в целом ориентированы на решение задачи и свободны от идеологических предрассудков. Во всяком случае Windows-программисты признают недостатки своей культуры и прагматически говорят: «Видите ли, чтобы продать текстовый процессор как можно большему числу людей, его надо научить выполняться на их компьютерах, а если из-за этого приходится хранить настройки в Гнусном Реестре, а не в элегантных файлах ~/.rc, то тут уж ничего не поделаешь».

Мир UNIX пышет самодовольством культурного превосходства, пропаганды и поклонения карме Slashdot, тогда как мир Windows более практичен («да, что делать, надо же на жизнь зарабатывать»), и поэтому культура UNIX чувствует себя осажденной, не способной вырваться из серверной стойки и области хобби на широкие просторы настольных машин. Это высокомерие слабости – самый большой недостаток книги «The Art of UNIX Programming», хотя сам по себе он не столь велик.

В целом в книге настолько много чрезвычайно интересного и глубокого проникновения во многие аспекты программирования, что можно вытерпеть отдельные дурно попахивающие идеологические эскапады ради возможности многое почерпнуть из нее относительно всеобщих идеалов.

Я действительно рекомендую эту книгу разработчикам, к какой бы культуре они ни принадлежали, на любой платформе, с любыми задачами, потому что очень многие из провозглашаемых в ней ценностей являются универсальными. Когда Рэймонд указывает, что формат CSV хуже, чем формат /etc/passwd, он думает тем самым добавить очков UNIX против Windows, но знаете что? Он прав. /etc/passwd действительно проще разбирать, чем CSV, и, прочтя его книгу, вы узнаете почему и станете лучше как программист.

Read All
Сравнение файлов в Vim и Neovim

2022-09-08

andpop

Vim
В составе Vim устанавливается утилита vimdiff для сравнения содержимого файлов.
```
$ vimdiff file1.txt file2.txt
```
При этом в Vim открываются два окна с файлами, где цветом выделены различия в строках этих файлов. Также запустить Vim в этом режиме можно с помощью ключа -d:
```
$ vim -d file1.txt file2.txt
```
После установки Neovim команда vimdiff недоступна, открыть файлы в режиме сравнения можно только по ключу -d:
```
$ nvim -d file1.txt file2.txt
```
Можно сделать псевдоним alias vimdiff='nvim -d' и поместить его в ~/.zshrc.

Есть альтернативный способ включить режим сравнения файлов. Открываем два файла в разделенных по вертикали окнах и в каждом буфере выполняем команду :diffthis.

Отключить режим выделения различий можно командой :diffof.
Read All
Установка последней версии SQLite из исходников

2022-09-07

andpop

Linux SQLite
При установке SQLite из стандартного репозитория Ubuntu командой sudo apt install sqlite3 мы получаем старую версию.

Если нужна самая последняя версия SQLite, можно установить ее из исходных кодов на официальной странице https://www.sqlite.org/download.html.

Сначала установим нужные инструменты:
```
sudo apt-get install build-essential tar wget
```
На 07 сентября 2022 года актуальна версия 3.39.03, исходники для нее берем из файла sqlite-autoconf-3390300.tar.gz. Скачиваем этот файл к себе на машину в каталог ~/sqlite.
```
mkdir sqlite
cd sqlite
wget https://www.sqlite.org/2022/sqlite-autoconf-3390300.tar.gz
```
Извлекаем из архива файлы:
```
tar xvfz sqlite-autoconf-3390300.tar.gz
```
Переходим в созданный каталог:
```
cd sqlite-autoconf-3390300
```
Настраиваем код для запуска компиляции:
```
./configure
```
Компилируем SQLite командой make:
```
make
```
Устанавливаем скомпилированное приложение:
```
soudo make install
```
Программа должна установиться, проверим версию:
```
sqlite3 --version
```
После установки в SQLite не работало перемещение по истории команд стрелками вверх/вниз. Для исправления этого поведения установил утилиту rlwrap.
```
sudo apt-get install rlwrap
```
Добавил в .zshrc псевдоним:
```
alias sqlite3="rlwrap sqlite3"
```
После этого команды из истории текущего сеанса стали перебираться стрелками вверх/вниз.
Read All
Утилита bat - улучшенный cat

2022-08-31

andpop

Linux
Консольная утилита bat для просмотра файлов расширяет возможности стандартной cat:
- Подстветка синтаксиса.
- Нумерация строк.
- Интеграция с Git - показывает изменения в файле.
Установка:
```
sudo apt install bat
```
По умолчанию вызывается как команда batcat, чтобы не было конфликта с существующим пакетом bakula-console-qt. Можно сделать симлинк (ярлык) на bat:
```
mkdir -p ~/.local/bin
ln -s /usr/bin/batcat ~/.local/bin/bat
```
Read All
Последние открытые файлы (Most Recently Used files) в Vim

2022-07-17

andpop

Vim

Список файлов, которые открывались в редакторе, показывает команда :ol[dfiles]. Список упорядочен по хронологии.

Зная номер n файла, можно его открыть в нормальном режиме в новом буфере, нажав 'n.

Команда :bro[wse] ol[dfiles] выводит тот же MRU-список и после нажатия <ESC> или q позволяет ввести номер файла для открытия его в новом буфере.

Read All
Vim, markdown и неотображаемые символы

2022-04-27

andpop

Vim

При работе с Markdown-файлами Vim выделяет слова с дополнительным форматированием (например, наклонный и полужирный шрифт или программный код), при этом сами ограничивающие символы (*, _, `) на экране не видны. К сожалению, иногда границы выделения определяются в редакторе неправильно, также неудобно набирать слова, начинающиеся с подчеркивания. В этих случаях отсутствие на экране ограничивающих символов только мешает, а не помогает.

Справиться с этой проблемой очень просто — достаточно отключить подсветку синтаксиса командой :syntax off, после чего на экране отобразятся все символы и можно будет понять, правильно ли сделана разметка текста.

Read All

2/3

Заметки и переводы

Различие в культурах Unix и Windows

Сравнение файлов в Vim и Neovim

Установка последней версии SQLite из исходников

Утилита bat - улучшенный cat

Последние открытые файлы (Most Recently Used files) в Vim

Vim, markdown и неотображаемые символы