Re: window managers
On 07.08.2012 20:20, Q wrote:
On Tuesday 07 August 2012 16:48:26 Artem Chuprina wrote:
[skip]
То есть прототип на 2-3 экрана кода. Какие тут нафиг IDE, специальные
средства поддержки рефакторинга и ты пы? Что с ними делать об эти 2-3
экрана?
А что полезного можно написать в 2-3 экранах кода? Одна формочка без обработки
столько займёт, да и что-то типа VisualTcl в такой объём точно не впишется.
Сэр, уже, как минимум дважды, упомянутое вами словосочетание VisualTcl является грязным
ругательством. Поясню почему:
1. Код самого VT - это просто ...
2. Много глюков, и они в важных местах, так что создать законченную формочку - это подвиг.
3. UI самого VT - он просто для ярых фанатов мышевозения, то есть он страшен на вид и чудовищно
неудобен для RAD.
4. Тиклевый код, создаваемый VT - я видел и хуже качества, но он был написан вручную, а этот
сгенерирован.
Я пробовал много (может быть и все) IDE для Tcl, так вот наиболее пригодный для RAD - emacs (хоть он
меня и бесит местами, но программирую я только в нём и не только на тикле).
И ещё, программирование UI с использованием динамических языков, в средах, изначально разработанных
для статических языков - это создание идеально круглых отверстий в граните с использованием черепной
коробки в качестве сверла.
Какие богатые библиотеки? За день-два для тысячи библиотек
даже описания не прочесть. Нужно три-четыре библиотеки, только вот
ровно нужные. Остальной CPAN для этих задач не нужен, он нужен для
других.
А для консольных программ документация короткая, да? man sed, grep и awk - это
уже три тысячи страниц, справочника, между прочим. Это без синтаксиса
регекспов и отладки, без которых новичок этим пользоваться не сможет. Это без
редактора, языка для него и разных режимов. Это без основ Unix и bash. И, уж,
тем более, без документации тех программ, которые, собственно, и несут в себе
всю необходимую внешнюю функциональность.
man Tcl - 12 правил.
Вы наверняка знаете, какой из этого следует выход. И для библиотек он тоже
годится.
Вон, задача в начале ветки стояла - в стиле Unix way пользователем добавить к
программе возможность сохранения сессии средствами RAD через libSM. Если вы
подобные зависимости в 3-4 библиотеки добавите, они, библиотеки, станут
неподъёмными.
Ну, да. Но стоит помнить, что для асинхронной работы с файлами, пайпами
и сокетами в перле потребуется подтянуть пять-десять библиотек. В tcl -
ни одной. Он в этом смысле гораздо ближе к bash.
Это всё здорово, пока не потребуется, скажем, udp, ftp и прочее. А потом с
прочитанными данными что-то делать надо: парсить их, просматривать,
редактировать...
Я как-то уже делился в этом списке рассылки своими наблюдениями о том, что очень много файлов ил
каталогов /etc и немало из /var можно загрузить в интерпретатор тикля как обычных тиклевый скрипт
таким вот образом:
proc unknown {args} {
# здесь используем голову по назначению
}
source /etc/какой-нибудь_файл
В unix интерпретатор тикля используется в большом количестве программ, и не всегда те, кто их
написал, догадываются о том, что в очередной раз изобрели лисапед.
Браузер у него уже есть, им только управлять нужно. Для этого гуй,
прямо скажем, вообще не нужен, а Tk нужен только для того, чтобы
выяснить, куда послать команду. У меня были такие инструменты к fvwm, а
Витус, полагаю, до сих пор такими пользуется. Написано на tcl/tk,
именно что.
Управления мало. Вон, задача с сохранением сессии была. Её разве можно решить
внешними средствами, не залезая в нутро программы?
А на инструменты ваши, конечно, интересно посмотреть. Заодно всплывает
проблема наличия русского сообщества RAD. С сайтом и поддержкой.
Если принимать за RAD сам Tcl, то и общество и поддержка есть, и русская в том числе.
И даже немного книг на русском есть.
То есть? Консольную (т.е. такую, которой нужен терминал) я запущу
посредством xterm -e. А команднострочные, конечно, запускаю, зачем на
tcl делать то, для чего утилита уже написана? UNIX way, однако.
А дальше возникает проблема парсинга вывода. Синтаксис которого может быть не
описан в документации, не предназначен для разбора регекспами или и вовсе
быть естественным языком.
Что делать с программой только с псевдографическим интерфейсом, я не знаю.
Unix-way, да. Современный подход.
Если бы консольная/команднострочная программа была бы библиотекой, парсить
текст бы не пришлось.
Тогда бы пришлось парсить бинарные данные где-то там в памяти, "Memory fault: core dumped..." - да,
помню-помню, весёлое было время.
[skip]
С configure, как знают все, занимавшиеся кросс-сборкой, типичны те же
самые проблемы. И главное, хрен в том скрипте найдешь, что надо
поправить, чтобы оно, блин, перестало путать билд-систему, хост-систему
и целевую систему.
Сборщики linux - программ -- мазохисты, консерваторы, или квалификации не
хватает?
Просто очень умные люди, я в своё время компилял много чего на sco unix - низкий им поклон, без
autoconf/automake проще было бы застрелится, чем использовать этот sco. А то, что со временем
autoconf стал тяжёл - так это не трагедия, свою задачу он с блеском выполнил - GNU софт получил
большое распространение на несвободных системах. На смену autoconf придут другие, вот например на
Jim (диалект тикля) делают вариант autoconf - очень перспективный вариант получается.
Reply to: