Re: window managers
Q -> debian-russian@lists.debian.org @ Tue, 7 Aug 2012 12:57:12 +0400:
>> Да. Предмет недавнего холивара тут - tcl/Tk - типичный и вполне
>> работоспособный RAD. "И куды приятней баша, хоть по виду и не баш." И
>> кстати, с ролью баша, т.е. с задачей RAD для команднострочных
>> инструментов, тоже справляется - но уже без Tk, разумеется.
>>
>> Сейчас уже ко всему множеству скриптовых языков есть библиотеки,
>> позволяющие писать на них программы с гуем, в основном в стиле этого
>> языка. Ну, понятно, биндинги к разным тулкитам. (Исключение, пожалуй,
>> perl - гуевую библиотеку в перловом стиле никто сделать не смог.) Я
>> работал в стиле RAD на комплектах tcl/TK, python/Gtk, немножко perl/Tk.
>> Первый гораздо радее остальных, но работоспособные программы за
>> приемлемое время пишутся на любом комплекте.
Q> Я, скорее всего, вас не понял. И вы, надеюсь, поясните подробнее,
Q> что вы имели ввиду. Потому что иначе мне придётся признать, что под
Q> RAD вы понимаете исключительно клепателя формочек с мышевозным
Q> интерфейсом, который так не любят некоторые линуксоиды. И которые,
Q> на самом деле, GUI по своей сути являются с большой натяжкой.
Похоже, мы друг друга не понимаем на уровне "в стиле Unix" и "RAD". По
моим представлениям, RAD, в качестве примера средства для которого
приводится bash - это скриптование для решения какой-то довольно узкой
задачи. Но действительно быстро, день-два, в сложном случае неделя.
То есть прототип на 2-3 экрана кода. Какие тут нафиг IDE, специальные
средства поддержки рефакторинга и ты пы? Что с ними делать об эти 2-3
экрана? Какие богатые библиотеки? За день-два для тысячи библиотек
даже описания не прочесть. Нужно три-четыре библиотеки, только вот
ровно нужные. Остальной CPAN для этих задач не нужен, он нужен для
других.
Q> А если даже так, то предполагается богатая библиотека к
Q> языку. aptitude мне подсказывает, что для перла и пайтона библиотек
Q> сильно больше тысячи.
Ну, да. Но стоит помнить, что для асинхронной работы с файлами, пайпами
и сокетами в перле потребуется подтянуть пять-десять библиотек. В tcl -
ни одной. Он в этом смысле гораздо ближе к bash.
Q> А так, какие с его помощью _пользователь_ может решить задачи?
Q> Скажем, браузер ему нужен. Уточняю: полноценный, поддерживаемый,
Q> поддерживающий последние стандарты браузер, дабы не было ссылки на
Q> hv3. И раз после Tcl стоит Tk, то никаких gnocl с его gnocl::webkit,
Q> который тоже заготовка, а не готовый, рихтуемый пользователем под
Q> себя продукт. Его действия?
Браузер у него уже есть, им только управлять нужно. Для этого гуй,
прямо скажем, вообще не нужен, а Tk нужен только для того, чтобы
выяснить, куда послать команду. У меня были такие инструменты к fvwm, а
Витус, полагаю, до сих пор такими пользуется. Написано на tcl/tk,
именно что.
Хотя вру, у меня там было целое одно окошечко для ввода того
единственного слова, которым нужно было кастомизировать команду. С
фильтром и автодополнением, все дела. И несколько разных хоткеев на
разные варианты запуска.
Q> Коммандострочных программ это тоже касается. Вы же не надеетесь на
Q> использование консольных утилит в Tcl?
То есть? Консольную (т.е. такую, которой нужен терминал) я запущу
посредством xterm -e. А команднострочные, конечно, запускаю, зачем на
tcl делать то, для чего утилита уже написана? UNIX way, однако.
Q> Ну и да. В чём писать программы на Tcl/Tk? Подсветка
Q> синтаксиса/семантики, контекстно-зависимое автодополнение, отладка,
Q> контекстно-зависимые подсказки, рефакторинг, навигация, whatever +
Q> автоматизированная часть, позволяющая временно объединять компоненты
Q> соплями, как это делает VisualTcl. Разумеется, среда должна быть на
Q> тактикле, дабы настраивалась и расширялась известным инструментом.
Если для использования языка для RAD требуется среда с поддержкой
рефакторинга, то это неподходящий для RAD язык. IMHO. RAD и
рефакторинг, конечно, сочетаются, но RAD и развесистый рефакторинг - уже
нет.
>> Q> А так же комплект программ, с помощью этой RAD написанный, и
>> Q> подстраиваемый пользователем под себя?
>>
>> А он, пардон, в случае bash & Co есть?
Q> Есть. Скрипты инициализации, конфигурационные файлы, файлы
Q> инициализации, ./configure (да, я знаю, откуда это берётся),
Q> pre-post-скрипты, ну и некоторые прикладные программы. Подозреваю,
Q> что в слаке таких программ больше, что два десятилетия назад доля
Q> шелл-скрптов было больше, и что шелл-программ было бы ещё больше,
Q> если бы не перл.
Два десятилетия назад грамотная обработка ошибок времени выполнения со
внятным восстановлением была зачастую недопустимой роскошью. А вот
сейчас я, когда мне нужно гарантированное try/finally с нормальной
вложенностью и при этом required пакеты, я откладываю в сторону bash и
беру perl, не забывая поглядывать, входит ли в perl-base тот модуль,
который я use.
Короче, на bash я видел вменяемые скрипты в пол-экрана, ну в экран.
Если в этот размер удалось втиснуть программу - будет программа. У
того, что длиннее, с регулярностью, достойной лучшего применения,
наблюдается "post-install script failed" на ровном месте.
С configure, как знают все, занимавшиеся кросс-сборкой, типичны те же
самые проблемы. И главное, хрен в том скрипте найдешь, что надо
поправить, чтобы оно, блин, перестало путать билд-систему, хост-систему
и целевую систему.
Q> И да, на bash можно написать "полноценную" программу в несколько
Q> строчек. Как насчёт тикля?
До половины экрана короче программа на bash. После - на tcl. Ну, если
говорить о программе, которая работает, а не "вроде работает, если
повезет".
Q> Вот готовые наработки и нужны.
>> sh - это RAD, на нем комплектов
>> программ без крайней необходимости не пишут. Отдельные программы - есть.
Q> Полноценная обработка входных данных и исключений, а не
Q> "неправильные входные данные" и "не могу открыть файл", или
Q> псевдографический интерфейс сойдёт за крайний случай? Это, всё-таки,
Q> пользователем нелегко программируется. Это не в конвейер программы
Q> объединить.
Полноценная обработка исключений пользователем нелегко программируется
на абсолютно любом языке. Потому что это задача с высокой
алгоритмической сложностью. Она в мозг плохо влезает, разве только по
мелким частям. Поэтому для _скриптов_ я в норме ограничиваюсь stack
trace'ом, и только в очень редких случаях ожидаемой ошибки или скрипта,
рассчитанного на употребление непрограммистом в течение _нескольких лет_
(да, я иногда пишу такие) предусматриваю какое-то восстановление.
Reply to: