Контексты и умолчания

[vitus_wagner]

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

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

Почему-то все попытки "улучшить" shell вели в строго противоположном направлении "давайте напихаем туда более низкоуровневых конструкций, массивов, объектов с методами, типизации". Да, эти конструкции, которые вполне себе высокоуровневы если смотреть с уровня ассемблера, даже портабельного, на уровне шелла - глубокие потроха, которые не надо выворачивать наружу.

Подумав, я пришел к выводу что

1. На этом уровне как часть языка нужно рассматривать не только команды и аргументы, но и форматы потоков, которыми эти команды обмениваются.

2. Должна быть некая система умолчаний. Сейчас в шелле контекст выполнения состоит пожалуй, из имени текущей директории (и. соответственно относительных путей). Ну с некоторой натяжкой - еще и списка фоновых задач из него запущенных - %1 меняет свое значение по ходу выполнения.

В более низкоуровневых языках программирования, которые являются аналогом письменной речи, система контекстов куда более развита. Начиная с let в Lisp-е и with в Pascal, и кончая развесистыми системами алиасов при импорте модулей в Python и Go. Где-то в промежутке namespaces в C++ и присваивание glob references в Perl. В общем придумано много способов сказать "сегодня это слово у нас значит то-то". Но это именно способы, характерные для письменной речи, причем даже скорее для научных и юридических текстов, а не для художественных и не для частной переписки.

А шелл это именно аналог устной речи. В естественных языках умолчаний и контекстной зависимости в устной речи гораздо больше чем в письменной. А вот в интерактивном взаимодействии человека с программой или программ между собой (опять же - шелловская сессия это не диалог человека с компьютером. Это целая тусовка - человек, шелл и куча программ, и они все общаются между собой в разных сочетаниях).

(три дня эту мысль думал, а все равно непричесанная какая-то. Или я поторопился и надо было еще сутки подумать?)

Comments

…а вот в PowerShell…

[8df887a0-b2d1-4ca4-8758-9799a5a7bad1 [openid.stackexchange.com]]

При всём отталкиващем синтаксисе Windows PowerShell, лёгкая интерпретация форматированных потоков как объектов и наоборот, это то, что там есть, а в Unix'овых шеллах — нет.

Вот пример. (https://books.google.ru/books?id=78w1953mptUC&lpg=PA197&ots=z0wBoJ-4UK&dq=powershell%20Convert-TextObject&hl=ru&pg=PA197#v=onepage&q&f=false)

Re: …а вот в PowerShell…

[vitus_wagner]

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

Re: …а вот в PowerShell…

[filin]

Понять бы тогда, каков мог бы быть шаг в правильную сторону...

В юниксе, как только у тебя поток так или иначе форматированный, синтаксис сразу становится на порядок страшнее, чем у PowerShell, потому что формат приходится не только использовать, но еще и парсить.

UPD. Хуже. Не как только форматированный, а как только структурированный. Хоть как-то.

Re: …а вот в PowerShell…

[vitus_wagner]

Давай развлечемся и xmlstarlet перепишем чтобы удобный был. (и на SAX с DOM пересадим заодно для пущей потоковости).
Чтобы был образец как правильно работать со структурированным потоком.

[yurikhan]

Вот with в Паскале был иногда штукой исключительно вредной. Того же уровня вредности, что и широкодействующий using namespace x в плюсах или from x import * в Питоне.

type Foo = record {…} end;
var
    foo: Foo;
    bar: Integer;
begin
    bar = plugh(quux);
    with foo do
    begin
        {…}
        baz = bar;
        {…}
    end
end;

В один прекрасный день в Foo появляется поле bar, и код внезапно и незаметно начинает работать неправильно. Плавали. Знаем.

[vitus_wagner]

Когда речь идет об интерактивном взаимодействии, а не о программе, которая должна пережить восемь апгрейдов, эта проблема менее актуальна.

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

Кстати с from x import * ситуация несколько лучше, чем в приведенном примере на паскале - ведь импортированные из модуля переменные будут "гражданами второго сорта" и локальные переменные будут их перекрывать.

Но вообще задача комбинирования нескольких контекстов она действительно нетривиальна и ее надо думать.
Она очень мощна, и, как и любая мощная конструкция опасна.

Приведу еще такой пример - я в windows обычно c:\mingw64\usr\bin пишут в конец path. Чтобы мингв-шные утилиты не перекрывали родные виндовые, пришедшие в комлекте git или еще откуда взявшися (perl и python считаем "родными виндовыми). И вот теперь мне понадобилось что-то, что я в unix привык делать с помощью find,,,

[yurikhan]

Ну, тот пример был из боевого применения Паскаля. Object Pascal, aka Delphi, двумя местами работы тому назад. И, кажется, оба юнита — и поменянный, и сломавшийся — были «наши». Для поломки достаточно было, чтобы их поддерживали разные люди. (Кстати, в контексте этой проблемы, я-который-здесь-и-сейчас и я-три-месяца-назад — разные люди.)

from x import * перекрывается локальными переменными, но может перекрывать from y import *.

[avnik]

Вообще то для компилируемого языка логично сказать "name clashing, нихачу компилировать".

Ну либо глядя на RecordWildcards в хаскеле -- смотреть что больше по типу подходит ;)

[anonim_legion]

В том языке, где это нормально реализовано - то есть в Ada, после появления поля bar код просто перестанет компилироваться.

[dzz]

Контекст исполнения в unix shell определяется переменными среды.

[vitus_wagner]

Задумка такая была. На практике этоим осмысленно пользоваться разве что в мейкфайлах можно.

[dzz]

> разве что в мейкфайлах можно.

Ну вот неправда. Совмещение нескольких инстансов оракловых продуктов (будь то БД, веблоджик, паблишер или ещё какая фигня из стека) на одном сервере только за счёт этого механизма и работает нормально. Не говоря уже о влиянии LD_LIBRARY_PATH на выбор правильных библиотек ld. Локаль, опять же, юниксовая, таймзоны...

[vitus_wagner]

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

[slobin]

Ну так эти языки придумывались для написания шелл-скриптов. То есть того, что машина будет делать завтра, когда контекст уже потерян. А то и вовсе в другом месте. А замена шелла для "здесь и сейчас" -- это гуй. Ну, в моём случае туй типа нортона, но это, возможно, неважно. "Мне, пожалуйста, вот это вот сюда". (Обрати внимание, что объект и локацию я назвал хотя бы указательными местоимениями, а действие вообще никак не назвал... и ничего, сошло). И вот юниксячья идея, что сценарии можно записывать и повторять завтра -- она реально сложная, именно из-за этого противоречия (насколько контекст ещё цел?).

... А на это господин дракон велел сказать: посмотрим! ...

[allter]

Кстати, что мне нравится в использовании Far/Midnight Commander такого, чего нет в Total и прочих GUI файловых менеджерах, так это то, что из текстового интерфейса можно без дополнительных телодвижений скопировать любой компонент интерфейса - имя файла, каталог, список файлов. А если не хватит интерфейса файлового менеджера, то можно запустить любую нужную команду.

[vitus_wagner]

Эта идея была в свое время доведена до логического конца у Вирта в Оберон-системе. Там если где-то на экране написано было имя команды, по нему можно было кликнуть средней кнопкой и выполнить.

[livelight]

Если бы Обероном люди пользовались, то эту фичу прокляли и забанили бы первой. Примерно как автоматическое скачивание с автоматическим запуском левого файлА.
Впрочем, виндузятники по дефолту до сих пор скрывают расширения файлов, что очень удобно для всяческих троянов: скайчай себе файл новый-модный-фильм.avi.exe, спрячь расширение и запусти то, что видишь, он покажет тебе кино (про трахающихся негров, отключаемое только платной СМС-кой)

[shadowfoto]

ну кстати в некотроых ММО-играх, в которых можно скриптовать/переписывать куски морды клиента - eval() или выпилен нахрен, или требует явного включения неявными способами. по тем самым причинам, да.

[dzz]

Оберон - вообще очень идеалистический проект. Как писал Дейсктра (правда, гораздо раньше и совсем по другому поводу ;) - "техника будущего для технологии программирования прошлого".

[slobin]

Да, и это тоже.

... Невнимательный маньяк ...

[livelight]

А ещё команда clip в FAR-овском хозяйстве очень полезна.
Долго страдал от её отсутствия, потом догадался погуглить :)

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

[vitus_wagner]

На самом деле в гуе вместе с возможностью "повторить завтра" выплеснули и возможность "повторить здесь и сейчас для всепх элементов этого списка".

[slobin]

Ну у юниксологов до сих пор collective rename -- это отдельная фича, за которую деньги берут.

... Векторы прерываний были завязаны узлом ...

[vitus_wagner]

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

[stiv_sigmal]

Не знаю, не помню, как у прочих гуевых шеллов, а у того же FAR Manager есть «применить команду [к текущему элементу либо выделенным, которые в том числе могут быть на временной панели]». Плюс есть макросы на LUA. Конечно, это получается не чистый гуй или чистый шелл, а что-то среднее.

[livelight]

> а действие вообще никак не назвал...

А вот это зря! Copy, move и link - существенно разные действия, и путать их череповато.

[vitus_wagner]

Кстати в двухпанальных файловых менеджерах не назвать действие по-моему нельзя. Там Copy, Move и Link на разнык хлавишах.

Вот в драг-н-дроповых - это да. С этим есть проблема.

[livelight]

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

[filin]

Мне казалось, что его логика документирована. В пределах одного диска он выбирает move, на другой - copy.

[livelight]

Оно, вроде, и документировано, но в реальной практике получается, что мне пногда надо одно, иногда другое, иногда третье, а система по дефолту тоже предлагает иногда одно, иногда другое (вроде, третье тоже иногда), так что проще и безопаснее заранее предполагать, что она не угадает, и тщательно проконтролировать.

[livelight]

В шелле как раз контекст такой огромный, что лучше бы обкромсать на порядок.
Во-первых, это environment variables -- те самые, которые со словом export в баше. Но их количество обычно обозримо, так что жить можно.
Во-вторых, кроме экспортов, в шелле есть не экспортируемые в запускаемые программы переменные. Шелловские скрипты огребают от них по полной, потому что они видны всему скрипту, включая sourcing, а local внутри функций мало кто пишет.
Ну и по мелочам: cwd (не все используют pushd/popd), %1, !! и т.д.

[filin]

Вот с контекста-то и начинается веселье. У меня есть документированый баг: я практически всегда рассматриваю больше вариантов состояния контекста, чем собеседник. Собеседник обычно обижается, что я не понимаю, какой из них он имел в виду — с его кочки зрения вариант там один.

У машины с этим еще на порядок хуже.

[nureddin]

>То есть меня в общем довольно давно волновал вопрос, почему за 40 лет не появилось языка программирования, который был бы shell лучше чем unix shell. То есть более высокоуровневый, с меньшим порогом вхождения. позволяющий легко формулировать сложные концепции.

А как же Rexx ?

[ramendik]

Для меня шелл был и остаётся очень сильно слишком write only. На шаг лучше регекспов (которые write only до полной, с моей т.з., неприменимости).

[livelight]

А перл - это на шаг хуже, чем регэкспы :)

[filin]

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

[ramendik]

Насколько я понимаю, написать читабельно на перле можно, но надо очень стараться. А регэксп просто нельзя написать читаемо. Шелл зачастую тоже, из-за количества эскейпов.

Мне больше нравится, конечно, питон. Там надо специально стараться, чтобы писать НЕчитаемо.

[vitus_wagner]

Читабельную программу на Перле написать легче, чем переносимую на C.

[ramendik]

Это да. Ну не может Си без так-её-тудыть арифметики пойнтеров.

Хочу ОС с микроядром, где само микроядро и системные сервисы написаны на Паскале или другом строго типизированном языке без арифметики пойнтеров. Недадуд, однако. Разве что DZ OS :)