[dxp 50]

Интересно, почему такая популярность у Tcl в HDL САПРах? Что в нем такого особенного, что его так любят производители синтезаторов, симуляторов и всего софта, предназначенного для проектирования FPGA/CPLD и ASIC? И почему в САПРах других направлений он не завоевал позиций?

 

По моему достаточно начальному впечатлению язык вполне так себе (если не сказать, что убогий). Но, может, я просто не понял, в чем там цимус. Вот и хочется понять.

[makc 199]

TCL - переводится как "Tool Command Language". Т.е. он разрабатывался с целью встраивания интерпретатора в различные инструментальные средства. При этом появился он в 1988 году, на год позже Perl и на два года раньше Python. Однако у TCL рано появилось расширение Tk, позволяющее легко создавать графический интерфейс пользователя для программ, написанных на TCL. Perl и Python в этом отношении отстали. Т.е. его нацеленность на встраивание и наличие Tk, с моей точки зрения, и повлияли на его популярность с точки зрения его применения в HDL САПРах. Это довольно логично.

 

Да, Perl и Python сейчас можно легко встроить в любой программный пакет, если появится желание у разработчиков. Но какой смысл переходить на аналог уже имеющегося TCL, если заметных преимуществ, кроме другого синтаксиса (может быть более удобного) не появится?

 

По моему достаточно начальному впечатлению язык вполне так себе (если не сказать, что убогий). Но, может, я просто не понял, в чем там цимус. Вот и хочется понять.

 

Он слегка напоминает shell-скрипты. Но его возможности шире, при этом простота синтаксиса может показаться убогостью, однако не смотря на это TCL позволяет решать требуемые задачи весьма эффективно и лаконично. О вкусах не спорят, кому-то и язык регулярных выражений кажется абракадаброй. ;)

[dxp 50]

TCL - переводится как "Tool Command Language". Т.е. он разрабатывался с целью встраивания интерпретатора в различные инструментальные средства. При этом появился он в 1988 году, на год позже Perl и на два года раньше Python. Однако у TCL рано появилось расширение Tk, позволяющее легко создавать графический интерфейс пользователя для программ, написанных на TCL. Perl и Python в этом отношении отстали. Т.е. его нацеленность на встраивание и наличие Tk, с моей точки зрения, и повлияли на его популярность с точки зрения его применения в HDL САПРах. Это довольно логично.

Да, я в курсе истории сознания и названия. Tk, насколько понял, это расширение в части GUI. Как это расширение могло оказать влияние на широкое применение в HDL САПРах, не понятно. Там GUI чаще всего пишется совсем не на Tcl/Tk (исключение составляет Modelsim и именно GUI в нем и является наиболее слабым и горбатым местом). Мне кажется, что тут больше повлияло название - командный язык для тулов. Точно так же, как переименовали Accel EDA в PCAD, и тучи пикадовцев, сидевших на ДОСовых пикадах, заслышав о появлении пикада под винду, ломанулись в PCAD2xxx, хотя у него с ДОСовым пикадом общего только название. Т.е. на психологии сыграли.

 

Да, Perl и Python сейчас можно легко встроить в любой программный пакет, если появится желание у разработчиков. Но какой смысл переходить на аналог уже имеющегося TCL, если заметных преимуществ, кроме другого синтаксиса (может быть более удобного) не появится?

Ну, эт кому как. Я бы не сказал, что у тот же Python отличается от Tcl только синтаксически. Там философия совсем другая.

 

Он слегка напоминает shell-скрипты. Но его возможности шире, при этом простота синтаксиса может показаться убогостью,

Убогостью кажется его основаная идея - все операции представляют собой строку, где первая лексема - команда, остальные - аргументы. Из-за этого приходится вполне мозги выворачивать наизнанку. Читабельность программ начинает конкурировать с программами, использующими обратную польскую запись.

 

Не знаю, как вы, я а так после питона вообще офигеваю. Одно хорошо, что не надо, видимо, сильно глубоко копать в него. Да и САПРах скрипты весьма примитивные - типа задания параметров да запуска исполняемых... Кстати, заметьте, нигде, кроме обсуждаемых САПРов оный язык особой популярностью не пользуется (еще для Web дизайна, вроде используют, но та своя специфика, насколько он там хорош, судить не берусь).

 

однако не смотря на это TCL позволяет решать требуемые задачи весьма эффективно и лаконично.

Ну, и прикиньте, проще или нет было бы все это делать на том же питоне (насколько помню, вы с этим языком тоже достаточно близко знакомы).

 

Насчет простоты - есть еще такой язык (уж не знаю, с какой целью его придумали, наверное специально постебаться). Зацените. Tcl по простоте и лаконичности ему, конечно, уступает. Но тендеция, имхо, та же.

 

О вкусах не спорят, кому-то и язык регулярных выражений кажется абракадаброй. ;)

Это вообще не язык, это правила составления расширенных масок (pattern'ов).

[fk0 0]

Интересно, почему такая популярность у Tcl в HDL САПРах?й он не завоевал позиций?

 

По моему достаточно начальному впечатлению язык вполне так себе (если не сказать, что убогий). Но, может, я просто не понял, в чем там цимус. Вот и хочется понять.

 

Альтернатива? Требования: простой (лисп не предлагать), достаточно функциональный, обладающий множеством прикладных библиотек и расширяемый на все случаи жизни. Да, и встраиваемый разумеется, мультиплатформенный. Навскидку вариантов-то и не шибко много. Perl разве что по всем пунктам кроме одного превосходит -- он сложный для программиста в плане встраивания, так и для пользователя САПР в плане программирования.

 

Убогий... Нет. Он *ПРОСТОЙ*. Если чего-то не хватает, то это многое чего реализуется загрузкой дополнительных библиотек. Нужно ООП, например -- на выбор десяток разных вариантов. Из пакетов расширений. Ну и действительно, хорошая связь с Tk. Хоть тот же Perl и Python имеют поддержку Tk проблема в том, что сам Tk полагается на Tcl. Комбинация Tk+Tcl+Perl явно избыточна по сравнению Tcl+Tk.

 

На счёт убогих хочется привести в пример KEIL uVision. Встроенный недо-C, что, лучше? На нём вообще ничего написать нельзя. Tcl позволяет (разумеется не средствами языка, а опять же пакетами расширений) встраивание C-программ прямо в код на Tcl. Ну и GUI само собой.

[CaPpuCcino 0]

на счёт надстройки Тк не ведал - думал, что что-то на подобии ТЦЛ - вид сбоку. насколько хороши его графические возможности? заинтересовали (меня интересует легкий способ визуализации действий алгоритма по его дебаг-логу).

[fk0 0]

Убогостью кажется его основаная идея - все операции представляют собой строку, где первая лексема - команда, остальные - аргументы. Из-за этого приходится вполне мозги выворачивать наизнанку. Читабельность программ начинает конкурировать с программами, использующими обратную польскую запись.

 

Читабельность программ, и слову об, на порядок выше, чем у Perl (типичный ууе-код...)

 

Идея исключительно правильная для УПРАВЛЯЮЩЕГО ЯЗЫКА. Интегрированного с остальной операционной системой. Примерно как /bin/sh. Tcl -- единственный из немногих языков, на основе которого имеется практически полноценный shell (tclsh). Потому, что, например, странно по результатам вызова внешней программы получить от неё тип "целое со знаком" или "вещественное с двойной точностью". И уж тем более это не нужно самому пользователю. Если ему нужно целое со знаком есть соответствующие языки.

 

Мозги наизнанку. Мозги наизнанку -- это для с Forth или Lisp не знакомых. Вот где наизнанку. Tcl подобного недостатка лишён. Для арифметических выражений используется алгебраическая запись, для вызова команд-функций порядок записи аналогичен принятому в большинстве императивных ЯВУ (странно, что не слышно критики Microsoft Basic...) Говоря же о Python -- использовать в качестве shell язык, в котором работа оператора зависит от числа пробелов перед ним... -- это просто НЕРЕАЛЬНО. Ввод любой нетривиальной команды требует ручного её разбития на строки и ввода каждой с соответствующим числом пробелов. Такой язык годится только для текстового редактора, где видно относительное положение строк, и не годится для интерактивной работы, чисто из-за синтаксиса. Опять-же синтаксис не нагруженный скобками и прочим "ууе-кодом" более удобен именно при интерактивной работе.

 

 

 

 

 

на счёт надстройки Тк не ведал - думал, что что-то на подобии ТЦЛ - вид сбоку. насколько хороши его графические возможности? заинтересовали (меня интересует легкий способ визуализации действий алгоритма по его дебаг-логу).

 

wiki.tcl.tk

[CaPpuCcino 0]

Хоть тот же Perl и Python имеют поддержку Tk ...

можно ссылку на документик с изложением процесса встраивания, плз.

а хорош ли язык ТЦК для обработки регулярных выражений, если требуется проанализировать лог, по сравнению с тем же Перлом (не уступает ли по функциональности в этом разделе)

[fk0 0]

можно ссылку на документик с изложением процесса встраивания, плз

 

(Учу гуглить $50/час...)

 

http://docs.python.org/ext/ext.html

http://search.cpan.org/~nwclark/perl-5.8.8/pod/perlembed.pod

http://wiki.tcl.tk/2074

и рекомендую также: http://www.lua.org/

 

Скажу сразу, Tcl и Lua -- это вполне реально и разумно в плане размера. У Lua он для i386 порядка сотни кбайт, у Tcl для i386 будет порядка мегабайта с лишним (плюс Tk, но без ничего лишнего, чисто Tcl легче). Python и Perl даже и не пытался пробовать. Очевидно, что гигабайты ненужного хлама в комплекте и без него никак не заведётся. Плюс Tcl или Lua в том, что не нужно, кроме собственно exe, таскать лишнего. Если таки нужно зачем-то, то для Tcl имеется возможность прикрепления к тому-же exe архива с виртуальной файловой системой (смотрите, например, как устроен tclkit).

Изменено 7 ноября, 2007 пользователем Kirill Frolov

[dxp 50]

Альтернатива? Требования: простой (лисп не предлагать), достаточно функциональный, обладающий множеством прикладных библиотек и расширяемый на все случаи жизни. Да, и встраиваемый разумеется, мультиплатформенный. Навскидку вариантов-то и не шибко много. Perl разве что по всем пунктам кроме одного превосходит -- он сложный для программиста в плане встраивания, так и для пользователя САПР в плане программирования.

Python. Пожалуй самый простой ЯП. Очень прозачный и дружественный к пользователю. И при этом очень мощный! По возможностям ничем Tcl не уступает.

 

Говоря же о Python -- использовать в качестве shell язык, в котором работа оператора зависит от числа пробелов перед ним... -- это просто НЕРЕАЛЬНО. Ввод любой нетривиальной команды требует ручного её разбития на строки и ввода каждой с соответствующим числом пробелов. Такой язык годится только для текстового редактора, где видно относительное положение строк, и не годится для интерактивной работы, чисто из-за синтаксиса.

Какая нетривиальная команда имеется в виду? Речь же не идет о том, чтобы писать скрипты в консоли. Скрипты по любому пишутся в редакторе, а в консоли они только запускаются. Что касается выравнивания, то и это проблем не составляет. А если пользоваться IPyhton, то там это вообще автоматически делается. Кстати, имеется ли для Tcl подбный клиент - чтобы история команд была приличная, сохраниение ее между сессиями, подсветка синтаксиса и прочее?

 

Опять-же синтаксис не нагруженный скобками и прочим "ууе-кодом" более удобен именно при интерактивной работе.

Зато он нагружен тучей команд там, где без этого легко можно обойтись.

[CaPpuCcino 0]

(Учу гуглить $50/час...)

спасибо, пользоваться поисковиками я умею, и читать тоже. когда спрашиваю о ссылках интересуют именно рекомендованные документы, ведь у человека занимающимся какой-то областью наверняка найдутся документы наиболее ему приглянувшиеся локаничностью и полнотой.

в любом случае спасибо за ссылки :beer:

[makc 199]

Да, я в курсе истории сознания и названия. Tk, насколько понял, это расширение в части GUI. Как это расширение могло оказать влияние на широкое применение в HDL САПРах, не понятно. Там GUI чаще всего пишется совсем не на Tcl/Tk (исключение составляет Modelsim и именно GUI в нем и является наиболее слабым и горбатым местом). Мне кажется, что тут больше повлияло название - командный язык для тулов. Точно так же, как переименовали Accel EDA в PCAD, и тучи пикадовцев, сидевших на ДОСовых пикадах, заслышав о появлении пикада под винду, ломанулись в PCAD2xxx, хотя у него с ДОСовым пикадом общего только название. Т.е. на психологии сыграли.

 

Не только на психологии. Ведь если брать те же Python и Perl, то они являются типичными ЯВУ общего назначения. А тут нужно было что-то более специальное, чем и оказался Tcl.

 

 

Ну, эт кому как. Я бы не сказал, что у тот же Python отличается от Tcl только синтаксически. Там философия совсем другая.

 

Да, философия там другая. Но и назначение на более широкое применение, по сравнению с Tcl. Поэтому в нем большее разнообразие языковых конструкций, да и вообще он куда более монструозен. :) В то время как для Tcl по минимуму достаточно одного интерпретатора (похожего, кстати, на тот же bash).

 

Убогостью кажется его основаная идея - все операции представляют собой строку, где первая лексема - команда, остальные - аргументы. Из-за этого приходится вполне мозги выворачивать наизнанку. Читабельность программ начинает конкурировать с программами, использующими обратную польскую запись.

 

C другой стороны - это универсальность. Есть базис, довольно примитивный, замечу. На основе этого базиса строится все. Это логично. Да, для решения некоторых специфичных задач специальные средства могут оказаться удобнее, лаконичнее и производительнее. Но на то они и специальные...

 

Не знаю, как вы, я а так после питона вообще офигеваю. Одно хорошо, что не надо, видимо, сильно глубоко копать в него. Да и САПРах скрипты весьма примитивные - типа задания параметров да запуска исполняемых... Кстати, заметьте, нигде, кроме обсуждаемых САПРов оный язык особой популярностью не пользуется (еще для Web дизайна, вроде используют, но та своя специфика, насколько он там хорош, судить не берусь).

 

В том же Линуксе до недавнего времени было множество графических утилит, которые были написаны на Tcl/Tk. Почему? Думаю, по причине хорошей переносимости и универсальности языка и библиотеки Tk.

 

Что же касается необходимой глубины изучения Tcl, то она определяется целями: можно просто использовать команды в командной строке, можно писать скрипты и добавлять свои команды в среду для автоматизации рутинных действий, а можно с помощью того же Tk расширять графический интерфейс среды под свои нужды.

 

Ну, и прикиньте, проще или нет было бы все это делать на том же питоне (насколько помню, вы с этим языком тоже достаточно близко знакомы).

 

Да, с питоном я очень хорошо знаком. :) Но при этом совершенно не испытываю сложностей при использовании Tcl. Может быть просто привык... Как привык и не могу жить без (g)vim, в то время как другие люди от него плюются и крутят пальцем у виска, когда им говоришь, что этим редактором можно пользоваться.

 

Насчет простоты - есть еще такой язык (уж не знаю, с какой целью его придумали, наверное специально постебаться). Зацените. Tcl по простоте и лаконичности ему, конечно, уступает. Но тендеция, имхо, та же.

 

Да, язык что надо. :) Но вот читаемость у него куда хуже, чем у Tcl...

 

Это вообще не язык, это правила составления расширенных масок (pattern'ов).

 

Если есть четкое описание синтаксиса, то для меня это язык - http://en.wikipedia.org/wiki/Regular_expre...language_theory

 

 

на счёт надстройки Тк не ведал - думал, что что-то на подобии ТЦЛ - вид сбоку. насколько хороши его графические возможности? заинтересовали (меня интересует легкий способ визуализации действий алгоритма по его дебаг-логу).

 

Его возможности вполне достаточны чтобы с успехом создавать графические приложения. При этом если Вы представляете как в том же Qt писать без использования designer'a, то процесс создания графического интерфейса покажется очень знакомым, учитывая развитость пакера виджетов, который есть в Tk.

[fk0 0]

Python. Пожалуй самый простой ЯП. Очень прозачный и дружественный к пользователю. И при этом очень мощный! По возможностям ничем Tcl не уступает.

 

Не уступает. Превосходит. Как ЯЗЫК. Но и только. На этом всё заканчивается.

Суть TCL не в языке, а в том, что вокруг него сформировалось. А пользователю

не-программисту от мощного питона только лишняя головная боль. Там же с

первых страниц туториала пойдут типы данных, атрибуты, объекты -- что это такое

и зачем оно нужно для моей работы, спросит он. БЕЙСИК -- вот суть.

 

Какая нетривиальная команда имеется в виду? Речь же не идет о том, чтобы писать скрипты в консоли. Скрипты по любому пишутся в редакторе, а в консоли они только запускаются.

 

Есть такое понятие -- командный интерпретатор. Человек вводит команды, машина исполняет. При этом может происходить что угодно. Например, подобным образом возможно интерактивное управление прибором. Разумеется, что, в мире существуют несколько более интеллектуальные интерпретаторы, нежели command.com. В которых есть операторы и функции присущие полноценным ЯВУ. И скрипты в консоли вполне пишутся. Не на 200 строк, а на несколько. Например, если нужно выполнить какие-либо операции в цикле. Регулярно это проделываю сам. Когда программировал на Tcl, то регулярно использовал его интерпретатор для провеки каких-либо частей кода интерактивно -- это проще и лучше, чем с бестолковым пошаговым отладчиком.

 

Что касается выравнивания, то и это проблем не составляет. А если пользоваться IPyhton, то там это вообще автоматически делается.

 

Автоматически не бывает. Невозможно понять что имел ввиду пользователь. А если пользователю жестами приходится как-то отмахиваться от "интуитивно-понятной" автоматики, то это не сможет сделать программа пытающаяся через ту консоль пропихнуть какие-то инструкции интерпратотору.

 

Кстати, имеется ли для Tcl подбный клиент - чтобы история команд была приличная, сохраниение ее между сессиями, подсветка синтаксиса и прочее?

 

Есть Tkconsole, например. Если выкинуть подсветку синтаксиса и прочее, то tcl с командной строкой в linux работает через libreadline, которая обеспечивает дополнительный сервис (на уровне bash) по сравнению простым чтением stdin, как делает tcl сам по себе. Увы, но libreadline заGPL'ена и может не входить ни в windows, ни в коммерческие приложения. Но тут могут помочь графические "консоли" (один хрен, в windows нет человеческого эмулятора терминала, вроде xterm).

 

 

Вдогонку. Приходилось писать большую, относительно, программу на Tcl. Вот где Tcl по-полной проигрывает нормальным ЯВУ. Проблем вобщем там... хватает, чтоб я для

себя в следующей раз для аналогичной задачи выбирал C++ или *ВНИМАНИЕ*, Python, как "продвинутый C++". Вот место Питона.

 

А в скриптах на 1000 строк, где не нужны классы, типы данных и др. изращения, да там переменных никаких кроме глобальных ненужно -- TCL именно так и задуман. И хотя он имеет средства для создания больших программ, в TCL это делать уже сложно и проблемно.

Изменено 7 ноября, 2007 пользователем Kirill Frolov

[dxp 50]

Не только на психологии. Ведь если брать те же Python и Perl, то они являются типичными ЯВУ общего назначения. А тут нужно было что-то более специальное, чем и оказался Tcl.

Что более специальное в Tcl? То, что он больше шелл, чем ЯП?

 

Да, философия там другая. Но и назначение на более широкое применение, по сравнению с Tcl. Поэтому в нем большее разнообразие языковых конструкций, да и вообще он куда более монструозен. :) В то время как для Tcl по минимуму достаточно одного интерпретатора (похожего, кстати, на тот же bash).

Для питона тоже одного интепретатора достаточно. А широкие возможности карман в данном случае не тянут. Не надо, не используй. Насчет сложности тоже не соглашусь - на уровне элементарных команд они примерно одинаковы по сложности, отличия синтаксические. Возможно, кто привык к шеллу, тому и Tcl кажется нормальным, но на ЯП он похож меньше питона. Тогда бы и называли его кроссплатформенным шеллом, а не языком программирования. Многие вопросы (у меня) просто бы и не возникли.

 

Что же касается необходимой глубины изучения Tcl, то она определяется целями: можно просто использовать команды в командной строке, можно писать скрипты и добавлять свои команды в среду для автоматизации рутинных действий, а можно с помощью того же Tk расширять графический интерфейс среды под свои нужды.

Одно радует, что расширять можно не только скриптами на Tcl, но и на других языках. :)

 

Если есть четкое описание синтаксиса, то для меня это язык - http://en.wikipedia.org/wiki/Regular_expre...language_theory

Я имел в виду язык программирования. Язык программирования - это язык для записи алгоритмов... Хотя под это определение регулярные выражения тоже можно затащить. :)

 

Не уступает. Превосходит. Как ЯЗЫК. Но и только. На этом всё заканчивается.

Суть TCL не в языке, а в том, что вокруг него сформировалось. А пользователю

не-программисту от мощного питона только лишняя головная боль. Там же с

первых страниц туториала пойдут типы данных, атрибуты, объекты -- что это такое

и зачем оно нужно для моей работы, спросит он.

Типы данных есть и в Tcl, хотя официально декларируется, что тип данных там только один - строка. Но на деле эта строка является базовым типом данных, на который явно или неявно накладываются еще списки, массивы, выражения и т.д. Т.е. типов таких как бы нет, но объекты такие есть. Такая нелогичность не добавляет понимания (чего стОит только наличие разных команд для объединения - append, concat, lappend, join - только путаницу и создают, какая уж тут простота). В питоне же с типами все очень просто - есть строка, есть список, есть словарь (ассоциативный массив), есть числовые типы. Что в этом сложного? Это как раз структурирует понимание, тем самым облегчая его. Типы придуманы для упрощения работы, а не для усложнения. По уровню же абстракции обя языка примерно равны.

 

А вот синтаксис Tcl с его подстановками и командами сильно похож на птичий язык make, не в последнюю очередь из-за которого я с него (make) перелез на питоновый SCons.

 

Есть такое понятие -- командный интерпретатор. Человек вводит команды, машина исполняет. При этом может происходить что угодно. Например, подобным образом возможно интерактивное управление прибором. Разумеется, что, в мире существуют несколько более интеллектуальные интерпретаторы, нежели command.com. В которых есть операторы и функции присущие полноценным ЯВУ. И скрипты в консоли вполне пишутся. Не на 200 строк, а на несколько. Например, если нужно выполнить какие-либо операции в цикле. Регулярно это проделываю сам. Когда программировал на Tcl, то регулярно использовал его интерпретатор для провеки каких-либо частей кода интерактивно -- это проще и лучше, чем с бестолковым пошаговым отладчиком.

Прекрасно понимаю и сам пользуюсь тем же на питоне. Именно в интерактивном режиме. Что-то большое или часто/регулярно используемое пишется в редакторе и подгружается в интерктивный интепретатор, чтобы можно было расширять команды. Практически это дает возможность написать софт для отладки дивайса без использования GUI - описал какие надо команды и пускай их из интепретатора, запущенного в интерактивном режиме. Тут же делается и обработка полученных (от дивайса) данных, математика всякая (как в матлабе), что на Tcl делать вообще проблематично. Т.ч. каких-то особых преимуществ Tcl тут не просматривается.

 

Кстати, подскажите, как на Tcl можно в интерпретатор (или просто в скрипт) загрузить другой скрипт. Ну, аналог import в питоне.

 

Автоматически не бывает. Невозможно понять что имел ввиду пользователь. А если пользователю жестами приходится как-то отмахиваться от "интуитивно-понятной" автоматики, то это не сможет сделать программа пытающаяся через ту консоль пропихнуть какие-то инструкции интерпратотору.

Тем не менее в IPython если ввести выражение, заканчивающееся символом ':', то при переводе строки отступ делается автоматически (см картинку). Когда надо закончить ввод такой конструктции, надо просто установить курсор в начало строки на нажать Enter. Все просто и нисколько не хуже, чем на Tcl.

 

 

Есть Tkconsole, например. Если выкинуть подсветку синтаксиса и прочее, то tcl с командной строкой в linux работает через libreadline, которая обеспечивает дополнительный сервис (на уровне bash) по сравнению простым чтением stdin, как делает tcl сам по себе. Увы, но libreadline заGPL'ена и может не входить ни в windows, ни в коммерческие приложения. Но тут могут помочь графические "консоли" (один хрен, в windows нет человеческого эмулятора терминала, вроде xterm).

Не понял, как GPL мешает портировать программу под винду? Речь же не идет о том, чтобы программа была частью винды.

 

Вдогонку. Приходилось писать большую, относительно, программу на Tcl. Вот где Tcl по-полной проигрывает нормальным ЯВУ. Проблем вобщем там... хватает, чтоб я для

себя в следующей раз для аналогичной задачи выбирал C++ или

С++, конечно, не замена Tcl, совсем разные ниши и возможности.

 

*ВНИМАНИЕ*, Python, как "продвинутый C++". Вот место Питона.

Да, то, что можно расширять функциональность с помощью того же питона, это сильно скрашивает "особенности" Tcl. Пробовал exec python <script.py>, работает. Правда, обмен данными тут можно производить только через файлы. Может еще какой-то более прямой способ есть?

 

А в скриптах на 1000 строк, где не нужны классы, типы данных и др. изращения, да там переменных никаких кроме глобальных ненужно -- TCL именно так и задуман. И хотя он имеет средства для создания больших программ, в TCL это делать уже сложно и проблемно.

1000 строк - это уже прилично. Хотя, смотря что эти строки делают. Если куча set'ов да просто команды управления, то объем сложности не добавляет. А вот если математику метать, но тут и в сотне строк погибнуть можно.

 

Еще попутно вопрос: можно ли вызывать Tcl скрип на выполнение в batch режиме с аргументами из командной строки?

[andrew_b 15]

Кстати, подскажите, как на Tcl можно в интерпретатор (или просто в скрипт) загрузить другой скрипт. Ну, аналог import в питоне.

source?

 

Еще попутно вопрос: можно ли вызывать Tcl скрип на выполнение в batch режиме с аргументами из командной строки?

Естественно.

[dxp 50]

source?

Спасибо!

 

Естественно.

Как?