amarao (amarao_san) wrote,
amarao
amarao_san

Немного философии ПО

Кто-то на хабре переводил какую-то древнюю статью про софт. И там была очень важная мысль...

Культура юникса - культура текста. Метафоры, которыми оперирует юникс - это метафоры грамматики, когда отношения объектов формулируются в различных формах следования друг за другом, определяющим смысл высказывания. (там же ещё был выпад в сторону виндов, которые отказываются от культуры текста и возвращаются к культуре графических образов).

Я же хочу поговорить о более общем вопросе. Почему до сих пор не появилось ни одной (мейнстримовой) системы с интуитивной реализацией LR-грамматики? Ведь сама LR-грамматика весьма частный случай множества других грамматик, но даже его (реализующегося в 20кб сишного кода после обработки yak'ом 3-5кб исходника) не могут реализовать графически.

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

Вот, например, придумали пайп, stdin/out, именнованный пайп. Примитивная (с технологической точки зрения вещь). Однако, грамматическая форма "данные из А в Б", столь легко понимаемая умом и столь же легко реализуемая техникой, почему-то не может быть так же легко реализована в графической среде. Что есть аналог пайпа? Можно ли данные из одного графического приложения передать в другое? Можно ли сформулировать утверждение вида "взять всё из альбома, порезать в пикасе, засунуть в склеивальщик панорам, положить в новый альбом"? Нет, любые средства автоматизации всего лишь предоставят довольно громоздкий point-and-click интерфейс для мучительного сочетания фильтров и заданий. В получившемся решении будет слишком много хардкоженного, это не будет грамматическая конструкция, это будет просто "фича программы". Альтернативно, программа покажет консольку и предложит написать в ней нужное. Опять же, либо текст с грамматикой, либо визуальность.

В консоли нет особого очарования. Очарование есть в текстовом интерфейсе, позволяющим изъясняться на каком-то языке. Вы не можете изъясняться на языке "window manager'а", но можете на языке шелла. Потому любое ncurses приложение есть всего лишь жалкое подобие нормального графического приложения, оно "имтирует" интерфейс.

... Однако, графические интерфейсы имеют своё значение. Некоторые вещи не требуют текстового выражения. Нам не мощь скриптового языка для того, чтобы нажать "назад" в браузере или ткнуть в ссылку. Более того, иконка "выкл" или даже физическая кнопка куда более удачное решение, чем shutdown -h now (что не отменяет фич самого shutdown).

Вероятнее всего, развитие интерфейсов (именно развитие, а не утыкивание перделками) должно строиться на развитии двух различных направлений и поиске метода их объединения:

1) Развитие средств выражения, снижение объёма "держу в голове" и "тупого кодинга". Цель - позволить выразить человеку нетривиальную (новую) мысль в понятной для машины форме. Ключевое: мысль должна быть нетривиальной, то есть выходящей за рамки повседневных действий. Это не обязательно команда, скорее, команды в текстовом виде, это некоторый пережиток. Это утверждения, формулировки, запросы. (да, да, мы плавно переходим к запросам в ИКС, в том числе в поисковики).

2) Развитие командных интерфейсов. При всей моей любви к консоли я считаю, что интерфейс _командной_ строки есть ошибка. Человек не должен говорить, что делать, он должен говорить, что он хочет. (What do you wish for? _). Графические же интерфейсы как раз очень хорошо подходят для оперативного командования. И в этом смысле большинство современных интерфейсов - ужасны. Сравните объём и сложность задачи удержания курса автомобиля и лёгкость этого действия с помощью руля (замените руль на две группы radiobutton, одна из которых задаёт направление поворота, а вторая угловую скорость и вы поймёте, насколько охрененно придуман руль).

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

... Кстати, в той же консоли есть несколько таких удобных универсальных команд: Ctrl-D, Ctrl-Z, Ctrl-C, Ctrl-L... К сожалению, они реализуют очень узкий (хоть и часто нужный) набор функций, и совсем не предусматривают хоть сколько-то аналогового управления.

Наверное, современные точскрины чуть-чуть приближают нас к этой форме, но всё осложняется тем, что разработчики не чувствуют грани между командой и выражением мысли, и предлагают все мысли выражать последовательностью команд. Я вполне поддерживаю команду "увеличить", но я уже не совсем поддерживаю возможность выбрать 5 из 10 файлов и перетащить их в другое место. Это уже оформленная в виде набора команд мысль о том, что нужно сделать.

Понятно, что даже гик не будет использовать SQL в повседневной жизни. Слишком много печатать (и эта чёртова точка с запятой в конце...), слишком низкоуровневы термины и слишком нечеловеческая грамматика.

Но если появится голосовой интерфейс, который позволит свободно командовать (свободно, а не экспериментально!) компьютером, то, возможно, под него и появится язык, являющийся компромиссом между человеком и машиной. "собрать вчерашние файлы про сепульки сюда" - это охрененный запрос, правда? Впрочем, ошибаюсь, это опять команда. "Мне нужно предупреждение за 14 дней о днях рождения родни, причём так, чтобы я не забыл" - это уже круче. Сильно круче. Даже если его переформулировать в командный вид "предупредить за 14 дней...", то это не ухудшит идеи запроса - реши-проблему-мне-пофигу-как-я-сказал-что-мне-нужно. Другой вариант запроса: "меня надо в рабочие дни будить за час до выхода так, чтобы я успел доехать на работу к 9:00". (высчитать среднее время поездок, построить функцию зависимости времени поездки от сообщений о пробках, погоде и дне недели, учесть эту завимость для рассчёта времени выхода из дома).

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

Это должны быть именно запросы, причём запросы, однозначно понятные машине.
Tags: философия
Subscribe

  • systemd-networkd, netlink и arp флуд

    Нереально странный баг пофикшен с помощью eBPF затычки. Для меня большой неожиданностью является реакция на него.…

  • Rust soundness

    Каждый раз, когда я сталкиваюсь с маленькими "но" в Rust'е, это ощущение тщательной продуманности. Например, простейшие fold-функции для итераторов:…

  • still_ntp

    В ходе локального мозгового штурма у меня родилась суперидея. Надо написать ntp сервер, который может отдавать указанную дату. Т.е. сказали при…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 14 comments

  • systemd-networkd, netlink и arp флуд

    Нереально странный баг пофикшен с помощью eBPF затычки. Для меня большой неожиданностью является реакция на него.…

  • Rust soundness

    Каждый раз, когда я сталкиваюсь с маленькими "но" в Rust'е, это ощущение тщательной продуманности. Например, простейшие fold-функции для итераторов:…

  • still_ntp

    В ходе локального мозгового штурма у меня родилась суперидея. Надо написать ntp сервер, который может отдавать указанную дату. Т.е. сказали при…