On 09.08.2012 16:51, Q wrote:
On Thursday 09 August 2012 00:27:04 Alexander Danilov wrote:
Я пробовал много (может быть и все) IDE для Tcl, так вот наиболее пригодный
для RAD - emacs
Если это так, то есть разбухший текстовый редактор - лучший RAD, то с
пользовательским программированием в linux и в самом деле никак.
emacs - это удобный текстовый редактор, а насколько он будет разбухшим определяет конкретный
пользователь в конкретном случае. На фоне всяких там IDE и RAD emacs просто невероятно тощий.
Впрочем, emacs ругают те, кто им не пользуется.
man Tcl - 12 правил.
Это намёк на то, что знание синтаксиса ЯП достаточно для написания программ?
Или вы не учли, что пользователькое программирование подразумевает
первоначально полное отсутствие знания о программировании? Ну, кроме
элементарных школьных знаний.
Это намёк на то, что язык чрезвычайно прост в основе. И для его использования достаточно, чтобы
человек умел читать.
Я как-то уже делился в этом списке рассылки своими наблюдениями о том, что
очень много файлов ил каталогов /etc и немало из /var можно загрузить в
интерпретатор тикля как обычных тиклевый скрипт таким вот образом:
proc unknown {args} {
# здесь используем голову по назначению
}
source /etc/какой-нибудь_файл
В unix интерпретатор тикля используется в большом количестве программ, и не
всегда те, кто их написал, догадываются о том, что в очередной раз изобрели
лисапед.
Даже если принять тот факт, что мы не работаем с бинарными данными и данными
других форматов (скажем, JS, HTML или тот же LATEX), что на самом деле не
так, а так же тот факт, что читаемые данные синтаксически и семантически
корректны (что несколько ограничивает возможности программы), то варианта 2:
1. Писать достаточно универсальный скрипт, то есть строить синтаксическое и
семантическое дерево разбора + процедуры для работы с ним + проверку
корректности дерева во время/после изменения + сохранение данных с учётом
прочитанного синтаксиса/ семантики. Это явно не уровень пользователя, во
всяком случае, начинающего, тем более, очень глупо писать это каждому, не
выкладывая результата в публичный доступ. И вышеприведённые возможности
особо не помогают -здесь готовые библиотеки нужны.
2. Писать что-нибудь специализированное, кустарное, почти ничего не умеющее,
резко ограничивая функциональность скрипта. Такое может удовлетворить только
аскетов, ну или сгодится тогда, когда нужно решить только такую задачу.
Про DSL надеюсь в курсе? Так вот Tcl очень удобен для DSL.
Нужен пример? G code (язык для управления станками с ЧПУ, придуманный в 1968г) легко превращается в
Tcl после расстановки пробелов в плохо отформатированном коде, и тогда даже unknown определять не надо.
Если принимать за RAD сам Tcl, то и общество и поддержка есть, и русская в
том числе. И даже немного книг на русском есть.
А можно ссылки, за исключением ЖЖ и списков рассылки?
А вы на тикле программите или ссылки для продолжения троллинга нужны?
Тогда бы пришлось парсить бинарные данные где-то там в памяти, "Memory
fault: core dumped..." - да, помню-помню, весёлое было время.
Что-то я не помню, чтобы package require приводил к необходимости парсить
бинарные данные. Есть такие случаи?
Просто очень умные люди, я в своё время компилял много чего на sco unix -
низкий им поклон, без autoconf/automake проще было бы застрелится, чем
использовать этот sco.
Изначальный смысл был в том, что программы на bash больше одного экрана -
невменяемые, но их, при этом, не особо и заменяют. А наличие альтернативы без
внедрения недостаточно.
Программы на bash больше одного экрана бывают разные, и стиль написания тоже
бывает разный.
Я не видел "Руководство на написанию больших программ на BASH", может поэтому и качество таких
программ не радует. Bash - специфический инструмент для специфических задач, полной альтернативы ему
нет - скриптовые языки (tcl,perl,python,awk, sed, ...) ему не замена, так как не позволяют так
удобно управлять процессами, но и сам bash несовершенен, так как этот механизм управления процессами
не доведён до логического завершения, и средства обработки данных (строки, числа) весьма скудные.
Итог: наиболее оптимальный вариант - писать обработку данных на скриптовых языках, а управлять этими
обработками на shell.
А по поводу альтернатив без внедрения - существует немало технически совершенных инструментов,
широкому распространению которых помешали совершенно нетехнические факторы, как, например, бабло.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5024d2da.8040...@gmail.com
