Как-то раз я написал пост о том, как проектируются компиляторы. Основная идея этого поста заключалась в очень простом композиционном примитиве – а именно, выстроить конвейер из функций. Традиционно проектирование компиляторов выстраивается как нисходящий процесс. Компилятор – большая штука, слишком большая, чтобы сразу уложить его в голове. Поэтому задачи дробятся до тех пор, пока не удастся остановиться на какой-нибудь удобоваримой подзадаче, например: написать парсер. Эта проблема уже достаточно компактная, чтобы справиться с ней в одиночку.
Сегодня же я хочу поговорить о подходе к проектированию, который, при всем сходстве с вышеописанным, устроен совершенно наоборот. Как и вышеупомянутый подход, он позволяет дробить большую задачу на более мелкие, но на сей раз все мелкие подзадачи, к которым мы подходим, уже будут решены. Поэтому сформулируем вопрос по-другому: как же спроектировать такую систему? Как при проектировании системы правильно выйти на набор мелких подзадач, каждая из которых сама по себе решена?
«Философия Unix»
Здесь я приведу лучшую, на мой взгляд, формулировку философии Unix; Википедия приписывает эту формулировку пользователю Salus:
- Пиши программы, каждая из которых делает ровно одну вещь и делает ее хорошо.
- Пиши программы так, чтобы было удобно использовать их вместе.
- Пиши программы для обработки текстовых потоков, так как это универсальный интерфейс.
Поскольку я уже анонсировал композицию, вы, пожалуй, не удивитесь, что излагаемая здесь философия целиком построена вокруг композиции. Нам нужны сподручные компоненты, единообразные механизмы для сборки программы из этих компонентов, а еще мы хотим убедиться, что можем собрать максимальное количество этих компонентов в единый механизм, где они бы нормально взаимодействовали. В принципе, эта работа похожа на сборку конструктора Lego.
Одна из причин, по которым мне нравится вот так дробить задачи – в том, что с мелкими подзадачами сложно нарваться на проблемы. Конечно, возможны вопросы о том, что такое «делать ровно одну вещь», а также можно задуматься о выборе конкретного варианта текстовых потоков в качестве универсального интерфейса, но за пределами этих частностей такая стратегия совершенно неоспорима.
Другие формулировки сильнее тяготеют к прямому руководству (также из Википедии):
Каждую программу пиши так, чтобы она хорошо делала одну вещь. Приступая к новой задаче, пиши с нуля, а не усложняй старые программы, добавляя в них новые «фичи». Рассчитывай, чтобы вывод каждой программы годился в качестве ввода для новой, еще неизвестной программы. Не засоряй вывод лишней информацией. Избегай строго колоночного или двоичного формата ввода. Не настаивай на интерактивном вводе.
Иногда эти советы могут быть рациональны, но не всегда. Сломано немало копий по поводу того, «нарушают» ли эту философию утилиты ядра GNU потому, что у них так много флагов и т. п. В конце концов, нужен ли
tar флаг для каждого из форматов сжатия? Почему бы нам не использовать отдельный разархиватор и конвейер, именно так, как явно предполагается в философии Unix?Но эта критика – в основном мимо. Да, пожалуй, было бы приятно иметь очень маленькие и простые утилиты, но, едва выйдя в публичное пространство, они превращаются в границы системы, после чего их уже нельзя менять без учета обратной совместимости. Олдскульный подход к тому, как выявить в коде ненужные фичи и удалить их, тем самым упростив все вещи, потребует отрефакторить инструментарий. Удачи вам и убедительности, когда станете убеждать коллег, что это нормально – в будущем месяце списать чей-то шелл-скрипт, который больше никогда не будет работать.
Вы реально «нарушаете» философию Unix лишь в случае, когда пишете шелл-утилиты, работающие не так, как все прочие.
Но вот чем вы рискуете, слишком увлекаясь подходом «делать всего одну вещь». Вы рискуете замкнуться в программистском восприятии проблемы «заточенном на фичи», а не рассматривать проблему как «ориентированную на решение задач», как ее видит пользователь. В самом деле, никому никогда не следует критиковать
tar zxvf за выполнение задачи, которая в большинстве случаев стоит перед каждым, обращающимся к tar: файл tar.gz нужно разархивировать. Взять наиболее типичный случай, с которым придется иметь дело пользователю, после чего не решить его проблему напрямую, а потребовать, чтобы пользователь сразу потянулся за более сложной комбинацией инструментов – в любом случае, так себе дизайн.Разумеется, было бы хорошо, если бы также не требовалось запоминать флаги вроде
zxvf.“Всё — файл”
Хотя я и думаю, что многие считают этот тезис элементом философии Unix, на самом деле формулировка “всё – файл” это отдельная идея. Вероятно, она приобрела некоторую известность, поскольку активно задействовалась при проектировании Plan 9. Философия Unix касается композиции, а область применения этой идеи более узка.
В частности, философия Unix предполагает, что утилиты должны потреблять и/или производить потоки текста. Это полезно потому, что так удается использовать больше утилит в связке друг с другом. Для того, чтобы из кусочков составлялось более крупное единство, кусочки должны быть хорошо подогнаны друг к другу.
Но идея “всё — файл” во многом этому противоречит. Она не столько о композиции, сколько о многоразовости. В данном случае суть в том, что у нас есть отдельный интерфейс с общим набором операций (открыть/закрыть/прочитать/записать), и мы можем взаимодействовать с интерфейсом на уровне этих операций. Мотивация, заложенная во «всё – файл» попросту такова: у нас есть широчайший набор утилит для операций над интерфейсом, поэтому для любой операции, влезающей в наш интерфейс, мы получаем все эти утилиты бесплатно. А важнее всего, что нам не придется изучать иной набор утилит. Можно шире применять имеющиеся у вас знания.
Философия Unix никоим образом не требует от нас брать на вооружение тезис «всё — файл». Мы вполне можем работать и с нефайловыми интерфейсами; все, что от нас при этом требуется – создавать утилиты, которые работали бы с интерфейсами конвенциональным образом. Притом, что Plan 9 может претендовать на некоторую идеологическую чистоту, поскольку эта ОС предоставляла сеть приложениям при помощи файловой системы
/net, мы с тем же успехом можем добиться под POSIX некоторых аналогичных вещей при помощи netcat. Это не столь критично для того, чтобы с пользой применять оболочку. Упс, но такого ведь не должно быть
При этом подход, при котором всё расценивается как файлы, сам не лишен недостатков. Еще в 2016 мы ввязались в одном полурегулярном опенсорсном сообществе в холивар, сводящийся к тому, что rm -rf / угробил мой компьютер. После того, как мы бросили работать с излюбленной всеми системой init, оказалось, что суть проблемы была в “efivars”, файловой системе для предоставления переменных системной прошивки. Если прошивка была с багами, то при удалении некоторых переменных систему становилось невозможно загрузить, и она оказывалась в невосстановимом виде.
Разработчик ядра, который когда-то спроектировал efivars, высказался:
В ретроспективе понятно, что она абсолютно не должна была становиться файловой системой. С переменными EFI ассоциировано очень мало метаданных, поэтому крайне удобно предоставлять эту систему так, чтобы ею можно было управлять на уровне чтения и записи. Но реальная прошивка оказалась слишком хрупкой для такого обращения, поэтому, действительно, это решение было ошибочным.
В конце концов, в ядро был добавлен обходной путь, защищающий барахлящие материнские платы от пользователей, собирающихся просто удалить несколько якобы ненужных файлов.
Да это же простейшая возможность представить дерево
Тем временем, Linux продолжает доносить информацию до пользовательского пространства при помощи
sysfs; такая практика началась после того, как procfs показал себя не вполне подходящим, чтобы дампить в него такие интерфейсы. Но это также выглядит довольно подозрительно. Главное обоснование, почему sysfs спроектирован именно так, таково: ядро должно сообщать в пользовательское пространство данные, организованные в древовидной форме.Казалось, что это естественно реализовать в виде файловой системы… объекты – это каталоги, ключи – это файлы, значения – это содержимое файлов, а массивы – это просто пронумерованные подкаталоги. Это и кажется подозрительным. Может быть, мы злоупотребляем файловой системой как таковой, чтобы представить древовидные данные, поскольку у нас нет возможности просто… передавать эти данные в виде дерева? Может быть, и так.
Это и наблюдается. На самом деле, правильно использовать
/sys напрямую достаточно сложно, поэтому мы все равно постоянно прибегаем к инструментам вроде lspci, а файловая система как таковая нас уже практически не волнует. Таким образом, зачем же беспокоиться о файловой системе? При этом, придерживаясь работы с файловой системой, вы приобретаете проблемы, если вам требуется выполнять атомарные транзакционные изменения во множестве файлов сразу. Удачи вам.Помню, однажды читал о данных, представляемых в виде файлов в
/proc или /sys, но вообще их, как правило, сложно читать и понимать. Проблема в следующем: поскольку система постоянно меняется, и поскольку сложно считывать значения сразу из многих файлов, непротиворечивого ответа вы никогда не получите. Вы можете считать одно значение, затем система изменится, и вы там же прочитаете уже другое значение. Результат получается бессмысленным: например, отрицательные значения там, где величина обязательно должна быть положительной, либо расход ресурсов свыше 100%, в таком роде. Работаем не только с текстовыми потоками
Когда Microsoft, наконец, изрядно надоело, что администрирование машин с Windows превращается в такой ужас, компания выдала блестящее решение: язык PowerShell. В нем вполне достойно воспроизведены лучшие черты философии Unix.
Определенно, у него есть и недостатки. Например, почти от всех старых программ Powershell отличается тем, что, для проведения каких-либо операций на нем сначала нужно написать специальный “cmdlet”. Соответственно, не так он и универсален, хотя, на нем все равно можно выполнять любые процессы и передавать любые аргументы командной строки.
Но с композиционной точки зрения PowerShell в основном поддерживает все тот же дизайн, что и Unix, но работает с потоками объектов, а не с потоками текста. Он дает приемлемую интероперабельность с текстовыми потоками, поскольку выполняет некоторые неявные преобразования (одно из них применяется почти всегда, с его помощью результаты отображаются в консоли).
В общем и целом, я бы назвал PowerShell грандиозным успехом. Он вынужденно замахивается на дизайн, более сложный, чем в Unix (в конце концов, ему приходится работать с уже существующими Windows API), но при этом предоставляет и дополнительные возможности, благодаря которым такая сложность приемлема. Powershell вполне приспособлен для работы с древовидными данными, пусть и в объектном преломлении.
Тем временем, философия «всё – файл» здесь и не просматривается. Поскольку все сущности являются объектами, вы освобождаетесь от необходимости иметь всего один файловый интерфейс. Напротив, теперь можно работать с объектами, реализующими почти любые интерфейсы. Такой подход более сложный, но и более мощный, и иногда стоит пойти на такой компромисс.
Есть и другие проблемы с тем, как спроектирован PowerShell, но, думаю, его можно охарактеризовать как «философия Unix: избранное и лучшее», а дополнительная сложность, присущая этому языку, нужна для обеспечения совместимости. Композиция – исключительно полезное средство при проектировании системы такого рода. Вторичная цель – обеспечить многоразовое использование. Философия «всё – файл» в рамках проектируемой нами системы нисколько не сравнится в полезности с более фундаментальной возможностью самостоятельно сформировать полезный инструментарий.
Композиция – это работа с типами
Чтобы скомпоновать определенные вещи, необходимо знать, как они стыкуются, а значит – нужно работать с типами. Начнем с того, каков тип базового элемента, например, процесса с его окружением, аргументами командной строки, stdin, stdout, stderr и кодом возврата. Процесс – это и есть базовая единица, которой мы собираемся оперировать.
Затем можно приступить к формулировке всех способов, какими можно скомпоновать такую вещь. Обычно, но не всегда, удается создать большее значение данного типа из меньших значений такого типа. Иногда хочется склеить вместе элементы разных типов.
При обращении с типичными оболочками эта работа настолько выходит за пределы работы с каналами
|, что даже голова кружится. Работая с кодами возврата, можно реализовать логику && и ||. Можно захватывать вывод в виде переменных при помощи $(cmd). Можно выполнять переадресацию в файлы или создавать временные каналы также в виде «файлов» при помощи >(cmd), так, чтобы файлы могли переадресовываться командам обратно, даже без записи на диск. И т. д.# paste принимает имена файлов в качестве аргументов
$ paste <(echo -e "a\nb\nc") <(echo -e "q\nw\ne")
a q
b w
c e
Итак, обрисовав всевозможные способы компоновки элементов, давайте попытаемся поработать с такой системой. Со временем мы соберем стандартную библиотеку из всех этих маленьких заготовок, которые всегда должны быть у нас под рукой. (Не бойтесь рефакторинга, ведь до того, как эти API превратились в границы системы, процесс постепенной доводки в стиле agile в значительной степени был определяющим на раннем этапе разработки Unix-оболочки). В конце концов, занимаясь компоновкой более крупных элементов, будем все чаще обнаруживать, что у нас уже есть готовые мелкие элементы для их сборки.
Трактуя композицию именно таким образом, в терминах компоновки операторов и тех типов, что они принимают и производят, неудивительно делать акцент на древовидных данных как на концепции, недооцененной во многих языках программирования. Почти любая композиция приводит к созданию дерева (или, как минимум, ориентированного ациклического графа, реже – просто графа). Это одна из основополагающих структур, которые мы должны быть в состоянии представлять.
В самом деле, несмотря на то, что философия Unix десятилетиями дает нам аккуратные маленькие оболочки, приспособленные для композиции, есть и мейнстримовые языки вроде Java. В них до самого 2014 года не было предусмотрено возможности компоновать мелкие операции подобным образом, пока не появились потоковые API.
Знаете, иногда я задумываюсь, а почему мы такие странные?
Комментарии (24)
victor_1212
30.09.2022 15:32+4Ув. Алексей, Вы не возьметесь объяснить, что именно Вас заинтересовало в блоге Ted Kaminski откуда сделан этот перевод?
Не хочу писать ничего критического, просто посмотрел в оригинале остальные статьи из блога, и хотел бы знать Ваше мнение.
0x131315
01.10.2022 12:37+1Пиши программы, каждая из которых делает ровно одну вещь и делает ее хорошо.
Пиши программы так, чтобы было удобно использовать их вместе.
Пиши программы для обработки текстовых потоков, так как это универсальный интерфейс.Да это же по сути основные принципы проектирования современного софта и телекоммуникаций.
Пиши функции так, чтобы каждая из них делала ровно одну вещь, и была по возможности чистой. Принцип тестируемости кода: чистый код легко тестировать, у него нет скрытых зависимостей, вызывающих неожиданное поведение и побочные эффекты. Принцип, без которого разработка быстро превращается в боль, в ежедневный нудный детектив. Принцип, призывающий максимально развязывать зависимости и жестко ограничивать сферу ответственности каждого фрагмента кода. Призывающий превратить код в набор стандартных кирпичиков, каждый из которых можно проверить отдельно, призывающий собирать софт только из проверенных надежных кирпичиков, что превращает задачу в детский конструктор. А еще независимые кирпичики можно и разрабатывать независимо, когда есть спецификация, что невероятно ускоряет разработку.
Основные протоколы связи в сети сейчас текстовые, текстовые конфиги, текстовые сообщения, логи. По большей части сейчас человечество использует текстовые протоколы, иногда со сжатием. И совсем не из соображений эффективности, а скорее из соображений ремонтопригодности: софт и так слишком сложен, сложность нужно снижать, сложность это дорого, это время, ресурсы, энергия.victor_1212
01.10.2022 21:39+2> Основные протоколы связи в сети сейчас текстовые
чтобы понимать текст надо например договориться о кодировке, это уровень 6 (presentation layer), ниже этого уровня текста нет, только поток данных (bits, bytes, frames), сетевое устройство типа switch, router вообще с кодировками пакетов дела не имеет
murkin-kot
Это основа порочности подхода. Все остальные рассуждения после такого превращаются в разговоры ни о чём.
Даже минимально полезное приложение содержит хотя бы несколько опций. А unix-way предлагает нам заставить пользователей зубрить эти опции наизусть. Это абсолютно нереалистично. Ну и потому unix-way как-то живёт лишь среди старых админов, которым с детства нравилось играть в игры-бродилки, где нужно запоминать секретные ключи. Всем остальным этот unix-way - просто кость в горло.
Для сравнения - в GUI интерфейсе пользователь сразу видит все опции. От него требуется лишь ткнуть на какую-нибудь. Нет задачи запоминать всё и всегда. Нет нужды читать мануалы каждый раз. Нет нужды искать в мануалах запрятанный сотым пунктом важный переключатель. Нет нужды листать сотню страниц, потому что GUI легко позволяет показывать информацию в виде дерева (или вообще в картинках).
Философия Unix мертва. Это станет окончательно очевидно после ухода бородатых админов и замены их на простую поисковую систему, способную по ключевым словам найти тот заветный переключатель, что обычно в мануалах unix располагают на сотой странице.
Вообще, идея "помнить ключи" - бесчеловечная. Человек должен помнить принципы, а помнить ключи - задача справочника. С этим справлялись даже бумажные изделия. Но философия unix по прежнему настаивает на старом и убивающем человека принципе.
Конкуренция на поле администрирования давно показала - нужны люди, понимающие принципы, а помнящие ключи админы постепенно вытесняются на обочину.
13werwolf13
чушь, например в моём shell если написать tar и тыкнуть кнопку tab то так же прочитаешь все "опции" и выберешь нужные стрелочками и enter
так что претензия ваша не к философии в целом а к её некоторым реализациям. да, чтобы получить такой ux мне пришлось поправить один конфиг, сложнаааа, но юзверю это не обязательно, он может получить тот же результат так же тыкнув одну кнопку. философия не мертва, просто люди деградировали и разучились даже читать. не далее чем пару дней назад прочитал в одном чате "линукс ужасен, чтобы прочитать документацию нужно вспомнить как называется утилита для чтения мануалов а потом ещё и воспользоваться переводчиком" - не кажется ли вам что это претензия из разряда "мерседес ужасен, чтобы открыть дверь нужно взяться за ручку"?
a3or
Извинете, но ваша аналогия с ручкой у авто ужасна. Уж лучше сравнить КПП авто. На механике ездять в основном те, кто с ней может управиться адекватно, на автомате же ездят все остальные. МКПП не умрет, пока есть те, кто знает как им пользоваться, остальные 90% выберут АКПП.
Murtagy
Зачем ездить на механике, когда есть АКПП? При желании воткнул в ручное управление и тормози двигателем. Если вы не участвуете в ралли, то вероятнее всего механика это избыточный контроль, который в 99% ежедневных ситуаций не нужен.
13werwolf13
мкпп лучше как минимум в плане финансов:
1) обслужить намного проще
2) обсуживать надо намного реже
3) обслуживать тупо дешевле
4) сломать сложнее
5) меньше способов сломать
это конечно "в среднем по палате" и верно не для всех 100% акпп и мкпп, но общая картина такова.
кроме того ИМХО мкпп просто удобнее а главное с куда меньшим шансом подведёт в неподходящий момент
Murtagy
Будем честны - большинство не обслуживает узлы самостоятельно. Замена масла раз в 60 тыс я бы не назвал прям сложным обслуживанием. Насчет сложнее сломать - я бы поспорил, что механику сломать проще, т.к. больше шанс выбора несоответствующей передачи.
13werwolf13
1) большинство - уже плохой аргумент
2) кому как, у меня 60к это всего за год
3) ну так не выбирайте несоответствующую, делов то
Murtagy
1) Почему же? Большинство ходит в обуви вместо того чтобы ходить босиком. Так ли оно не право?
2) Это 164 км в день, похоже на такси. Думаю у вас все же межгород режим. Возьмем фуры как ультимативный пример - большинство современных тягачей на АКПП
3) Автоматизация двигатель прогресса, нравится вам это или нет
13werwolf13
1) плохой пример, большинство выбирает windows хотя никто не спорит что это самая убогая ОС - как вам такой пример?
2) каждый день около 12 км по трассе и около 10 по городу (умножаем на два ибо в обе стороны) это дорога на/с работы, ну и просто вечером покататься, в магазин сгонять раз в неделю, просто выехать на природу покурить в тишине леса или у озера. а иногда просто от бессонницы по ночным дорогам нарезать соточку. я очень люблю ездить за рулём.
3) нравится, просто пока что все варианты автоматизировать кпп мне не подходят, разве что DSG при первой попытке понравилась, и то нашёл до чего докопаться, да и нет ни одного авто с DSG которое бы мне понравилось так как мой хоть и старенький но ещё радующий душу форестер
Murtagy
Когда легко можно привести контр пример - это означает что тезис слишком общий.
Windows конечно не идеальная ОС, но она объективно хороша по многим параметрам. Не буду аппелировать к своему опыту, но например J Blow, доволен Windows куда больше чем Linux, хотя обе системы плохи в части GUI.
Если вы, например, адепт С++, и не понимаете почему индустрия влюблена в Python - возможно это вы не понимаете чего-то. ( Например J Carmack активно использует Python в работе)
Опять таки, я не утверждаю что C++ чем либо хуже. Но вероятнее всего для обычной работы вроде автоматизации какого-нибудь простого процесса, либо вебсайта - маловероятно что C++ более удачный инструмент.
То же самое и для АКПП. Возможно часть людей и выигрывает больше от механики, но значительному большинству ездить на АКПП безопаснее, проще и эффективнее.
... При желании всегда можно воткнуть коробку в manual
13werwolf13
совершенно не то же самое
13werwolf13
аналогия с кпп в авто ещё хуже, ведь и там и там надо браться рукой за рычаг, а значит комментатор выше будет одинаково недоволен
kma21
Никто не заставляет зубрить опции. Есть хелпы, маны, автодополнения. Вы же не говорите, что Microsoft заставляет зубрить кнопки в MSO? Что Adobe заставляет зубрить кнопки в Photoshop?
Поэтому есть всякие API, IaS и прочие, потому что кнопки удобнее?
И GUI программы с большим количеством функций превращается в приборную панель b-52, где на каждую функцию кнопка. Безумно удобно, правда?
Нет, вам приходится делать бесконечное множество древовидных меню. Где найти какую-то конкретную опцию огромная проблема (привет изменение формата листа в MSO 2003 и прочих libreoffice). В самолётах тоже, кстати, переходят на "стеклянные" кабины, т.к. это удобнее. И вы не можете посмотреть все дерево опций и поиском по странице найти что-то.
Философия ни начём не настаивает. Она есть и всё. Ей могут следовать, могут не следовать. И она не может меняться под влиянием времени. Если что-то меняется, то это уже другая философия, не та, что была.
Как можно сравнивать понимание принципов и знание опций программ? Если быть таким же строгим, то понимающий принципы, но не знающий опций сможет использовать программы? Вы знаете как работает сеть, вы знаете как работает сетевой стек в unix-like системах. Вы сможете настроить сеть с ходу, без изучения опций программ в каком-нибудь netbsd? Но вы же понимаете принципы.
Или наверное не понимающий принципы, но знающий "ключи" сможет настроить сеть в windows с кнопками?
Никогда этот радикализм не доводил ни до чего хорошего. Для каждой задачи свои инструменты.
vassabi
сначала, я даже немного удивился, думал что-то написать в ответ, возразить.
но, потом дочитал до
и понял, что это такой тонкий сарказм, и просто забыт смайлик в конце :)
PS: эх, а ведь когда-то люди были энциклопедистами... но увы - со увеличением специализации - уже не получалось вообще всё охватить. Конечно, тогда хотя бы считалось нормальным знать всё в своей области деятельности. Время шло - и настало так, что стало сложно все знать и в своей области деятельности. ОК, если не знаешь всего в своей области работы, знаешь только узкую часть, то было принято хотя бы не гордиться этим.
Увы, ничто не вечно - мы наконец-то дошли до "ученых-поисковиков" Лема (т.е. "ученые", которые ничего не исследуют и занимаются только поисковыми запросами в уже существующие знания), которые гордятся тем, что ничего знать не нужно - "вы дурачки, а мне - поисковик все найдет" :)
murkin-kot
Энциклопедисты не запоминали ключи от тысячи утилит unix.
Энциклопедист, это человек, умеющий применять широкие знания. А запоминанием орфографического словаря перед энциклопедистом хвастаться не получится.
murkin-kot
Из чего вы сделали такой вывод? Вас вогнало во грех впечатление от серенького цвета моего комментария? Это самый сильнодействующий аргумент?
По хорошему, вам бы извиниться. Ну и перечитать мой комментарий.
sim31r
Напоминает "мнение" Шерлока Холмса по поводу узкой специализации.
SteelRat
В данном случае речь не про пользовательский интерфейс. А про интерфейс обмена данными. Но даже если говорить про пользовательский интерфейс - командная строка удобнее, быстрее и эффективнее любого GUI. По мне так бесчеловечно заставлять пользователя возюкать полчаса мышкой, чтобы сделать то, что в командной строке можно сделать за 5 секунд.
Очевидно, что есть области где GUI удобнее, типа того же веба, игр. Тут спору нет.
Staschik
Утрируя, 10 лет назад я писал tar zxvf и сегодня я так же пишу. GUI могут также?
Newbilius
В проводнике windows 95 я перетаскивал файлы из одной папки в другую и вызывал контекстное меню для вырезания или копирования по правой кнопке мышки. В windows 10 ничего не изменилось. Так что да, могут :)