Когда всё - строка, мы можем использовать банальные grep / sed.

В любом случае, без опыта работы в этом shell на протяжении хотя бы недели, это всё размахивание руками.

И они не предлагают ничего альтернативного? Там прямо в примерах есть where, по виду куда более интеллектуальный. И это как раз подтверждает изначальный тезис - классная идея не приживается, потому что люди не хотят отказываться от привычного (в данном случае набора sed/grep)

Я не топлю за этот конкретный проект и кроме написанного в readme ничего про него не знаю :) просто он очень хорошо иллюстрировал мысль, а дальше нить разговора ушла в несущественную конкретику

При работе в интерактивной оболочке не нужна строгость. Как правило, достаточно совершенно нечётких решений.

Во! Вот тут начинается интересное.

Почему не нужна?

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

Я бы сказал, что gradual typing в данном контексте гораздо лучше как полностью строгой, так и полностью динамической систем

Пример:

1. Есть JSON, в котором закодирована некоторая развесистая структура с числами внутри. Структура без схемы по историческим обстоятельствам (генерируется кодом, код иногда меняется).
2. Мне надо узнать, принимает ли там некое поле определённое значение.

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

То есть, выдирая суть - у собеседника с компьютером есть знание контекста, которое позволяет обойтись без связывания по рукам и ногам.

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

————————————-
Спасибо за вопрос.

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

Он не проще, он гибче.

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

После фразы "связывание по рукам и ногам" я вижу, что тут где-то недопонимание :)

Ну допустим есть json и нужно найти в нем конкретное значение. Для json'а есть парсер. Парсеру можно скормить путь и значение получить. То есть, было бы что-то наподобие

load-json "foo.json" | get foo.bar.myprop

и вот значение

Если структура джейсона неизвестна и foo.bar.myprop так сходу не напишешь - наверняка сначала в исследовательских целях можно сделать обычный cat > grep, но потом это один раз зафиксировать

И в данном примере я по-прежнему не вижу ничего, что бы "сковывало" действия

кстати на линуксе для парсинга JSON есть стандартная утилита jq. Она в отличии от грепа понимает структуру и по этому пользоваться ей удобнее для JSONa

Это просто напрасная трата времени - разбор этого несчастного дерева.

например можно выводить в консоле график пятисоток из графита)

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

как ситуацию с обработкой json можно улучшить?