Tcl/Tk 8.5a5 is released.

>>> На собственном опыте могут сказать, что писать на нем просто и приятно. Для тех же, кто считает, что большая программа может быть написанно только с использованием ООП могу посоветовать изучить xotcl, snit и itcl (все три), они изменять ваше представление об ООП.

>> О, попался знающий человек :). Так, а что использовать? Не все же три? И что будет стандартом?

>snit имеет ограниченное применение при кодировании виджетов и не более того.

snit имеет смысл применять только тогда, когда он для решения какой-то конкретной задачи удобнее, чем другие расширения. Тоже самое можно сказать и про itcl и про xotcl

>itcl уже мёртв.

Ложь. То, что он не релизится каждый месяц говорит лишь о том, что разработчиков и пользователей он устраивает в нынешнем виде.

>xotcl скорей тоже мёртв. В 9-й версии будет урезанная версия xotcl, предположительно, как штатная объектная система.

это пациент живее всех живых, ибо версии выходят весьма часто, экспериментальное расширение для ООП.

>Ну так покажите же его!?

Показать как в Forth реализуется инкапсуляция, полиморфизм, наследование и "перегрузка операторов"? А книжки зачем?:)

>> На собственном опыте могут сказать, что писать на нем просто и приятно. Для тех же, кто считает, что большая программа может быть написанно только с использованием ООП могу посоветовать изучить xotcl, snit и itcl (все три), они изменять ваше представление об ООП.

>Snit практически пригоден исключительно как средство построения megawidgets.

А для создания других объектов он что, непригоден? Глупость! Другое дело, какое требование вы приедъявляете в ООП расширению. Я с помощью snit пишу расширения - очень удобно раздавать с помощью него объектные команды. Для сравнения: вручную написанный клиент dict протокола содержал на треть больше строк, чем snit версия.

>itcl на фоне xotl смысла не имеет (имеется эмулятор itcl на xotcl). Сам xotcl, как ни странно, тоже склонен к порождения описанных проблем. Я не просто так пишу -- давно посмотрел и попробовал.

itcl имеет смысл хотя бы потому, что нельзя для всех проблем предлагать одно и тоже решение. iTcl - это ООП в стиле C++, xotcl - в стиле Smalltalk. И эти подходы отличаются. Snit - это третий вариант. С таким разнообразием конечно трудно примирится тем, у кого понятие ООП заменено на C++.

>> Ошибки времени исполнения могут быть перехвачены, а вот в C++ и Java они могут иметь более фатальные последствия.

>Для юзера результат один -- программа не рабоает. Поэтому таких ошибок быть не должно, a tcl их очень сильно провоцирует. Хотя я в другом соглашусь -- лучше такие ошибки, чем сразу выпадение в корку. Иногда это весьма критично.

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

Что касается провоцирования, то все зависит от того, насколько хорош выбранный вами стиль написания программ.

Что касается меня, то я стараюсь использовать ФП подход и создавать DSL для задачи, это сильно уменьшает использование переменных, да и вообще код приложения становиться меньше, проще и понятнее. Кстати в tcl8.5 вроде бы lambda и apply появятся, это сильно упростит кодирование.

----

daapp

> Паскаль предназначен для создания пирамид

Не пирамид, а пирамидок, вас обманули. :)

Дворакская раскладка проприентарная до усрачки,недаром все ИТ гиганты от нее отказались, слишком большие отчисления за патенты.

Гхмм? А почему тогда поддержка этой раскладка есть во всех ОС?

Патент на Дворак раскладку автор получил в 1936 - патент уже протух.

/me в ужосе бросился выкидывать все dvorak раскладки из xkeyboard-config...

Тут проскальзывали несправедливые наезды на пакет ActiveTcl от ActiveState, хотелось бы заступиться за последнюю и посоветовать прочитать http://www.activestate.com/Products/ActiveTcl/license_agreement.plex чтобы убедиться, что там всё либерально и права ничьи не нарушены.

Три года назад, наша фирма была вынуждена в "пожарном порядке" менять платформу, СУБД и средства разработки, и мне было нужно создать GUI к существующему функционалу на Linux-платформе, причем за короткий срок (3-4 месяца). По определенным причинам (Open Source, сертификация и т.д.), средства разработки ограничивались - Qt3.0 и C++, которые надо было осваивать практически с нуля. Тогда случайно (можно сказать из чистого любопытства) "наткнулся" на TCL/Tk..., в результате удалось в установленный срок выполнить поставленную задачу. Использование в качестве девелопера - Visual TCL, помогли значительно упростить процесс и сократить сроки разработки конечного продукта. Вышесказанное, прошу принять к сведению тех, кто на страницах форума подвергает остракизму TCL/Tk. P.S. Вопрос: если еще какие-нибудь средства разработки GUI на TCL/Tk, подобные Visual TCL?