Настоящими программистами считается, что ничего лучше интерфейса командной строки пока не придумали и никогда не придумают, потому что лучше уже некуда. Естественно, хочется поспорить.
Чтобы лучше понимать друг друга, давайте разговаривать об абстрактных апельсинах. Представьте себе Автокад, если слышали или доводилось попробовать. Можно Иллюстратор или КорелДро, что-нибудь далекое от программирования, чтобы абстрагироваться и рассуждать непредвзято. Почему они не могут работать в консоли?
Рис. 1. Абстрактный интерфейс в вакууме.
Первое: нужно иметь общую картину происходящего. Писать команду
Один взгляд на общую картину может сразу все прояснить для человека, тогда как над запросами надо думать, надо интерпретировать результаты (каждый ответ — это своя проекция информации, что не способствует ни составлению ментальной модели, ни выработке привычки). На достаточно емкой схеме разные люди могут увидеть каждый свое — то, что сейчас интересно. Короче, лучше один раз увидеть.
Второе: непосредственное взаимодействие. В графическом интерфейсе человек может двигать сами объекты, в консольном же ему нужно решить уравнение «какую переменную и как изменить, чтобы решение изменилось так, как я хочу». Он оперирует в одном пространстве, задача у него в другом, правила перевода формализвоаны в одну сторону (команда → задача), а решать нужно обратную задачу. По ощущуениям примерно как прототипировать макет сайта сразу в хтмле. Возвращаясь к бананам, я могу взять конец отрезка и перетащить его к концу другого отрезка (соединить). Я вижу, что надо сделать, и я делаю именно это.
Кому-то может показаться, что напротив, интерфейс в стиле запрос-ответ более естественнен для человека — ведь именно так мы строим диалог с людьми в жизни. Посчитайте количество действий и сравните. В гипотетической консоли я:
Рис. 2. Вывод команды
Про непосредственное взаимодействие тоже интересно. Глядя на дерево в gitk, не составляет большой проблемы разобраться в том, что сейчас происходит, даже в середине сложного мержа или какой-то еще хитрой трансформации. А вот перевести это в команды уже сложнее. Например, я понимаю, что нужно вот начиная с этого коммита все ченжсеты перенести в другую ветку. Но какой командой? На текущий момент их штук пять, все со своими особенностями, они зависят от где я нахожусь и куда хочу попасть, и обычно н делают то, что мне нужно, то есть их нужно комбинировать. Каждый раз я с трудом решаю эту загадку (shame on me, мог бы и зазубрить к моим-то годам), жутко бешусь от своего бессилия (все понимаю, а сказать не могу) и совершенно справедливо таю злобу за созданный на пустом месте квест.
Но даже если сделать команды более прямолинейными, все равно останется проблема — мне придется в одном окне смотреть на дерево репозитория и потихоньку переписывать хэши ревизий в другое. То есть, опять-таки неясно, в чем бонус.
А теперь о хорошем. Гибкость. Мощь. Пельмени. Я не глупец и не стану спорить с тем, что bash + unix utils связка мощная. Только восторги тут обычно связаны с тем, что bash — это такой REPL скриптового языка для файловой системы, который ее интерфейс удачно дополняет (см., например, как он встроен в mc или Far, и да, это не интерфейсы командной строки). Иметь в программе скриптовый язык с REPL-ом хорошо, это делает интерфейс пригодным для более сложных задач. (Эрудированный читатель знает, что и в Автокаде есть лисповая консоль, и все перечисленные страшные вещи в ней можно делать — искать объекты, двигать линии). Но в силу описанных выше причин помните, что это обмен удобства использования на гибкость, именно поэтому в cli возможны только простейшие утилиты-функции. И именно в этом суть и гениальность графического интерфейса.
Рис. 3. Командный режим Автокада.
Чтобы лучше понимать друг друга, давайте разговаривать об абстрактных апельсинах. Представьте себе Автокад, если слышали или доводилось попробовать. Можно Иллюстратор или КорелДро, что-нибудь далекое от программирования, чтобы абстрагироваться и рассуждать непредвзято. Почему они не могут работать в консоли?
Рис. 1. Абстрактный интерфейс в вакууме.
Первое: нужно иметь общую картину происходящего. Писать команду
(get-lines) и получать честный список (((0 12) (5 12)) ...) неудобно для человека. Пытаться с помощью команд понять текущую ситуацию — это обмениваться через замочную скважину записками о том, как пахнет ветер и как звучит музыка (по выразительности) и чистой воды бюрократия по методу, когда справку выдают только по правильно составленному заявлению, о своей ошибке вы узнаете только после подачи, и в будущем заявление придется писать снова и снова. А, да, чтобы узнать, какие запросы вообще можно подать, надо делать отдельный запрос. Один взгляд на общую картину может сразу все прояснить для человека, тогда как над запросами надо думать, надо интерпретировать результаты (каждый ответ — это своя проекция информации, что не способствует ни составлению ментальной модели, ни выработке привычки). На достаточно емкой схеме разные люди могут увидеть каждый свое — то, что сейчас интересно. Короче, лучше один раз увидеть.
Второе: непосредственное взаимодействие. В графическом интерфейсе человек может двигать сами объекты, в консольном же ему нужно решить уравнение «какую переменную и как изменить, чтобы решение изменилось так, как я хочу». Он оперирует в одном пространстве, задача у него в другом, правила перевода формализвоаны в одну сторону (команда → задача), а решать нужно обратную задачу. По ощущуениям примерно как прототипировать макет сайта сразу в хтмле. Возвращаясь к бананам, я могу взять конец отрезка и перетащить его к концу другого отрезка (соединить). Я вижу, что надо сделать, и я делаю именно это.
Кому-то может показаться, что напротив, интерфейс в стиле запрос-ответ более естественнен для человека — ведь именно так мы строим диалог с людьми в жизни. Посчитайте количество действий и сравните. В гипотетической консоли я:
- дожен как-то указать, какой отрезок двигать, т.е. сочинить и проверить запрос на поиск отрезка по уникальному признаку; признак тоже предстоит придумать;
- аналогично найти конец второго отрезка;
- отдать команду и передать ей результаты выполнения предыдущих команд;
- как-то удостовериться, что произошло то, что нужно, и только то, что нужно;
- убедиться, что именного этого я и хотел.
Рис. 2. Вывод команды
git log --graph --pretty=oneline --abbrev-commit. Воспроизведете по памяти?Про непосредственное взаимодействие тоже интересно. Глядя на дерево в gitk, не составляет большой проблемы разобраться в том, что сейчас происходит, даже в середине сложного мержа или какой-то еще хитрой трансформации. А вот перевести это в команды уже сложнее. Например, я понимаю, что нужно вот начиная с этого коммита все ченжсеты перенести в другую ветку. Но какой командой? На текущий момент их штук пять, все со своими особенностями, они зависят от где я нахожусь и куда хочу попасть, и обычно н делают то, что мне нужно, то есть их нужно комбинировать. Каждый раз я с трудом решаю эту загадку (shame on me, мог бы и зазубрить к моим-то годам), жутко бешусь от своего бессилия (все понимаю, а сказать не могу) и совершенно справедливо таю злобу за созданный на пустом месте квест.
Но даже если сделать команды более прямолинейными, все равно останется проблема — мне придется в одном окне смотреть на дерево репозитория и потихоньку переписывать хэши ревизий в другое. То есть, опять-таки неясно, в чем бонус.
А теперь о хорошем. Гибкость. Мощь. Пельмени. Я не глупец и не стану спорить с тем, что bash + unix utils связка мощная. Только восторги тут обычно связаны с тем, что bash — это такой REPL скриптового языка для файловой системы, который ее интерфейс удачно дополняет (см., например, как он встроен в mc или Far, и да, это не интерфейсы командной строки). Иметь в программе скриптовый язык с REPL-ом хорошо, это делает интерфейс пригодным для более сложных задач. (Эрудированный читатель знает, что и в Автокаде есть лисповая консоль, и все перечисленные страшные вещи в ней можно делать — искать объекты, двигать линии). Но в силу описанных выше причин помните, что это обмен удобства использования на гибкость, именно поэтому в cli возможны только простейшие утилиты-функции. И именно в этом суть и гениальность графического интерфейса.
Рис. 3. Командный режим Автокада.
