Q -> [email protected] @ 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'ом, и только в очень редких случаях ожидаемой ошибки или скрипта, рассчитанного на употребление непрограммистом в течение _нескольких лет_ (да, я иногда пишу такие) предусматриваю какое-то восстановление. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
