Здравствуйте, raskin, Вы писали:

R>Тема начиналась с того, что объявлялось, что shell скрипты никогда не
R>удобнее программы на C#. Мне предлагали ставить mono на GNU/Linux, а он
R>больше по размеру.

Насколько я помню исходно ставлися тезис что шел-скрипт — это ДСЛ который чем-то лучше чем универсальный язык. Вместо доказательства этой позиции тема сошла в демогагическое обсуждение того, то наличие готовых утилит оправдывает убогость ЯП и его среды.

R>Да, действительно, нормальный matching там есть. Хотя необходимость
R>что-то подключать для кода короче десяти строк — минус, хотя и мелкий.

Для скриптов можно специально по умолчанию открыть пару пространств имен, чтобы не дублировать код. К тому же визарды никто не отменял. Достаточно создать проект "скрипта" и одни нажатием мы получим нужное окружение.

>> По-моему, даже применение Явы для этого уже дало бы множество
R>Какие?

Полноценный язык который (компилируемый, что немаловажно), возможность использования отличной IDE, отладчика, моря библиотек, качественной документации.

R> Что я получу взамен case,

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

R>for,

for в Яве 1.5 расширен до возможностей foeeach C#-а.

R> предельно краткого синтаксиса

Предельно экзотического и извращенного. Причем разного вразных вариантах.

R>вызова функций

вызов функций Причем полноценный, рекурсивный и быстрый.

R>и краткого синтаксиса перенаправления потоков данных?

Полноценным языкам не требуются подпорки вроде пайпов. Они и так повзовляют передавать результаты одной функции другой. Для этого придумана куча мехонизмов. В том числе потоки ввода вывода и итераторы.

R> Я успею этим воспользоваться в экране кода? На Яве столько обвязка для
R>Hello world занимает..

Для целей скрипта можно сделать простенький снипет-компилятор который уберет эту "обвязку". Плюс опять же с ней нет проблем если ты пользуешся IDE.

>> приемуществ. Соорудить набор соотвесвующих библиотек и удобные средства
>> запуска. Остальное уже есть. Конечно более мощьный язык вроде Немерла
R>На экране кода синтаксис стоит тоже немало.

Синтаксис шелов ужесен. Что на экране, что на 20. Причем скрипты в 20 экранов очень даже встречаются.

R>Полноценная IDE не нужна для скриптов короче экрана — ей просто некогда
R>воспользоваться на таком малом объёме.

Она нужна для любого объема код. От одного вызова, до проекта на 1000 файлов.
Это и удобство для опытных пользователей, и простота вхождения для новичков.

R>Основание — shell имеет сочетание свойств, выгодное для его роли.

И как мы выяснили все они упираются в греп и еще пару утилит к шел-у по большому счету отношения не имеющих.

R> Вызов
R>функций — просто с аргументами через пробел. С учётом специфики -
R>удобно.

Не сказал бы. Это твоя привычка. Мне как программисту всю жизнь использовавшему С- и Паскале-подобные языки (а до этого учившегося в школе математике) понятнее и привычнее синтаксис со скобками и запятыми.

R> Далее имеем такую вещь, как флаги вида -<буква>

И чем это отличается от перечислений передающихся в параметры? Хотя отличие есть. В параметрах задолбашся разбираться (пока их не зазубришь), а перечисления как раз будут отлично понятны без пояснений. Да и пояснения для них получить будет раз плюнуть (помним про Интеллисенс).

R>. С выдачей списка по <tab>-<tab> при наборе.

Он отдыхает по сравнению с полноценным комплитом и хинтами. Расширить комплит для подсказки каталогов на текущей машине и стандартных каталогов и будет вообще улет.

R> Как их передавать — как строки?

Зависит от задачи.

R> Подозрительная похожесть решения проблемы флагов в shell и Lisp наводит на мысли, что сделать лучше можно, но весьма сложно.

А не наводит на мысль то что Лисп уже 45 лет на задворках? Может ну его на такое удобство?

R>Я пробовал использовать как shell что-нибудь помощнее. Но многословность
R>в тривиальных случаях быстро добивает.

Это только говорит о тебе. Вместо того чтобы создать библиотеки ты все добил в коде скрипта.

R> А shell-скрипт — это как раз не больше экрана кода, из которого обвязку выкинули как класс и при этом в большинстве строк по несколько вызовов вложенных вызовов функций.

В коде любого языка все коротго если код вызвает гтовые выскоуровневые библиотеки. В ранних версиях Юникс и ДОС-е выбор утилит и кривых скриптовых языков было обяснимо. В те времена компонентных технологий еще попросту не существовало. Но почему в современных ОС дела обстоят не сильно лучше лично я понять не могу. Это банальная костность мышления.