Re: window managers
On Tuesday 07 August 2012 16:48:26 Artem Chuprina wrote:
> Похоже, мы друг друга не понимаем на уровне "в стиле Unix"
Бинарные компоненты, написанные профессионалами, объединяются в скрипт
потенциально любой сложности посредством простого для освоения пользователем
языка через парсер текстового/ых протокола/ов, с возможностью построения
логики работы с интерфейсом к этому скрипту, а также обработки ввода-вывода.
То есть я не оригинален. Так тот же Реймонд пишет.
> и "RAD".
Программа, позволяющая писать программы быстрее, чем это делается посредством
IDE, и требующая при этом более низкой квалификации. Программа, не язык.
Это - краткий пересказ википедии.
> По
> моим представлениям, RAD, в качестве примера средства для которого
> приводится bash - это скриптование для решения какой-то довольно узкой
> задачи. Но действительно быстро, день-два, в сложном случае неделя.
Bash в своё время был RAD. Сейчас можно ещё быстрее.
> То есть прототип на 2-3 экрана кода. Какие тут нафиг IDE, специальные
> средства поддержки рефакторинга и ты пы? Что с ними делать об эти 2-3
> экрана?
А что полезного можно написать в 2-3 экранах кода? Одна формочка без обработки
столько займёт, да и что-то типа VisualTcl в такой объём точно не впишется.
> Какие богатые библиотеки? За день-два для тысячи библиотек
> даже описания не прочесть. Нужно три-четыре библиотеки, только вот
> ровно нужные. Остальной CPAN для этих задач не нужен, он нужен для
> других.
А для консольных программ документация короткая, да? man sed, grep и awk - это
уже три тысячи страниц, справочника, между прочим. Это без синтаксиса
регекспов и отладки, без которых новичок этим пользоваться не сможет. Это без
редактора, языка для него и разных режимов. Это без основ Unix и bash. И, уж,
тем более, без документации тех программ, которые, собственно, и несут в себе
всю необходимую внешнюю функциональность.
Вы наверняка знаете, какой из этого следует выход. И для библиотек он тоже
годится.
Вон, задача в начале ветки стояла - в стиле Unix way пользователем добавить к
программе возможность сохранения сессии средствами RAD через libSM. Если вы
подобные зависимости в 3-4 библиотеки добавите, они, библиотеки, станут
неподъёмными.
> Ну, да. Но стоит помнить, что для асинхронной работы с файлами, пайпами
> и сокетами в перле потребуется подтянуть пять-десять библиотек. В tcl -
> ни одной. Он в этом смысле гораздо ближе к bash.
Это всё здорово, пока не потребуется, скажем, udp, ftp и прочее. А потом с
прочитанными данными что-то делать надо: парсить их, просматривать,
редактировать...
> Браузер у него уже есть, им только управлять нужно. Для этого гуй,
> прямо скажем, вообще не нужен, а Tk нужен только для того, чтобы
> выяснить, куда послать команду. У меня были такие инструменты к fvwm, а
> Витус, полагаю, до сих пор такими пользуется. Написано на tcl/tk,
> именно что.
Управления мало. Вон, задача с сохранением сессии была. Её разве можно решить
внешними средствами, не залезая в нутро программы?
А на инструменты ваши, конечно, интересно посмотреть. Заодно всплывает
проблема наличия русского сообщества RAD. С сайтом и поддержкой.
> То есть? Консольную (т.е. такую, которой нужен терминал) я запущу
> посредством xterm -e. А команднострочные, конечно, запускаю, зачем на
> tcl делать то, для чего утилита уже написана? UNIX way, однако.
А дальше возникает проблема парсинга вывода. Синтаксис которого может быть не
описан в документации, не предназначен для разбора регекспами или и вовсе
быть естественным языком.
Что делать с программой только с псевдографическим интерфейсом, я не знаю.
Unix-way, да. Современный подход.
Если бы консольная/команднострочная программа была бы библиотекой, парсить
текст бы не пришлось.
> Q> Ну и да. В чём писать программы на Tcl/Tk? Подсветка
> Q> синтаксиса/семантики, контекстно-зависимое автодополнение, отладка,
> Q> контекстно-зависимые подсказки, рефакторинг, навигация, whatever +
> Q> автоматизированная часть, позволяющая временно объединять компоненты
> Q> соплями, как это делает VisualTcl. Разумеется, среда должна быть на
> Q> тактикле, дабы настраивалась и расширялась известным инструментом.
>
> Если для использования языка для RAD требуется среда с поддержкой
> рефакторинга, то это неподходящий для RAD язык. IMHO. RAD и
> рефакторинг, конечно, сочетаются, но RAD и развесистый рефакторинг - уже
> нет.
Про развесистый речи не шло. Переименовать переменную, если что, хотелось бы
одним нажатием кнопки, а не составлением регекспа с надеждой, что он
правильно составлен с первого раза.
Как насчёт остального?
> Два десятилетия назад грамотная обработка ошибок времени выполнения со
> внятным восстановлением была зачастую недопустимой роскошью. А вот
> сейчас я, когда мне нужно гарантированное try/finally с нормальной
> вложенностью и при этом required пакеты, я откладываю в сторону bash и
> беру perl, не забывая поглядывать, входит ли в perl-base тот модуль,
> который я use.
>
> Короче, на bash я видел вменяемые скрипты в пол-экрана, ну в экран.
> Если в этот размер удалось втиснуть программу - будет программа. У
> того, что длиннее, с регулярностью, достойной лучшего применения,
> наблюдается "post-install script failed" на ровном месте.
Скрипты инициализации невменяемые?
> С configure, как знают все, занимавшиеся кросс-сборкой, типичны те же
> самые проблемы. И главное, хрен в том скрипте найдешь, что надо
> поправить, чтобы оно, блин, перестало путать билд-систему, хост-систему
> и целевую систему.
Сборщики linux - программ -- мазохисты, консерваторы, или квалификации не
хватает?
> Q> И да, на bash можно написать "полноценную" программу в несколько
> Q> строчек. Как насчёт тикля?
>
> До половины экрана короче программа на bash. После - на tcl. Ну, если
> говорить о программе, которая работает, а не "вроде работает, если
> повезет".
Вот по этой причине размера tcl-программ, и нужны готовые. Особенно с учётом
того, что реальные скрипты в том же дебиане - далеко не один экран.
> >> sh - это RAD, на нем комплектов
> >> программ без крайней необходимости не пишут. Отдельные программы -
> >> есть.
>
> Q> Полноценная обработка входных данных и исключений, а не
> Q> "неправильные входные данные" и "не могу открыть файл", или
> Q> псевдографический интерфейс сойдёт за крайний случай? Это, всё-таки,
> Q> пользователем нелегко программируется. Это не в конвейер программы
> Q> объединить.
>
> Полноценная обработка исключений пользователем нелегко программируется
> на абсолютно любом языке. Потому что это задача с высокой
> алгоритмической сложностью. Она в мозг плохо влезает, разве только по
> мелким частям.
Вот поэтому обработка исключений в RAD по имени sh - это и есть тот крайний
случай, один из, когда готовая программа очень желательна. Причём для
пользователя этот крайний случай - далеко не крайний, он - любитель
законченных программ.
Reply to: