Проще говоря, стиль Unix - это набор инструментов для составления небольших единиц для формирования сложных операций. В этом смысле это очень похоже на функциональное программирование, но живет в приложениях, а не в теории. Две операции, наиболее примечательные из этой эпохи, - это конфигурация и объединение операторов.
Возьмем, к примеру, программу для поиска исходных файлов, в которых есть табуляция вместо пробелов.
find . -name test.py -print -exec cat {} \; | egrep './|\t'
Эта конструкция в основном излишняя, но дело в том, что у разработчика есть много возможностей как для настройки существующих операторов, так и для добавления новых операторов по мере необходимости. В одной строке здесь есть поиск по каталогу, подстановка аргументов, объединение функций и поиск по регулярному выражению. Такой код обычно занимает ~ 10-строчную программу. Что может звучать не так уж плохо, но если учесть тысячи таких коротких программ, которые пользователь Unix может написать за один день, работать с оболочкой становится намного приятнее.
Функциональный стиль, с другой стороны, имеет гораздо больше возможностей компоновки, но полностью лишен части конфигурации (вплоть до того, что все именованные операторы допускают только одно узкое значение). Современные среды обычно имеют доступ к набору инструментов Unix, но предпочитают не использовать его. Почему это?
Первая причина не использовать Unix в приложениях - это безопасность. Управление терминалом обычно настолько мощно, что любое приложение, вызывающее вызовы exec на любом уровне, считается дурным тоном. Unix предназначен для системных администраторов, а не для веб-приложений.
Во-вторых, Unix требует большого обучения. Все команды и параметры неясны и часто противоречат интуиции. Если у операторов есть одна общая черта, то это просто ответ на прочтение страницы руководства.
И, наконец, в-третьих, Unix не очень компонуем. Unix разрешает только текст для композиции текста. Из-за этого намеренного ограничения сложные структуры данных должны быть сокращены до JSON и т. Д., Иначе они могут погрязнуть в логике приложения. Есть причина, по которой приложения превращаются в монолиты, и обычно не по «соображениям производительности».
Итак, каков путь вперед?
Что ж, во-первых, давайте придерживаться предыдущего стандарта. Давайте сделаем лучше sh. Как бы это выглядело с учетом сегодняшней точки зрения?
Если стиль Unix - это не путь вперед, то что же тогда? Если мы посмотрим на академическую теорию, мы можем попробовать функциональную. Как насчет Haskell или ML?
Так как я немного больше знаком с веткой машинного обучения, давайте попробуем это. OCaml включает REPL, поэтому, если вы хотите продолжить, начните с установки и запуска ocaml в оболочке.
Типы данных? чек.
# type 'a btree = BTree of 'a btree * 'a * 'a btree | Empty;; type 'a btree = BTree of 'a btree * 'a * 'a btree | Empty # BTree(Empty,1,Empty);; - : int btree = BTree (Empty, 1, Empty)
Оператор трубы? чек.
# let ( |> ) x f = f x;;
val ( |> ) : 'a -> ('a -> 'b) -> 'b = <fun>
# let f x = x+1;;
val f : int -> int = <fun>
# let g x = x+1;;
val g : int -> int = <fun>
# f 1 |> g;;
- : int = 3
Производительность и безопасность? Сравнительно проверить и проверить.
Итак, мы остановились на двух вещах, которых нам не хватает: настраиваемости и встроенных функциях.
Для встроенных команд в Haskell есть библиотека Turtle, которая хорошо портирует как можно больше стандартных операторов оболочки. Я не знаю аналогичного проекта в OCaml. Результат немного неудобен и, вероятно, не является улучшением по сравнению со старыми оболочками.
Что касается конфигурируемости, то ни один из включений не очень хорош с параметризацией операторов. Haskell не допускает для этого такого краткого синтаксиса, которого я ожидал бы от оболочки. Хотя OCaml поддерживает дополнительные параметры функций, перспективы не намного лучше. Если бы мы собирались в полной мере воспользоваться преимуществом типов данных, нам понадобилось бы что-то вроде специального полиморфизма. Эта функция, хотя обычно считается полезной, не пользуется широкой поддержкой в функциональном сообществе из-за несовместимости с тем, как выполняется вывод типов.
Взятые вместе, я оптимистично смотрю на то, что философия Unix выживет и перенесет свой стиль в современный язык и использование оболочки. Однако какое-то время не стоит ожидать, что вы выбросите весь код, уцелевший за последние 40 лет. Хорошие идеи упорно отбрасывают.
Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.
Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!
