LINUX.ORG.RU

Tcl/Tk 8.5a5 is released.


0

0

Выпущена очередная промежуточная версия этого известного мультиплатформенного интерпретатора.

Скачать Tcl/Tk 8.5a5: http://www.tcl.tk/software/tcltk/down...

Напомним, что в отличии от большинства других языков программирования, Tcl/Tk имеет на всех поддерживаемых платформах привязку к нативным библиотекам и не имеет зависимостей от библиотек Gtk+/GNOME и Qt/KDE. Это позволяет достичь высокого быстродействия оконных приложений в XWindow, созданных с использованием библиотек Tcl/Tk. Долгое время в Tk были довольно ограниченные средства интеграции с нативной платформой, особенно под Unix. В версии 8.5 сделан упор на расширение взаимодействия с оконными системами, в частности с XWindow. Скриншот приложения, использующего Tcl/Tk 8.5, позволяет частично оценить возможности этой версии библиотеки.

http://sk1.sf.net/screenshots/sk1_cmy...

Если верить "Tcl/Tk 8.5 Roadmap" финальная версия не за горами.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от Cris

> Интересные господа fk0 && dmiceman. Один хвалит Тк, другой хз что. Но оба сошлись во мнении, что Tcl - это максимум для детских скриптишек.

Почему как скрипт -- так сразу детский? Иной скрипт 10000 строк кода заменяет. Но это именно скрипт. Самое важное, наверное, в нём то, что ОН ПРОСТОЙ. Когда скрипт становится сложным (>1000 строк плюс-минус в 10 раз) -- НАДО БРАТЬ БОЛЕЕ ПОДХОДЯЩИЙ ЯЗЫК ПРОГРАММИРОВАНИЯ. Почему -- смотри ниже.

> Но вот я не понимаю, как BMW и другие крупные конторы пишут на Тикле.

Что именно они на нём пишут? Вот в чём вопрос. Если tcl используется в качестве скриптового языка в других приложениях, если tcl использустся как RAD средство для быстрой склейки чего-нибудь из чего попало -- это то для чего он предназначен. Если на тикле пытаться писать, например, Mozilla или OpenOffice оно развалится не успев начаться. Первой проблемой будет -- нужна объектная система. Это уже первый признак того, что НУЖНО МЕНЯТЬ ЯЗЫК.

Тикль прекрасный инструмент что-то сделать *быстро*, в качестве макета, когда нужен именно скрипт, когда объём кода небольшой и весь умещается в голове. Он даёт средства визуализации, программирования, интерфейсы (программные) к чему угодно. Даже с COM-портами более-менее единообразно работает. Это КЛЕЙ, который позволяет из всего чего угодно склеить новую программу. СКЛЕИТЬ, но не написать. Написать на нём сложно и плохо.

> И никак из головы не выходит скриншот с количеством ошибок и качеством кода в разных языках. Брались Ява/Си/не помню что еще/Тикль. И по качеству кода и ошибок он зарулил все.

Очень интересен был бы подобный скриншот для 100, 200, 500, 1000, 2000, 5000, 10000 и 50000 строк кода. Было б видно, как тикль выигрывая "на коротких дистанциях" начинает резко отставать на длинных. Хорошо, когда всю программу можно разделить на "короткие дистанции". Независимо от использования или неиспользование тикля. А когда нельзя -- на первое место, боюсь, выходят такие монстры как Java и C++ -- для программ с большим объёмом кода и сильными связями в нём. Для TCL основными проблемами, при росте кода, будет являться, как ни странно, то самое, что называют его преимуществами: отсутствие такого понятия как тип данных, как собственно для данных, так и для процедур -- ошибки времени исполнения; отсутствие компилятора -- синтаксические ошибки времени исполнения как расплата за динамическую компиляцию; отсутствие чётко устаканившейся объектной системы с единообразным интерфейсом ко всем объектам; отсутствие элементов "декларативного программирования" (например, как объявления в C) только усугубляет путаницу и ведёт к росту числа ошибок. Такие программы как "static syntax checker" помогают мало -- для этого и писать на tcl надо как на C... Писать многочисленные тесты -- ими все возможные ситуации не охватить, просто тестов не напасёшься.

> Теперь насчет производительности. Это вообщем-то очень смешной аргумент. Понятно, что скриптовый язык будет проигрывать любому компилируемому. Но, насколько я сужу по тенденциям(тот же sk1), все что можно скриптуется, а что нельзя, профилируется и пишется на СИ.

Поэтому есть смысл стараться разделить всё на "короткие дистанции" и постараться их закодировать на C/C++, где это возможно. Если дистанция исключительно длинная -- TCL может быть лишь дополнением к логике программы реализованной на более подходящем языке (python, c++, java).

fk0
()
Ответ на: комментарий от fk0

> Очень интересен был бы подобный скриншот для 100, 200, 500, 1000, 2000, 5000, 10000 и 50000 строк кода. Было б видно, как тикль выигрывая "на коротких дистанциях" начинает резко отставать на длинных. Хорошо, когда всю программу можно разделить на "короткие дистанции".

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

Вобщем вопрос стоит просто. Может ли мощность языка компенсировать нестрогость данных.

Cris
()
Ответ на: комментарий от fk0

> Но вот я не понимаю, как BMW и другие крупные конторы пишут на Тикле.

>Что именно они на нём пишут? Вот в чём вопрос. Если tcl используется в качестве скриптового языка в других приложениях, если tcl использустся как RAD средство для быстрой склейки чего-нибудь из чего попало -- это то для чего он предназначен. Если на тикле пытаться писать, например, Mozilla или OpenOffice оно развалится не успев начаться. Первой проблемой будет -- нужна объектная система. Это уже первый признак того, что НУЖНО МЕНЯТЬ ЯЗЫК.

Касательно Mozilla - на tcl уже есть браузер, browsex называется, там часть на C, часть на Tcl, качество отображения среднее, есть также tkhtml widget, он претендует на прохождение acid2, это говорит о том, что написать Mozilla на Tcl не так уж сложно, вопрос нужно ли? Я бы предпочел иметь хорошо работающие компоненты из которых можно собрать приложение. Очень хорошо об этом написал Виктор Вагнер http://www.linuxrsp.ru/artic/true_unix_gui.html

>Тикль прекрасный инструмент что-то сделать *быстро*, в качестве макета, когда нужен именно скрипт, когда объём кода небольшой и весь умещается в голове. Он даёт средства визуализации, программирования, интерфейсы (программные) к чему угодно. Даже с COM-портами более-менее единообразно работает. Это КЛЕЙ, который позволяет из всего чего угодно склеить новую программу. СКЛЕИТЬ, но не написать. Написать на нём сложно и плохо.

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

>> И никак из головы не выходит скриншот с количеством ошибок и качеством кода в разных языках. Брались Ява/Си/не помню что еще/Тикль. И по качеству кода и ошибок он зарулил все.

>Очень интересен был бы подобный скриншот для 100, 200, 500, 1000, 2000, 5000, 10000 и 50000 строк кода. Было б видно, как тикль выигрывая "на коротких дистанциях" начинает резко отставать на длинных. Хорошо, когда всю программу можно разделить на "короткие дистанции". Независимо от использования или неиспользование тикля. А когда нельзя -- на первое место, боюсь, выходят такие монстры как Java и C++ -- для программ с большим объёмом кода и сильными связями в нём. Для TCL основными проблемами, при росте кода, будет являться, как ни странно, то самое, что называют его преимуществами: отсутствие такого понятия как тип данных, как собственно для данных, так и для процедур -- ошибки времени исполнения;

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

>отсутствие компилятора -- синтаксические ошибки времени исполнения как расплата за динамическую компиляцию;

для этого существуют средства типа frink http://wiki.tcl.tk/2611

>отсутствие чётко устаканившейся объектной системы с единообразным интерфейсом ко всем объектам;

учитывая однородный синтаксис Tcl можно сказать, что единообразный интерфейс ко всем объектам существует. Выглядит он так

object command ?arg1 arg2 ...?

>отсутствие элементов "декларативного программирования" (например, как объявления в C) только усугубляет путаницу и ведёт к росту числа ошибок.

Интересно, а что же тогда делают команды global, variable ?

>Такие программы как "static syntax checker" помогают мало -- для этого и писать на tcl надо как на C...

Для этого надо познакомится хотя бы с другими парадигмами, например ФП. На Tcl кстати вполне можно писать в функциональном стиле, не все возможности ФП конечно пока реализованы.

>Писать многочисленные тесты -- ими все возможные ситуации не охватить, просто тестов не напасёшься.

Но их писать надо

---

daapp

anonymous
()
Ответ на: комментарий от Cris

>Вобщем-то я бы годик назад и не заметил его, если бы не выкупил, что в нем можно писать самые навернутые конструкции.

тебе стоит еще попробовать Rebol. Я вобоще по большому не вижу разницы между Тиклем, Лиспом, Схемой и Реболом. И кстати Ребол в смысле очеловечивания языка самый удобный. Помниться читал в студгоды книгу Дьяконова по Форту, там было много примеров тоже навернутых конструкций, которые практически выглядели как человеческий язык.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

>>На Tcl кстати вполне можно писать в функциональном стиле, не все возможности ФП конечно пока реализованы.

Мысль очень спорная. Как можно писать в функциональном стиле на языке, где даже анонимных функций нет? Главная заповедь функциональшиков ("переменные суть зло") не выполняется!

geekkoo
()
Ответ на: комментарий от anonymous

> тебе стоит еще попробовать Rebol.

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

У него есть сейчас какая-то ниша? Или борется за место под солнцем с другими скриптовыми языками.

Cris
()
Ответ на: комментарий от anonymous

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

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

Cris
()
Ответ на: комментарий от geekkoo

> Где?

Они неявные :). В Тикле основная функция eval. Блоки кода строятся за счет строк. {} - является аналогом "", который не интерпретируется в момент исполнения. Тоесть конструкция:

if {$x > 0} {

...

} else {

...

}

представляет собой вызов функции if, которой передаются четыре текстовых аргумента: условие, блок if, else, блок else. Если вам нужно достучаться до нужных значений в месте исполнения кода(сделать аналог closure) - есть функция upvar и global.

Cris
()
Ответ на: комментарий от anonymous

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

Для "полноты ощущений" ООП ещё бы Forth не мешало бы изучить. Правда в Forth это не называют ООП, потому как ООП - лишь подмножество его возможностей:)

Led ★★★☆☆
()
Ответ на: комментарий от Cris

> Так, а что использовать? Не все же три? И что будет стандартом?

по вкусу. или оставим только один "самый правильный язык"?

Rastafarra ★★★★
()
Ответ на: комментарий от Cris

Да х з какая ниша. Но возможности впечатляют. Имхо, ИМХО, это просто Лисп, который лишили скобок, как впрочем чем то и Тикль.

anonymous
()
Ответ на: комментарий от Led

>Для "полноты ощущений" ООП ещё бы Forth не мешало бы изучить

Cмелое утверждение! Даже очень. Назвать язык, в котором один на все про все тип, ООП - это круто. Я бы додумался только до того что он скорее функциональный, по сути кастрированный и потому сверх компактный и быстрый... Лисп.

anonymous
()
Ответ на: комментарий от anonymous

>Назвать язык, в котором один на все про все тип, ООП - это круто.

Круто - это лезть обсуждать язык, совершенно его не зная. ООП на Форте делается в несколько килобайт исходников. Хочешь с динамической типизацией, хочешь со статической.

А, вот, мой JBForth - он вообще тупо работает исключительно с нативными Java-классами. И от этого не перестаёт быть Фортом.

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

>>сути кастрированный и потому сверх компактный и быстрый... Лисп.

Ну всё - хана топику...
Щас лисперы набегут и начнут рассказывать, что в лиспе в отличии от других языков все можно реализовать в 15 строчек. И так на 2000 каментов :( ...

geekkoo
()
Ответ на: комментарий от KRoN73

вы не возбуждайтесь так. я таки не сколько не против форту. за форт положил лет пять жизни. и броуди мне открыл глаза. однако форт ни разу ни ООП. все что на нем ООП - это то же ООП что и в GTK... вот и еще скажу что фообще говоря Форт на системе с выше чем 16-битной адресацией и не подшитым словарем - это вобщем палиатив. и все таки подуайте на тему что Форт - это обрезаный Лисп. я сам до этого не сразу дошел.

anonymous
()
Ответ на: комментарий от anonymous

> Добавлю. Вообще правильно Мейер назвал функциональщину вредом в числе первых. Не тратте время на функциональщину. Для "клея" самый удобный ныне это Руби.

Не тратьте времени на ООПщину. Результат будет такой же прескверный. О чём esr, кстати пишет.

fk0
()
Ответ на: комментарий от geekkoo

> Щас лисперы набегут и начнут рассказывать, что в лиспе в отличии от других языков все можно реализовать в 15 строчек. И так на 2000 каментов :(

Неа, не набегут... А я что тут делаю?! Уже ушёл! :)

yyk ★★★★★
()
Ответ на: комментарий от Rastafarra

>да ради бога. просто ООП -- это именно СМ ;)

Вы не в теме:) Просто с ST его стали так называть - ООП:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>Forth страше SmallTalk. Forth - "ровесник" С и Pascal.

и что. если вы считаете по возрасту то опять же ... старше Лиспа найдется совсем чуть. ;) Форт отличная штука для встраиваемых систем с 16-битной адресаций. Когда компактный шитый словарь умещается в килобайты. когда от процессора требуется экономичность и дешевизна, потому что для форта в минимуме нужен вообще один-единственный регистр (кстати именно поэтому выбрали для ява машины фортоподобность, чтобы можно было ее запустить вообще на любом процессоре, не упираясь в те же регистры).

anonymous
()
Ответ на: комментарий от fk0

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

anonymous
()
Ответ на: комментарий от anonymous

>если вы считаете по возрасту то опять же ... старше Лиспа найдется совсем чуть.

1) Я про Лисп не говорил и ничего против Лиспа не имею:)

2) При чём тут "древний" Лисп в контексте ООП?

>Когда компактный шитый словарь умещается в килобайты.

Вы просто не умеете его готовить:)

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

Его выбрали не столько из-за этого, а из-за простоты реализации на ЛЮБОЙ платформе (проще, чем транслятор ассемблера написать)

А вообще, про 16bit-only (в смысле практичности) - очень смешно:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>2) При чём тут "древний" Лисп в контексте ООП?

При чём тут "древний" Форт в контексте ООП?

>Его выбрали не столько из-за этого, а из-за простоты реализации на ЛЮБОЙ платформе (проще, чем транслятор ассемблера написать)

именно в отсутствии типов кроме стека эта простота и заключается но VM реализовывали не изза простоты а именно изза портабельности

>А вообще, про 16bit-only (в смысле практичности) - очень смешно:)

да не смешно! смешно что вы не понимаете смысла. когда на своем Форте вы выходите в 32 адресацию шитому коду приходит конец, если вы это не понимаете, то тогда дальше говорить нет смысла. а для всех сообщу, что в не шитом словаре форт принципиально не отличен от какой нить Сишной библиотеки. а семантически - подмножество Лиспа.

anonymous
()
Ответ на: комментарий от anonymous

>>2) При чём тут "древний" Лисп в контексте ООП?

>При чём тут "древний" Форт в контексте ООП?

При том, что ООП фактически там присутсвовал, хотя так ине назывался.

>но VM реализовывали не изза простоты а именно изза портабельности

ИМХО простота реализации == портабельность.

Led ★★★☆☆
()
Ответ на: комментарий от Led

>>>2) При чём тут "древний" Лисп в контексте ООП?

>>При чём тут "древний" Форт в контексте ООП?

>При том, что ООП фактически там присутсвовал, хотя так ине назывался.

ООП можно найти и в Лиспе и как видите и на Си можно писать квазиООП. Вы конкретно скажите без общих слов про что вы? что именно вы считаете ООП в ФОрте?

>ИМХО простота реализации == портабельность.

офигенная логика! :)) не найдесь! я и спорить не стану! только суть в треде была о причинах фортоподобности ява-машины. и не смотря что вы в чем то и правы в этой мегалогике, а выходит простое передергивание фактов. кстати такой знак, что вы нарисовали означает эквивалентность, ну так как наоборот будет верно? :)

anonymous
()
Ответ на: комментарий от Cris

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

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

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

itcl уже мёртв.

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

fk0
()
Ответ на: комментарий от fk0

В итоге ООП в тикле нет. Может оно и правильно. Для скриптов достаточно naming conventions и namespace. И вычисления имен переменных.

geekkoo
()
Ответ на: комментарий от anonymous

>только суть в треде была о причинах фортоподобности ява-машины.

Суть в треде была о том, что неплохо бы посмотреть на ООП-подобный подход в Forth'е, по крайней мере Forth впервые AFAIR в этом топике был упомянут в этом контексте

Led ★★★☆☆
()
Ответ на: комментарий от geekkoo

>В итоге ООП в тикле нет.

В С++ тоже нет, если компилятор C++ написан на C (в котором ООП нет). И вобще - реализаций ООП на не-ООП-процессорах тоже нет:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

>>И вобще - реализаций ООП на не-ООП-процессорах тоже нет:)
Ну и что? Я только за. Кому оно нужно это ООП.

geekkoo
()
Ответ на: комментарий от Led

>Суть в треде была о том, что неплохо бы посмотреть на ООП-подобный подход в Forth'е

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

anonymous
()
Ответ на: комментарий от fk0

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

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

Так а зачем урезать xotcl? Я так кинул одним глазом, все гламурные приколы CLOS-а сделали. Зачем же резать функциональность? И тогда не понятно почему он мертв(xotcl)?

Cris
()
Ответ на: комментарий от Cris

> Так а зачем урезать xotcl? Я так кинул одним глазом, все гламурные приколы CLOS-а сделали. Зачем же резать функциональность? И тогда не понятно почему он мертв(xotcl)?

wiki.tcl.tk

fk0
()
Ответ на: комментарий от anonymous

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

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

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

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

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

> Интересно, а что же тогда делают команды global, variable ?

Связывают переменную с другим пространством имён. При чём вполне могут это проделывать и для несуществующих переменных. C[++] в этом случае выдаёт ошибку.

> для этого существуют средства типа frink http://wiki.tcl.tk/2611

Ну и хрен ли толку, если он вообще не работает толком (ибо с ним надо писать в стиле C), как, кстати и tcl-компилятор.

fk0
()
Ответ на: комментарий от fk0

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

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

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

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

>itcl уже мёртв.

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Led ★★★☆☆
()
Ответ на: комментарий от fk0

>> На собственном опыте могут сказать, что писать на нем просто и приятно. Для тех же, кто считает, что большая программа может быть написанно только с использованием ООП могу посоветовать изучить 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

anonymous
()
Ответ на: комментарий от anonymous

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

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

ero-sennin ★★
()
Ответ на: комментарий от anonymous

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

zenkov ★★★
()
9 декабря 2006 г.
Ответ на: комментарий от zenkov

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.