Вышел (http://sourceforge.net/projects/tcl/files/Tcl/8.5.8/tcltk-re...) релиз Tcl/Tk 8.5.13 (http://www.tcl.tk/software/tcltk/8.5.html), динамического языка программирования, распространяемого совместно с кроссплатформенной библиотекой базовых элементов графического интерфейса. В новой версии исправлено несколько десятков ошибок и внесено несколько улучшений, из которых можно отметить:- В Tk добавлена новая реализация поддержки интерфейса Cocoa для Mac OS X, собираемая при указании опции "--enable-aqua". Поддержка реализации интерфейса на базе Carbon прекращена;
- Новые имена цветов: aqua, crimson, fuchsia, indigo, lime, olive, silver, teal;
- Поддержка имён сетевых путей в Cygwin;
- Поддержка Unicode обновлена до версии 6.2;
- Контекстные меню больше не выходят за пределы экрана;
- Устранено 7 ошибок, приводящих к крахам;
- Добавлены новые версии пакетов: msgcat 1.5.0 и http 2.7.10.URL: http://sourceforge.net/projects/tcl/
Новость: http://www.opennet.me/opennews/art.shtml?num=35290
Единственный нормальный скриптовый язык!
Если тикль — нормальный, то всё, что лучше тикля, автоматически становится хорошим языком, а всё, что хуже — плохим? Тогда хороших языков будет намного больше, чем плохих. Хреновая у вас норма.
Если тикль — нормальный, то все остальные языки просто отличные! И только Васик просто хороший.
Нет, но все остальное - дрянь.
Полностью согласен. При всех недостатках тикля, остальные ещё хуже.
Что-же вы там такого нашли нужного, чего нет в Perl или Python?
> Что-же вы там такого нашли нужного, чего нет в Perl или Python?Например, асинхронно-событийную модель? Родной графический тулкит и встроенность в оборудование cisco и БД oracle.
>> Что-же вы там такого нашли нужного, чего нет в Perl или Python?
> Например, асинхронно-событийную модель?EventMachine/Twisted не оно? если нет, я не понимаю, о чём именно речь в тикле.
> Родной графический тулкит
который удобнен в программировании, но предоставляет настолько корявый в 2012 году ux, что всё равно нужны мутные, но функциональные Gtk/Qt.
> встроенность в оборудование cisco и БД oracle.
я боюсь, что на этих двух достижениях победное шествие тикля по планете и остановилось.
>>> Что-же вы там такого нашли нужного, чего нет в Perl или Python?
>> Например, асинхронно-событийную модель?
> EventMachine/Twisted не оно? если нет, я не понимаю, о чём именно речь
> в тикле.eventmachine и twisted резко отличаются от того, что есть в тикле, хотя бы тем, что это внешние библиотеки в обоих случаях, а второе еще и целый framework (будто питон недостаточно тормозит и без этого). Эта же функциональность есть в базовом интерпретаторе tclsh, который можно засунуть в любую эмбедовку. Тут более корректно сравнивать скорее с erlang.
>> Родной графический тулкит
> который удобнен в программировании, но предоставляет настолько корявый в 2012 году ux,
> что всё равно нужны мутные, но функциональные Gtk/Qt.В версии 8.5 многое изменилось в лучшую сторону.
>> встроенность в оборудование cisco и БД oracle.
> я боюсь, что на этих двух достижениях победное шествие тикля по планете
> и остановилось.Так же, тикль широко применяется при тестировании; большая часть тестов sqlite (как пример) написана именно на нем.
Expect изначально был на tcl и для него, существующие в данный момент биндинги к python и perl иначе чем "корявыми" назвать у меня не получается, скорость работы ниже в разы.
>> EventMachine/Twisted не оно? если нет, я не понимаю, о чём именно речь
>> в тикле.
> eventmachine и twisted резко отличаются от того, что есть в тикле, хотя
> бы тем, что это внешние библиотеки в обоих случаях, а второе
> еще и целый framework (будто питон недостаточно тормозит и без этого).это несущественно и по сути лишь разные модели дистрибьюции рантайма.
> Эта же функциональность есть в базовом интерпретаторе tclsh, который можно засунуть
> в любую эмбедовку. Тут более корректно сравнивать скорее с erlang.а вот это уже интереснее. в цисках тоже работает? в ora-tcl?
>> который удобнен в программировании, но предоставляет настолько корявый в 2012 году ux,
>> что всё равно нужны мутные, но функциональные Gtk/Qt.
> В версии 8.5 многое изменилось в лучшую сторону.смотрел, не впечатлён.
>>> встроенность в оборудование cisco и БД oracle.
>> я боюсь, что на этих двух достижениях победное шествие тикля по планете
>> и остановилось.
> Так же, тикль широко применяется при тестировании; большая часть тестов sqlite (как
> пример) написана именно на нем.
> Expect изначально был на tcl и для него, существующие в данный момент
> биндинги к python и perl иначе чем "корявыми" назвать у меня
> не получается, скорость работы ниже в разы.ну реально, десять лет назад было то же самое:
1: тикль никто не использует.
2: циска! экспект!создаётся впечатление, что кроме циски и экспекта совсем похвастать нечем и это не меняется.
впрочем, поинт про тестирование понял.
>>> EventMachine/Twisted не оно? если нет, я не понимаю, о чём именно речь
>>> в тикле.
>> eventmachine и twisted резко отличаются от того, что есть в тикле, хотя
>> бы тем, что это внешние библиотеки в обоих случаях, а второе
>> еще и целый framework (будто питон недостаточно тормозит и без этого).
> это несущественно и по сути лишь разные модели дистрибьюции рантайма.
>> Эта же функциональность есть в базовом интерпретаторе tclsh, который можно засунуть
>> в любую эмбедовку. Тут более корректно сравнивать скорее с erlang.
> а вот это уже интереснее. в цисках тоже работает? в ora-tcl?В ora-tcl не знаю, в цисках работает с некоторыми ограничениями:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/gui...
ок. итак, три ниши для использования: тестирование cli-программ (expect), циска и оракл, event loop в интерпретаторе с минимальным footprint. но при всём этом до скриптового языка общего назначения в современном мире тикль не дотягивает, занимая узкую нишу (из которой его уже теснят -- так, в качестве встроенного языка сейчас гораздо более популярно lua).ойстерхаут в своё время писал: "мы не положили ооп в тикль потому, что британские учёные не выявили положительного влияния ооп на продуктивность программиста". проблема в том, что ситуация резко меняется, когда ооп -- это не только синтаксический сахар, а ещё возможность за несколько нажатий клавиш интегрировать в свой код функциональность, написанную другим человеком. собственно, the ruby hype -- это именно про это.
я не про то, что тикль плохой. больше языков, разных и непохожих. а про то, что в нём таки есть проблемы, требующие редизайна языка. и тикль-сообщество долгие годы предпочитает их игнорировать, а не решать. как мне кажется, именно поэтому оно такое немногочисленное.
> ойстерхаут в своё время писал: "мы не положили ооп в тикль потому,
> что британские учёные не выявили положительного влияния ооп на продуктивность программиста".
> собственно, the ruby hype -- это именно про это.Как я понимаю г-на Ойстерхаута, глядя на этот сакмы hype.
он как бы ровно за то же самое ратовал (увеличение продуктивности программиста), просто со своей стороны. просто у него почему-то взлетело слабо, а у рубистов цветёт и пахнет.
> ну реально, десять лет назад было то же самое:
> 1: тикль никто не использует.
> 2: циска! экспект!Я не знаю, что было десять лет назад, но сейчас Tcl де-факто стандарт, как язык автоматизации тестирования, особенно, с средствах работы с железом. К примеру, его использует коммерческий "Communication Protocol Test Harness" (http://www.trianglemicroworks.com/documents/TH_Quick_Start_G...), и опенсорсный OpenOCD. А буквально на днях я решил посмотреть, что такое Altera Virtual JTAG (http://www.altera.com/literature/ug/ug_virtualjtag.pdf). Оказалось утилита для настройки оного, которую предлагает Altera, тоже использует Tcl (правда, я ей не пользовался, ввиду ее виндовости и желания реализовать ее фичу самостоятельно. Так что, деталей ее использования не знаю).
В общем, Tcl живет и здравствует там, где Вы даже не подозреваете ;)
> который можно засунуть в любую эмбедовку.Да ну? Ну покажите, как Вы это собираетесь сделать на "любов эмбедовке", а я посмотрю. Хотя нет, подождите, за поп-корном сбегаю.
Не знаю. у нас один профессор написал на нём морду для программы решения дифуров и расчёта ляпуновских показателей. Я бы на Питоне написал.
Сам пишу на тикле. Объективно, недостатки - маленький интерес к языку, как следствие, малое количество библиотек. Рабочую библиотеку под работу с unix domain sockets мне найти не удалось, к примеру. Библиотека работы с snmp заброшена, пришлось патчить исходники, чтобы ее собрать на современной системе и т.д. ...
http://sourceforge.net/projects/tcl-unixsockets/
snmp собирается легко, патчится одним патчем, который лежит там же в трекере. Какие проблемы?
> http://sourceforge.net/projects/tcl-unixsockets/
> snmp собирается легко, патчится одним патчем, который лежит там же в
> трекере. Какие проблемы?Какой snmp, который биндинги к net-snmp там же на sourceforge?
К сожалению, оно находится в нерабочем состоянии (возвращает через раз неправильно экранированные значения, автор на разработку забил); наиболее адекватная библиотека на данный момент это scotty (Tnm), ее вроде подпиливают ребята из flightaware на github'e. Хотя в ней я тоже нашел ряд багов.
ave, tcl/tk.
Использую tkinter. Хорошо, что залатали. Плохо, что маинтенеры дистрибутивов как обычно на это обновление забьют.
Когда запилят нормальный гуй для линукса?
Какой скриптовый язык посоветуете для изучения, чтобы можно было использовать и на винде, и в линуксе? Критерии: простота, быстрота разработки и исполнения, возможность компиляции. Спасибо всем, кто ответит без холивара.
> Критерии: простота,Bourne Shell
> быстрота разработки и исполнения,Perl
> возможность компиляции.В каком смысле "компиляции"? Возможность распространения бинарников, не распространяя исходников? Ну, у Perl'а, вроде бы, был компилятор... Но скриптовые языки на такое не рассчитаны.
Если это -- main criteria, тогда -- Java.
python, наверное."компиляцию" нельзя, можно для винды сделать .exe-файл посредством py2exe (туда кладётся интерпретатор питона и твой скрипт).
Cx-Freeze позволяет "скомпилировать" (байт-код вшит в исполняемый файл) как под линь так и под ненужные ос.
> Какой скриптовый язык посоветуете для изучения, чтобы можно было использовать и на
> винде, и в линуксе? Критерии: простота, быстрота разработки и исполнения, возможность
> компиляции. Спасибо всем, кто ответит без холивара.Без холивара не получится, сначала в совершенстве овладейте C и, пожалуй, sh. После этого поймете сами, чего именно Вам в них не хватает для эффективной работы. А дальше, пробуйте все подряд и выбирайте тот, что наиболее полно соответствует Вашим потребностям и кругу решаемых задач. Так Вы имеет возможность сохранить объективность, а не завязнуть в сиюминутной моде.
Скриптовый язык - сугубо утилитарная вещь. ИМХО, вопрос "какой", в отрвыве от задачи - некорректен. К тому же, изучить еще один язык при достаточном багаже знаний - это несложно.
> сначала в совершенстве овладейте C и, пожалуй, sh.и только через пяток лет приступите к питону и своим задачам, которые надо было решить на нём. в которых ни c, ни sh не помогут.
предвосхищаю мнение вида "си и шелл научат тебя думать как программист". ну фигня же.
>> сначала в совершенстве овладейте C и, пожалуй, sh.
> и только через пяток лет приступите к питонуЕще один фанбой-питонец? Какие еще языки знаете, на основании чего предпочтение было отдано Питону?
> и своим задачам, которые
> надо было решить на нём. в которых ни c, ни sh
> не помогут.А какие могут быть задачи у студента, который не владеет еще ни C ни sh?
> предвосхищаю мнение вида "си и шелл научат тебя думать как программист". ну
> фигня же.Не надо выдавать свою глупость за мою.
>>> сначала в совершенстве овладейте C и, пожалуй, sh.
>> и только через пяток лет приступите к питону
> Еще один фанбой-питонец?ещё один двадцатилетний типа крутой специалист?
> Какие еще языки знаете,
не меряйтесь на пустом месте пиписьками с окружающими, это может быть не в вашу пользу.
> на основании чего предпочтение было отдано Питону?
наверное, по похожим на те, которые учитывали в MIT в замене лиспа на питон в курсе общего программирования. в этом качестве питон действительно чувствует себя хорошо, очень жаль, что ваша ограниченность мешает вам понять это.
>> и своим задачам, которые
>> надо было решить на нём. в которых ни c, ни sh
>> не помогут.
> А какие могут быть задачи у студента, который не владеет еще ни
> C ни sh?формочку там простеньшкую гуишную нарисовать, например (в условиях написано, что и под винду, и под линукс). зачем для этого си и шелл вообще?
>> предвосхищаю мнение вида "си и шелл научат тебя думать как программист". ну
>> фигня же.
> Не надо выдавать свою глупость за мою.вот и договорились. си и шелл не нужны для общего обучения программированию и мешают в этом качестве.
>>>> сначала в совершенстве овладейте C и, пожалуй, sh.
>>> и только через пяток лет приступите к питону
>> Еще один фанбой-питонец?
> ещё один двадцатилетний типа крутой специалист?
>> Какие еще языки знаете,
> не меряйтесь на пустом месте пиписьками с окружающими, это может быть не
> в вашу пользу.Эту болтовню Вашу я прочитал и не считаю стоящей моих комментариев.
>> на основании чего предпочтение было отдано Питону?
> наверное, по похожим на те, которые учитывали в MIT в замене лиспа
> на питон в курсе общего программирования.Хорошая попытка уйти от ответа. Я спрашиваю о конкретно Вашем юзкейсе, и почему именно Питон оказался здесь наиболее эффективным? Свои аргументы есть?
> формочку там простеньшкую гуишную нарисовать, например (в условиях написано, что и под
> винду, и под линукс). зачем для этого си и шелл вообще?Если говорить об этом случае, то здесь Tcl/Tk здесь подходит просто отлично! Но я не уверен, что именно об этом говорил автор треда, потому и советую понять, что же он хочет и для чего.
>>> предвосхищаю мнение вида "си и шелл научат тебя думать как программист". ну
>>> фигня же.
>> Не надо выдавать свою глупость за мою.
> вот и договорились. си и шелл не нужны для общего обучения программированию
> и мешают в этом качестве.У Вас очень плохо получается читать мои мысли, а потом, на основе этого еще менее удачными получаются выводы.
>>> на основании чего предпочтение было отдано Питону?
>> наверное, по похожим на те, которые учитывали в MIT в замене лиспа
>> на питон в курсе общего программирования.
> Хорошая попытка уйти от ответа. Я спрашиваю о конкретно Вашем юзкейсе, и
> почему именно Питон оказался здесь наиболее эффективным? Свои аргументы есть?а при чём тут мой юзкейс вообще? я сам от питона ушёл и в новых проектах его не применяю. руби, эрланг, вот это всё.
однако, я действительно считаю, что это подходящий язык, с которого можно начинать учить программирование (и в т. ч. решать какие-то практические задачи). но не с сей же, даже от того же лиспа толку в этом качестве гораздо больше.
>>>> на основании чего предпочтение было отдано Питону?
>>> наверное, по похожим на те, которые учитывали в MIT в замене лиспа
>>> на питон в курсе общего программирования.
>> Хорошая попытка уйти от ответа. Я спрашиваю о конкретно Вашем юзкейсе, и
>> почему именно Питон оказался здесь наиболее эффективным? Свои аргументы есть?
> а при чём тут мой юзкейс вообще?А притом, что скриптовый язык - вещь утилитарная. Притом, если можно применить какой-то скриптовый язык, то, скорее всего, можно применить и некий другой, а значит, есть выбор. Тогда встает вопрос, а почему именно этот?
К примеру если это язык "который я лучше всего знаю" - это, согласен, весьма веский аргумент. Если это язык "который используют все" - это тоже аргумент, но достаточно слабый.
> я сам от питона ушёл
> и в новых проектах его не применяю. руби, эрланг, вот это
> всё.Руби? Кстати (это не троллинг, я не в курсе) он где-нибудь за пределами web-программирования используется?
К слову о юзкейсах... если бы мне надо было заняться веб-программированием, я бы перешел именно на этот язык, углубив свои знания в нем. Но, как не странно, не на Питон и не на PHP.
> но
> не с сей же, даже от того же лиспа толку в
> этом качестве гораздо больше.Это почему же не Сей? Для того же Лиспа нужна соответствующая математическая подготовка, иначе многое будет казаться слишком усложненным и надуманным.
> А притом, что скриптовый язык - вещь утилитарная. Притом, если можно применить
> какой-то скриптовый язык, то, скорее всего, можно применить и некий другой,
> а значит, есть выбор. Тогда встает вопрос, а почему именно этот?грубо говоря, основной выбор скриптового кросс-платформенного языка (sh отпадает, ага) сегодня: tcl, perl, python, ruby. в дальнейшей востребованности первого и второго я немного сомневаюсь, поэтому выбор из оставшихся. из этих двух ruby приятнее для программиста, но python проще и полезнее для обучения. вот и вся цепочка рассуждений.
> Руби? Кстати (это не троллинг, я не в курсе) он где-нибудь за
> пределами web-программирования используется?для той же автоматизации. например, распространённые configuration management systems (infrastructure as code которые) сейчас на практике -- это три наименования: chef, puppet, cfengine -- две из них на руби, одна на сях. ну, или фреймворк для автоматизации через ssh по имени capistrano.
в принципе, на руби можно писать всё то же, что и на перле или питоне, принципиальной разницы нет. плюс очень активное комьюнити, большое количество библиотек, продуманная инфраструктура их использования. вполне себе скриптовый язык общего назначения.
>> но не с сей же, даже от того же лиспа толку в
>> этом качестве гораздо больше.
> Это почему же не Сей? Для того же Лиспа нужна соответствующая математическая
> подготовка, иначе многое будет казаться слишком усложненным и надуманным.да нет там никакой математики. он просто учит мыслить не только императивно, но и функционально. и именно это полезно.
а си -- это низкоуровневый язык со своими ньюансами, которые высокоуровнему программисту, да и просто "программирующему пользователю" ну совсем не нужны и не помогут. для освоения программирования вообще более важно сосредотачиваться на задаче "не писать на низком уровне, когда это не надо" (ещё раз пламенный привет ойстерхауту, немало про это написавшему) и меньше -- на ощущении того, что "низкоуровневое программирование это основа основ".
>> А притом, что скриптовый язык - вещь утилитарная. Притом, если можно применить
>> какой-то скриптовый язык, то, скорее всего, можно применить и некий другой,
>> а значит, есть выбор. Тогда встает вопрос, а почему именно этот?
> грубо говоря, основной выбор скриптового кросс-платформенного языка (sh отпадает, ага)
> сегодня: tcl, perl, python, ruby. в дальнейшей востребованности первого и второго
> я немного сомневаюсь, поэтому выбор из оставшихся.Как я понимаю, sh отпадает из-за своей некроссплатформенности? Ну да бог с ним, это очень просто и очевидное решение для облегчения труда unix-пользователя. Если что-либо надо автоматизировать - знание его придет само собой. Tcl я люблю как раз за простоту sh, вкупе с возможностями "взрослого" скриптового языка, будь то perl или ruby.
В одном из постов выше я отписался, где Tcl прочно держит свои позиции и не собирается их никому сдавать. Об остальных случаях - можно еще поспорить. Если приложение утилитарное, если, например, нужно набрасать простую визуализацию какой-нибудь хрени с помощью Tk (например, мы так тестировали работу передатчика), или выборку из базы данных с последующей обработкой, не требующей числодробительных операций, то Tcl подходит идеально.
Если нет... то спрашивается, а нафига вообще нужен скриптовый? Не будет ли более эффективным и простым решением использовать нормальный высокоуровневый язык, будь то C (если нужна производительность) или Java (если нужен гуй), или тот же Erlang (если уровень подготовки позволяет)?
> из этих двух ruby
> приятнее для программиста, но python проще и полезнее для обучения. вот
> и вся цепочка рассуждений.Ruby, конечно, красивый язык, не получается ли это из пушки по воробьям? Не вносит ли он лишних сущностей туда, где все должно быть просто?
> для той же автоматизации. например, распространённые configuration management systems
> (infrastructure as code которые) сейчас на практике -- это три наименования:
> chef, puppet, cfengine -- две из них на руби, одна на
> сях. ну, или фреймворк для автоматизации через ssh по имени capistrano.Не в курсе, что это за хреновина. Добавил к себе в заметки - посмотрю на досуге.
> в принципе, на руби можно писать всё то же, что и на
> перле или питоне, принципиальной разницы нет.В общем, как и на тикле ;)
> плюс очень активное комьюнити, большое
> количество библиотек, продуманная инфраструктура их использования.Увы :( Но тут, к слову, вне конкуренции именно Perl. ИМХО, это его самая сильная черта.
>>> но не с сей же, даже от того же лиспа толку в
>>> этом качестве гораздо больше.
>> Это почему же не Сей? Для того же Лиспа нужна соответствующая математическая
>> подготовка, иначе многое будет казаться слишком усложненным и надуманным.
> да нет там никакой математики. он просто учит мыслить не только императивно,
> но и функционально. и именно это полезно.
> а си -- это низкоуровневый язык со своими ньюансами, которые высокоуровнему программисту,
> да и просто "программирующему пользователю" ну совсем не нужны и не
> помогут.Нет никакой математики? А Вы попробуйте, объясните первокурснику, что значит мыслить иначе, что такое выводимость, грамматики. В то же время, что такое память, указатели, разыменование - можно показать на пальцах и листочке в клеточку, даже у меня получалось это сделать.
> для освоения программирования вообще более важно сосредотачиваться на задаче
> "не писать на низком уровне, когда это не надо" (ещё раз
> пламенный привет ойстерхауту, немало про это написавшему) и меньше -- на
> ощущении того, что "низкоуровневое программирование это основа основ".Если человек не программист и не собирается им быть... черт его знает, что ему лучше изучать, это вопрос не ко мне... :(
> Ruby, конечно, красивый язык, не получается ли это из пушки по воробьям?
> Не вносит ли он лишних сущностей туда, где все должно быть
> просто?это удачный язык для того, чтобы быстро и с удовольствием что-то написать. код пишется без лишних сущностей, но интерпретатору приходится разруливать всё вот это ооп, что может быть неторопливо в выполнении.
>> плюс очень активное комьюнити, большое
>> количество библиотек, продуманная инфраструктура их использования.
> Увы :( Но тут, к слову, вне конкуренции именно Perl. ИМХО, это
> его самая сильная черта.как человек, пишущий на perl года с 98-99, не могу с вами согласиться. perl был в этой роли, но начал активно сдавать позиции. в первую очередь, из-за невнятных перспектив долгостроя под названием perl 6.
bundler в руби просто офигенен, я не уступающих аналогов реально не знаю.
> Какой скриптовый язык посоветуете для изучения, чтобы можно было использовать и на
> винде, и в линуксе? Критерии: простота, быстрота разработки и исполнения, возможность
> компиляции. Спасибо всем, кто ответит без холивара.Tcl/Tk. Всем указанным критериям соответствует, компилятор имеется коммерческий, TclPro.
> Какой скриптовый язык посоветуете для изучения, чтобы можно было использовать и на винде, и в линуксе? Критерии: простота, быстрота разработки и исполнения, возможность компиляции. Спасибо всем, кто ответит без холивара.Без холивара:
Любой.
Простота - субъективна, куда проще писать на языке, который знаешь, чем который не знаешь.
быстрота разработки - во многом пункт 1.
быстрота исполнения - условно, любой скриптовый язык обеспечивает достаточную для своих задач скорость. Не достаточна - значит "use asm, luke".
возможность компиляции - это в данном случае не аргумент. Скриптовый язык на то и скриптовый, чтобы не компилировать :) Если нужно распространять софт, то гораздо вернее либо включить зависимость в пакет, либо исполняемый файл интерпретатора (статически слинкованный).Ну и немного холивара напоследок:
Единственное, что начинать изучать РНР я бы не советовал. Это будет зря потраченное время. Проверено на себе :)