Почему Столлман не любит Tcl?

Ну, да, прикольно. Но просветления не наступает. ЧЯДНТ?

Ну, может оно тебе и не надо? Разные люди по разному оценивают «плюшки» лиспа (говорю лисп, имею в виду CL): кто-то торчит от интерактива, замены кода «на лету», возможности легко писать «сверху вниз»; иных привлекают макросы - они не делают _весь_ код меньше (скажем так - не всегда), но код их использующий может сокращаться кардинально, и не всегда это можно красиво решить функциями.

Сужу по себе: использование макр довольно сильно (и быстро) «привязывает» к лиспу - гомоиконный синтаксис позволяет как никакой другой оперировать кодом (после него на макры раста/немерле не взглянуть без содрогания), и спустя короткое время на недостатки этого самого синтаксиса уже не обращаешь ни малейшего внимания.

Ну, может оно тебе и не надо? Разные люди по разному оценивают «плюшки» лиспа

Какой же это дзен?

Сужу по себе: использование макр довольно сильно (и быстро) «привязывает» к лиспу

Вот! Дай совет как прочувствовать эти лисповые плюшки? Пока что вот я пишу код - с виду никаких преимуществ особых не вижу. Только синтаксис необычный.

Столлман высказался в духе, что Tcl не подходит для больших проектов. Если прочесть критику полностью(а это достаточно известный holywar), то ясно что Tcl для него - средоточие контекстно-зависимых языков и свободных грамматик. Как фанату лиспа ему немного обидно что есть язык даже в теории более гибкий. Он (да и многие сейчас) кстати тогда так и недопёр, что lisp и tcl, несмотря на всю похожесть принципиально разные языки и их сравнивать всё равно что кислое с мягким.

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

зы. Вести проекты с Tcl действительно 'внезапно' сложно ;-) Серьёзное использование Tcl подразумевает создание собственного языка, максимально удобного для разработчика и конкретной задачи.

А чтобы 'язык' всех частей проекта был одинаково понятен всем - сами разработчики должны быть примерно одинаковой(высокой) квалификации и проект должен вестись централизованно и жёстко. Можно сказать Тикль максимально гибок и лёгок в использовании и столь же строг в ведении проектов.

Дай совет как прочувствовать эти лисповые плюшки?

:) код писать. Потом лезть на разные форумы и спрашивать - что за фигня у тебя получилась. Если повезёт - расскажут. С макрами (плохой совет): как только увидел несколько похожих блоков кода в программе - сразу пиши макрос на это дело (похожих - не значит одинаковых, одинаковый код можно засунуть в инлайн-функции). Конечно - slime.

Но гарантировать успех я не буду :)

неосилятор вульгарис )
много писанины при отсутствии знания матчасти,
и как мининум нет понятухи о существовании tclx и fileevent.

принципиально разные языки и их сравнивать всё равно что кислое с мягким.

Очень интересная мысль (серьезно!), никогда ничего подобного не слышал.

Уделите, пожалуйста, минутку внимания «заблудшим», объясните, в чем принципиальная разница? В интерпретируемости? Тогда, мб, стоит сравнить tcl со старыми лиспами, и маргинальными, вроде picolisp?

ИЧСХ, тикль успешно применяется суровым ънтрпрайзом для задач автоматизации. А вот лисп и ныне там.

а что общего ?
кроме мнения нахальных и назойливых персон для коих все из лиспа вылезло )

Уделите, пожалуйста, минутку внимания «заблудшим», объясните, в чем принципиальная разница?

это разные классы языков. См: классификация Хомского.

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

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

ни ухом и не рылом не похож на своего, типа, предка

строки ~= списки

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

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

Не , было бы смешно каждый раз при описании автомобиля читать о конных повозках и колесницах римской империи.
Или, например, историю появления типов в Си и всех ЯП с типами
и кто кому там Рабинович.
А вот строка и Тcl .... о, это всегда нечто особое. Понять простоту Tcl и без упоминания лиспа тут ну никак не выходит. Забавно ...

http://en.wikipedia.org/wiki/Homoiconicity#Examples

:) код писать

дык вот как-то и получается, что реальный код пишу на java, а всякие лиспы - just for fun... :(

Или Хаскелль, если решил к тёмной стороне примкнуть

Почему хаскель - тёмная сторона? :)

Наверное нети времени от конкретной работы, не ?)

Какая работа на пенсии-то?

Я тоже категорически против Tcl хотя бы за богомерзкий Tk тулкит, который отравляет прекрасный мир поделиями на его базе.

Ну попробуй на тикле без костылей реализовать работу с дочерними процессами и или асинхронный ввод-вывод

открой для себя мир: expect - классическое средство и удобный инструмент для «работы с дочерними процессами и или асинхронного ввода-вывода», всего-лишь библиотека Tcl

чую я равновесие Толщины пошатнулась при словах этих!

проиграл в голос

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

Но по копирастическим и прочим зондовым соображениям. В Tcl разве зонды есть?

Ну на официальном сайте для Windows рекомендуют Active Tcl, которое проприетарное. И лицензия Tcl BSD-like.

Это те машины, которые стоили овердожопы,

Да нормально они стоили. Как все машины до-PC эры, с полным циклом разработки (своё железо, своя ось, свой тулчейн, своё производство). PC всех убил, последним KSR был.

к тому же имели обкромсанный в говно лисп без всяких мегаГЦ,

ГЦ был в микрокоде.

сливали всему, что только можно и были тотальным говном? И сдохли в адских муках?

Нет, такие лисп-машины человечеству неизвестны.

Знатно тебе скобки анус разбарабанили, раз такой кислотный баттхёрт прёт.

Но просветления не наступает. ЧЯДНТ?

Без практического опыта просветление не придёт. Когда что-то серьёзное пишешь, тыщ хотя бы на несколько строк.

Без практического опыта просветление не придёт. Когда что-то серьёзное пишешь, тыщ хотя бы на несколько строк.

В этом и проблема.
На работе - java.
Смотришь вакансии - php/java/c#/ruby/python/c(pp) и тп.
Вот толком ни разу не видел вакансию по CL/Scheme/Racket/Haskell/Clojure. Мало их.
Какого-то популярного крутого софта на этих ЯП - тоже мало.
Т.е. получается, что штука вроде и крутая, и дзен, и все такое...но далека от реального мира. Может, конечно, это просто я чего-то не понимаю.
Поэтому, например, и начал изучать Clojure - он как-то ближе всех к enterprise, да и к java. Но, пока что, все равно не понял фишки этих ваших лиспов.
Ну, надеюсь, чуть позже все-таки пойму. Просто текущая ситуация с лиспами лично для меня является довольно сильным демотиватором. Если проще, то часто возникают мысли «А зачем я изучаю то, что никому не нужно?».

к тому же имели обкромсанный в говно лисп

Нормальный там лисп был, на ютубе есть демки.

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

Нормальный там лисп был, на ютубе есть демки.

Да лисп там вообще супер был! На одном из лисп митингов показывали отладку бага в компоненте операционки, там просто по трапу в дебаггер вывалились, где лисповый сорец наживую поправили и полетели дальше.

В МТИ, кстати, до сих пор одна лисп-машина крутится, какой-то сервис раздаёт.

Ну, может быть, спорить не буду. Лисп мне самому нравится, просто пока не вкурил особо - пока только учу.

Лисп нужен, как гимнастика для ума. Практического применения фактически не имеет. Он как латынь - на латинском можно такие смыслы подымать, но людям надо чего попроще. Наука кстати за латынь очень долго цеплялась, но тоже отправила на свалку, так и лисп туда в конце концов попадёт. Языки идут от сложного к простому.

ИЧСХ, тикль успешно применяется суровым ънтрпрайзом для задач автоматизации

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

Практического применения фактически не имеет.

Ой бяда, бяда. Коммерческим вендорам пилящим реализации LispWorks и Allegro CL нужно быстро переквалифицироваться, а кастомерам переходить на то, что одобрено местными «икспертами-кукаретиками».

Языки идут от сложного к простому.

Проще лиспа только лисп, ога. Если уж «погромист» лисп не может осилить, пускай лучше дворы подметает, и то пользы больше будет.

Челябинским, штоле?

Не, в лучших европейских домах котируют, инфа соточка

неосилятор вульгарис ) много писанины при отсутствии знания матчасти,

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

Типичный борщевистский подход: вместо того, чтобы пользоваться инструментом, дрочить на знание матчасти и осиляторство. Ты осилил библиотеку TCL, молодец. А я просто взял и написал код на руби, который будет в 4 раза короче и не требует еще одного такого же папки-осилятора для сопровождения.

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

    if {[catch {fconfigure $channel -mode}]} {
        # $channel is not a terminal
    } else {
        # $channel is a terminal
    }

и как мининум нет понятухи о существовании tclx и fileevent.

Настолько мощный язык, что пришлось настрогать дополнительных расширений, чтобы на нём можно было писать ХОТЬ ЧТО-НИБУДЬ практически полезное. Во-первых.

Во-вторых, даже эти расширения писать код не через жопу всё равно не позволяют. Понятные цитатки для осиляторов матчасти:

Note that exec and open will automatically reap the zombies they create with repeated use; there is no guarantee that you will be able to manually wait for the processes they create.

Fork will apparently not work unless threads are disabled when building TCL.

Спасибо, жрите сами.

открой для себя мир: expect - классическое средство и удобный инструмент для «работы с дочерними процессами и или асинхронного ввода-вывода», всего-лишь библиотека Tcl

См.: Почему Столлман не любит Tcl? (комментарий)

Но поскольку ты разговариваешь нормально, в отличие от предыдущего оратора, то тебе я отвечу тоже нормально. Всё это я уже давно открывал, и к выводам пришел однозначным: какое-либо проектирование и системный подход а API тикля начисто отсутствуют. Библиотеки пишутся по принципу php: что в голову пришло, то и накалякали. Отсутствует системность в наборах функций, отсутствует ортогональность компонент интерфейса. Зато присутствует куча оговорок и обходных путей, которые можно получить только тщательно шерстя tcl wiki и гугл. И поэтому затраты времени и труда для написания кода на тикле непомерно велики по сравнению с конкурентами, способными предоставить более простые средства автоматизации.

И поэтому же невозможно использовать это в команде разработчиков. Средний разработчик, имеющий бэкграунд в юниксе и предметной области, сходу въезжает в код, например, на питоне или руби, потому что там всё делается именно так, как и можно это ожидать с учётом его опыта. В случае тикля каждому новому разработчику надо пройти спецкурс «стандартный набор костылей, который вы должны изучить, чтобы понимать, как писать код в нашем проекте». Понятно, что такой вариант ну совсем не катит.

У меня есть опыт вхождения «резко в руби с нуля» и «резко в tcl с нуля» - и я могу сказать, что они отличаются как небо и земля. Под «резко с нуля» я имею ввиду «знакомтсво с языком есть, но опыта еще нет, и стандартные библиотечные вызовые еще не выучены». Так вот, чтобы писать на ruby, кроме встроенного справочника классов и методов (ri) не надо ВООБЩЕ НИЧЕГО. Нужна фича? Вбиваешь ключевое слово, с вероятностью в 90% попадаешь на страницу нужного метода, читаешь, используешь. Всё. Этим «вхождение» в API и заканчивается. Стандартная библиотека настолько грамотно спроектировано, что вопрос «какого хрена всё так по-идиотски?» не возникает никогда.

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

Наглядный пример:

ну это наглядный пример не работающей соображалки у тебя
и познаний наскока

ХОТЬ ЧТО-НИБУДЬ

какой занятный тип ))

ну это наглядный пример не работающей соображалки у тебя
и познаний наскока

А давай ты перестанешь пускать пузыри и попробуешь своё якобы имеющееся мнение как-нибудь аргуметировать?

Ну или крышку за собой закрыть не забудь.

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

А вот это суть Common Lisp. Из-за которой в своё время отпочковался Scheme. В живом образе переопределяем функцию (а ещё лучше макрос) и пытаемся жить с изменённым образом. А если через месяц выяснили, что исправили не так, то ... переустанавливаем систему? Или откатываем на точку восстановления весь образ вместе с данными?

Я перешёл с Windows на Linux именно потому, что при восстановлении конфигов в /etc и ~ в исходное состояние система целиком начинает работать так как работала. В Windows-же каждая операция — петля гистерезиса — нельзя войти в одну реку дважды. Так вот в Lisp-машине всё ещё хуже: там вся операционная система = Lisp-образ. С возможностью пользователя влазить в абсолютно любые функции.

держи
http://www.tu-chemnitz.de/docs/tcltk/tcl8.4.0/html/TclCmd/fconfigure.htm

А давай ты перестанешь пускать пузыри и попробуешь своё якобы >имеющееся мнение как-нибудь аргуметировать?

имхо, это бесполезное занятие для меня
патологических балбесов ублажать мне облом )

вообще-то как правило не отвечаю anonymous`ам, ну да ладно :-)

Настолько мощный язык, что пришлось настрогать дополнительных расширений, чтобы на нём можно было писать ХОТЬ ЧТО-НИБУДЬ практически полезное

дык, это правильно. В tcl _нет_ стандартных библиотек. Все батарейки - исключительно внешние. В интерпретаторе - собственно язык, работа с необходимыми встроенными типами, базовый ввод/вывод, цикл событий и средства для расширения языка и подключения внешних модулей. ВСЁ. причём кое-что можно было и подсократить.

До последнего времени в tcl-core рулил здравый минимализм, в язык не вносились фичи, а в интерпретатор батарейки. Батарейки кстати сосредоточенны в tcllib - можешь считать её «стандартной» библиотекой.

У меня есть опыт вхождения «резко в руби с нуля» и «резко в tcl с нуля» - и я могу сказать, что они отличаются как небо и земля

заметил? А вот Столлман нет :-) Языки то разные. Попытка писать на tcl в стиле php ruby обречена на лютый батхёрд.

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

это вообще-то беда подготовки «средних разработчиков» - они натасканы на OO в стиле плюсов, модные шаблоны проектирования. Некоторые знакомы с ФП. И все поголовно упороты в своих знаниях :) При достаточном знакомстве с Tcl у них происходит разрыв шаблона и отвал бошки, со следующим просветлением, либо полное невосприятие Tcl

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

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

держи

держи:

$ man n fconfigure | grep tty
$ pacman -Q tcl tcllib
tcl 8.6.1-1
tcllib 1.15-2

Что и требовалось доказать: официальная документация в какой-то жопе, инфу можно найти только в гугле.

дык, это правильно. В tcl _нет_ стандартных библиотек. Все батарейки - исключительно внешние. В интерпретаторе - собственно язык, работа с необходимыми встроенными типами, базовый ввод/вывод, цикл событий и средства для расширения языка и подключения внешних модулей. ВСЁ. причём кое-что можно было и подсократить.

В tcl _есть_ стандартные библиотеки. Любое взаимодействие со средой - это уже батарейки. open, exec и всё такое. Никто ж, кроме разрабов tcl, не виноват, что в перло-питонах это взаимодействие адекватное, а в tcl - нет. Если бы tcl был исключительно freestanding интерпретатором для встраивания в приложения, то и вопросов бы не было. Однако у нас по факту есть батарейки и есть tclsh, которая не встраиваемый интерпретатор с урезанным окружением, а полноценный язык. То есть можно из posix-совместимой среды запустить код и можно этим кодом повзаимодействовать со средой. И никакого другой, альтернативной и более адекватной реализации интерфейса к операционной среде нет: жрите то, что есть, или делате батарейки сами, с нуля.

Попытка писать на tcl в стиле php ruby обречена на лютый батхёрд.

Как ты там говорил? «вообще-то как правило не отвечаю anonymous`ам?» Вообще-то я как правило не отвечаю людям, считающим, что программист обязан прогибаться под инструмент, ну да ладно.

это вообще-то беда подготовки «средних разработчиков» - они натасканы на OO в стиле плюсов, модные шаблоны проектирования. Некоторые знакомы с ФП. И все поголовно упороты в своих знаниях :) При достаточном знакомстве с Tcl у них происходит разрыв шаблона и отвал бошки, со следующим просветлением, либо полное невосприятие Tcl

Алё? Ты не заметил, мы говорим про батарейки, а не про парадигму языка? Не съезжай с темы. «Средний разработчик для *никсов» - это человек, знакомый на приличном уровне POSIX, умеющий писать sh-скрипты, понимающий, что такое сокет, пайп, дескриптор, процесс и т.п.

Это требования, абсолютно ортогональные к ООП, ФП и прочим вещам, которые касаются только ЯЗЫКА как набора синтаксических и семантических примитивов. Заметь, что я нигде не критиковал ЯЗЫК, более того, я сразу же сказал, что ЯЗЫК - хороший.

И вот этому человеку, у которого в требованиях было «разработчик под unix», а не «разработчик под непонятную ерунду», штатные батарейки tcl вместо доступа к абстракциям POSIX дают какую-то, извините, херню на костылях.

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

Это детское оправдание из разряда «во всех странах чиновники воруют». Вопрос в КОЛИЧЕСТВЕ усилий, необходимых для получения заданных РЕЗУЛЬТАТОВ. В руби или в той же кложе этот показатель намного гуманнее. Ну а дальше идут в рассчёт вполне конкретные человеко-часы разработки: стоит брать этот язык в качестве инструмента или не брать. И выходит, что не брать.

А вот Столлман нет :-)

Столлман тут ни при чем. Насколько я помню, у Столмана вызывает разрыв шаблона сама парадигма tcl по сравнению с лиспом. Еще раз: я говорю не про ЯЗЫК. Не про исполнителя. А про качество реализации батареек, чтобы исполнитель мог делать что-то полезное во внешнем мире.

http://pleac.sourceforge.net/pleac_tcl/index.html

привет. про «частицы и поле это одно и тоже»: см. статью про солитоны

Наверное это уже поздно говорить, но еду ртом едят...

И как я буду делать объединение четырех uint8_t и одного uint32_t, чтобы проще было данные передавать по SPI какому-нибудь или UART'у?

set uartstring [binary format c4i {1 2 3 4} 100500]

И поэтому затраты времени и труда для написания кода на тикле непомерно велики по сравнению с конкурентами, способными предоставить более простые средства автоматизации.

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

set toTTY [dict exists [fconfigure stdout] -mode]
puts [expr {$toTTY ? "Output goes to tty" : "Output doesn't go to tty"}]