ADD-2011 (Рецензии Стаса Фомина)

Подстраницы (4) →

• Философия_простоты,_или_еретическая_лекция_о_программировании_(Никита_Прокопов,_ADD-2011)

«Nobody likes molting boron» © Futurama. Разумеется, никто не любит сложность. Это хорошо видно и по остальным отзывам к докладу. Сложность систем, сложность интерфейсов.

Но для меня сложность — это не легкое раздражение при виде меню из пяти пунктов, вместо кнопки «включить». Сложность — это стресс, это нервы, это специализация, это риски «тут ничего не сможет сделать неспециалист», причем специалист становится фантастически редкой штукой.

Нереально вручную починить иномарки и бытовую технику — хотя вроде бы интерфейс-то у них простой, а сложность упрятана за сотни пломб.

Позволю отвлеченный пример. Когда-то я смотрел комедию братьев Коэнов «Аэроплан», где разыгрывалась смешная сценка — в небе летит пассажирский лайнер, где все, кто выбрал на обед рыбу — отравились. Включая пилотов. Стоит фантастическая задача — найти среди пассажиров кого-то, кто сможет посадить этот Боинг. И доктор — комедийный персонаж Лесли Нильсена, говорит стюардессе «Вам нужно не только найти человека, который сможет посадить самолет. Но и того, кто не ел на обед рыбу». Тут разумеется смех в зале, за кадром и везде. Бггг — сравнил вероятность найти пилота среди паксов, 1/100500 и 50/50 (выбор «рыба или курица» за обедом).

Какого же было мое удивление, когда я таки добрался до первоисточника, на который сняли эту пародию, «[Взлетно-посадочная полоса ноль-восемь]» Артура Хейли, и обнаружил, что исходный диалог еще более адовый:

- Мисс Бенсон, вы когда-нибудь слышали о теории вероятности?

- О теории вероятности? Я полагаю, да. Но я не знаю, что это такое.

- Я вам объясню. Это значит вот что. Из общего количества в пятьдесят шесть человек наш единственный шанс выжить зависит от того, есть ли на борту человек, который не только способен посадить эту штуковину, но и который бы НЕ ЕЛ рыбу на обед. ©

(и кстати, рыбу там выбрали только 30% пассажиров). По тексту также видно, что полно персонажей тоже летчики (газетчики и т.п.), и вообще, умение управлять самолетом было не rocket science, ну может как водительские права для СССР в застое.

Кстати, сюжет не совсем художественный — были реальные случаи, пассажир-пилот в 1954 отлично посадил самолет, после приступа аппендицита у первого пилота (со вторым там какая-то паника приключилась). А сейчас, если среди пассажиров лайнера вдруг оказались люди умеющие им управлять — это наоборот, офигенный фактор риска, что самолет полетит совсем не туда (9/11).

Так вот, в этом докладе был взят классический беспроигрышный вариант — взять программерские тулы и фреймворки, издревне известные негламурностью интерфейсов и демонстративно отпинать за это самое. Я был особенно польщен, что с особым восторгом отпинали мой совет линуксоидам, у которых нет тулы для записи скринкастов (я просто не в курсе), как это можно сделать пайпом из двух непредназначенных для этого утилит (Я сам не очень линуксоид, поэтому альтернативы не нашел).

Однако почему это так? Почему программерские тулы любят настройки, опции? Может это заговор программистов? против программистов?

Почему они не хотят использовать красивый и гламурный GUI-based SourceSafe, а возятся с таким исчадием ада как Git? Без conspiracy theory тут не разобратся, наверняка это влияние ордена тамплиеров, и чтобы бросить ему вызов нужна проповедь еретика.

На самом деле все просто. При выборе «Свобода или гламур», «Возможности или кажущаяся простота» программисты выбирают свободу и возможности. Страховка от неверного выбора — это отдельный вопрос, он решается не запаиванием пульта управления под девизом «вам это не нужно», а контролем версий, тестами, и т.п. А в остальном — все для максимальной производительности, для максимума скорости, все для победы.

Если серьезно работаешь, каждая мелочь в твоем инструменте может стать важной, и правильная настройка сэкономит годы жизни. От чего можно отказаться в текстовом редактире? От настройки шрифтов? Клавиатурных сокращений? Настраиваемой синтаксической раскраски? Режима редактирования колонками? Вызова внешних команд? Разбора их вывода? ... Мне нужно все. И больше. Ах много настроек? — ничего, я справлюсь с этим.

Всего этого я жду от любой программы, включая медиаплеер. Я хочу, чтобы программа могла сделать все, на что она потенциально способна. Плеер? ОК. Ты должен уметь играть быстрее и медленее, управлятся с клавиатуры, причем глобально (хрен иначе сделаешь стенограмму), переключать звуковые дорожки и субтитры, должна быть эффективная навигация по видеофайлу, обязателен и commandline интерфейс. Да, такой только один, VLC, и то, я хочу от него еще кучу фич! Ах, он не гламурен, нет скина со свистелками-перделками, в диалоге настроек много страшных опций пугающих хомяков? Мне плевать! Раз он на порядки эффективней.

И так во всем остальном. В молодости простительно жаждать простоты, и плевать на эффективность — еще мало знаешь, время твое дешево, и его очень-очень много. Пройдет лет 10, и станет ясно, что времени осталось чуть, каждый час на счету, на счету и остатки зрения, нервов и т.п. — и растрачивать это, пользуясь простыми немудренными мотыгами вместо тракторов — глупо.

И фантастически обидно пользоваться, внешне простым и гламурным инструментом или фреймвором, когда никак, ни за что нельзя (даже если это нехорошо), залезть и использовать так, как тебе надо — автоматизировать через командную строку, посмотреть внутренние структуры данных и т.п.

Я не хочу внезапно оказаться в воздухе на лайнере без пилотов! Пусть даже он будет внутри сто раз гламурен, а интерфейс кресла просто до невозможности.

Я против тупого гимна простоте — «Будь проще, и люди к тебе потянутся» — тут потянутся такие люди, что об этом сто раз пожалеешь.

Да, сложность бывает необоснованной, бывает заградительной на начальном этапе — а я хочу, чтобы была невырожденная кривая обучения! Чтобы можно было пользоваться и с нуля, прочитав «Getting Started», «Crash course» или «Airplanes for dummies», но продолжать совершенствование, не упираясь запаянные люки в потолоке.

Но это уже совсем другой вопрос, как обеспечить это — вот это уже интересная задача.

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

Надо развивать эти мысли на отдельную тему «Usability for advanced users». Будучи в программном комитете я долго сопротивлялся этому докладу, ибо изобретенный велосипед мне казался очень специфическим и редким. Но все равно он достоит внимания. Да и кто без греха? Вот и я делал поделки для визуализации коллективной работы, и доклады «швейцарским ножом» обзывал…

И в целом, я понимаю, что такое удобно сделанный под твою задачу инструмент, повышающий твою эффективность на порядки (хотя в зале указывали, что для визуализации жизни кластера давно есть крутое http://meta.rocksclusters.org/ganglia/ и возможно этот велосипед излишен). И что эффективный инструмент скорее всего будет не в парадигме «визивига», где надо тыкать кнопки, заполнять тыщи полей, и двигать мышью виджеты, а будет работать в парадигме «запрос—ответ» и «визуализации компактных требований», каковые удобно делать либо в командной строке, либо кратким предметным языком. Так вот, я просмотрел доклад в записи, которую же сам и смонтировал пользуясь изобретенным command-line видеоредактором, слушающим команды и спецификации для видеомонтажа.

Другое дело — все-таки очень ограничена предметная область, подлежащая визуализации этими тулами. Плоские графики с временной осью, серии или числовая ось... А преимущество «уанлайнера» несколько лукавое — «лайн» длиной в килобайт — это уже не лайн, line — это то, что можно набить за пару секунд, т.е. не больше пары десятков символов. А больше — это уже надо писать компактный dsl, который можно делать расширяемым, и таким же удобным и интерактивным — хороший, компактный DSL, без кучи «зюк и хрюк», скобок, кавычек двух типов, символов продолжения линий..., так вот, такой DSL, удобный и читаемый, ибо для читаемости можно и отступы использовать и переводы строк и пробелы — открыт в одном окне в редакторе, а в консоле происходит запуск тулы. Редактировать параметры и смотреть, как меняется картинка — гораздо быстрей и удобнее! И да — тут нет ограничений на отсутствия гуя — картинки то все равно надо смотреть!

В некотором смысле это проблема «уанлайн» подхода — сначала все кратко и красиво, а потом, с ростом задачи понимаешь, что к черту awk, лучше сразу perl, а то и python.

Забавно, что когда-то давно у нас и металогика алгоритмов учетных систем была «уанлайнером», с обвешанными семантикой символами «@!$», что знатно выносило мозг незнакомым с этой нотацией аналитикам, но потом это стало жать и самим разработчикам.

Т.е. если бы я начал решать эту задачу, это был бы python + matplotlib или pycairo (ну или другая библиотека визуализации), где все кишки бы я спрятал в отдельный модуль, а оставил лишь формулировку задачи компактной Python-функцией (что бы бы офигически и прозрачно расширяемо). Ну и если спектр графиков у меня получился бы совсем простым, я бы сделал простой DSL, то тоже редактируемый, с разбиением на строки, с максимальной читаемостью.

Я так и не придумал, чтобы мне можно было визуализировать этими тулами (полно всего просит визуализации, но там и графы и многомерность и динамика треба, на плоскость «время-серии» ничего не ложится), но вот что мне надо на самом деле — попрактиковаться в Haskell. И возможно для этого я и поковыряю исходники этих тулов, благо они опубликованы, да и писал их не какой-то ламер, а antilamer и эксперт по функциональному программированию.

---

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «ADD-2011 (Рецензии Стаса Фомина)»