В ембеддинге у него ниша есть только на 32-битных MCU с десятками-сотнями килобайт ОЗУ и лишней сотней килобайт ROM (см. jim). За исключением picol, который вполне на atmega64 живёт, но это недоtcl убогий. На PC -- ну считай, альтернатива питону. Со своей графической мордой (а к питону если тот же Tk прикручивать, то он там не естесственен, более того, Tcl за собой потянет всё равно) и возможностью относительно легко привязывать функции в C-шные программы (IMHO в остальных похожих языках с этим туго, разве что на SWIG расчитывать). Графическая морда кстати, несмотря на страшный внешний вид, имеет некоторые преимущества перед Gtk или Qt (где быстро упирается в C++ всё). CPAN своего конечно нет, но с библиотеками тоже не так уж и плохо (а вот на счёт python не уверен!), есть более-менее хорошо работающая поддержка последовательных портов (embedded!), и масса других лулзов описанных лучше здесь:
http://lurkmore.ru/Tcl
Ну ещё плюс, собственно в исходниках Tcl+Tk своими руками лазить как-то можно, не такое уж оно и bloatware. А оно надо, потому, что можно делать tclkit, когда внутрь одной exe упрятан собственно движок tcl и tk, необходимые .tcl файлы и другие "ресурсы", а движок слинкован (статически) с твоим C-кодом. Который может бы как tcl-функции доступен, либо наоборот, вызывать интерпретатор по-потребности (в т.ч. для создания и обслуживания GUI, например, а собственно логика в C-коде). Да, и под windows оно всё как-то работает (собирать только надо в mingw == урезанный cygwin, нативную windows сборку в MSVC я ниасилил) более-менее пристойно, включая GUI (у Gtk, например, не всё с этим хорошо...)
fk0, легенда (14.10.2010 12:21, просмотров: 117) ответил Snaky на fk0, расскажи про Tcl: зачем вообще нужен, где в основном применяешь? а то я как-то особо не увидел для него ниши в ембеддинге: для МК слишком жирный и интерпретаторов можно сказать нет (или совсем нет), если просто скрипт на PC накидать чтобы