budden писал(а):
Меня устраивает интерпретатор уровня StdInterpreter, но он слишком многословный и не удобный для интерактивного ввода
Я разрабатывал свой язык программирования около 2 лет. До этого ещё около 6 лет об этом мечтал, собирал кусочки. Но вот эта означенная вами задача мной ещё далеко не понята. Я только лишь заметил некоторые вещи. Например, в тикле (и баше) слово без кавычек - это, обычно, строковый литерал. А в КП слово без кавычек - это, обычно, имя переменной или процедуры. Чтобы вычислить переменную в тикле, нужно приписать доллар. А чтобы написать строковый литерал в КП - нужно заключить его в кавычки. Это различие долго было не замечено мной (и я даже по инерции в тикле долго ставил ненужные там кавычки). Но оно имеет глубокий смысл, который я понял не больше квартала назад.
Оказывается, в интерактивной работе литералы встречаются чаще, чем обращения к переменным. Но даже в скрипте на bash это уже не так. Заглянешь в скрипт - а там сплошные доллары. Поэтому баш для интерактивной работы в консоли и баш для скриптов необязательно должны совпадать!
Я к тому, что задача разработки такого вот "немногословного" языка мной ещё даже на концептуальном уровне не осознана. Но я твёрдо убеждён, что bash, или уж, как минимум, практика его применения - это кака и что нужно как-то по-другому. Поэтому я совершенно осознанно отказываюсь на данном этапе от попыток разработать немногословный язык для интерактивной работы.
В лиспе есть всего один диалект. С т.з. семантики лисп одинаково хорошо подходит и для интерактивности, и для программирования (и это - своего рода чудо, и это дошло до меня только сегодня, после ознакомления с докладом Евгения). С точки зрения же синтаксиса, лисп одинаково плохо подходит как для интерактивности, так и для программирования.
Тикль - великий язык, но он слишком динамический. А с какой стати язык для скриптов должен быть динамическим? Есть такой вот шаблон поведения при разработке скриптов - написать команд одна за другой, и даже не проверять коды возврата. При этом скрипты автоматизации очень дорогостоящие, долго выполняются, тяжело отлаживаются. Эта практика категорически порочна.
Последие баш-скрипты, которые я написал, полностью состоят из строчек вида
команда || умри-баш
Но, кажется, там есть даже какой-то флажок, который делает такое поведение поведением по умолчанию - т.е. ненулевой код возврата одной команды рушит весь процесс.
Т.е. скрипт хотя бы падает, если что-то пошло не так. Но так никто обычно не пишет - вам мало попадётся скриптов, которые так написаны. В итоге, скрипт выполняется, но нужный результат не достигается, и сиди, разбирайся, почему. То, что написано на баше - это, обычно, классический говнокодинг.
Далее, баш уникален по своим возможностям. Его конвейеры позволяют строить целые системы из программ с помощью нескольких строчек кода. Ни один известный мне «обычный» ЯП такими возможностями не обладает. Чтобы сделать нормальный язык для автоматизации, нужно глубоко понять баш.
Если вы полезете в эту задачу без чёткого понимания, как надо, у вас получится скриптовый язык не лучше баша, с соответствующими кривыми практиками. Зачем он нужен? А если хотите сделать хорошо, вам нужно потратить много сил на изучение предыдущего опыта и проектирование. Я хочу хороший скриптовый язык, но у меня нет ресурсов даже на то, чтобы полностью осознать баш и тикль (хотя на тикле я написал IDE). Поэтому я ограничиваю свои цели (на данном этапе) только самым простым. А самое простое - не плодить сущностей, отложить. Пусть КП многословен, зато его не надо проектировать, он уже есть. Значит, нельзя сделать новых ошибок.
Вопрос же о гуях или их отсутствии тут второстепенен и ортогонален.