Состояние экосистемы Common Lisp на 2015 год

Tcl станет Lisp-ом. Только плохим, с кучей разных видов скобок. Если Tcl доживёт, это где-то будет к 3000 году. Ожидай.

Зачем же ждать 3000 год, когда уже есть такой «Lisp», который называется Clojure? :-)

Clojure — нелисп.

Clojure — нелисп

Он «Lisp» с кучей разных скобок :-) Арлекин, конечно, лучше :-)

tkinter от tcl зависит:

def _stringify(value):
    """Internal function."""
    if isinstance(value, (list, tuple)):
        if len(value) == 1:
            value = _stringify(value[0])
            if value[0] == '{':
                value = '{%s}' % value
        else:
            value = '{%s}' % _join(value)

Ну и любой вызов по именам:

self._tk.getboolean(self._tk.call(«info», «exists», self._name)):

Что здесь видим? Режим интерпретации. Даже если вызов call происходит через ffi, минуя интерпретатор tcl, всё равно разрешение имён в значения происходит при каждом вызове. А байт-компилятор tcl вполне может сделать это один раз и навсегда.

Поэтому, если ты пишешь на tk через биндинги, у тебя будет производительность никогда не лучше, чем на чистом tcl, а скорее всего, всегда хуже и намного. Байт компилятор ускорил tcl в 6 раз. Наверное, во столько же раз биндинги и сольют чистому tcl во многих случаях, где байт-компиляция реальна.

Нашёл правильную цитату-ответ:

В ней приведены неверные факты. Так что это неправильная цитата ответ. Кстати, синтаксис tcl на вид гораздо более читаем, чем у лиспа. Сравни ввод локальной переменной:

set x 5

(let ((x 5))
  ...
  )

Или хотя бы
(defmacro once-only ((&rest names) &body body) ...)

Это можно сделать, причём легко. Просто поверь :) Или заплати - я как раз с октября безработный.

Мало того, что 6 скобок, так ещё и уровень отступа.

Используй правильный лисп

(define x 5)

Это разные вещи по семантике. let - это скоуп-выражение со связыванием. set в Tcl просто долбит в текущий скоуп. Аналога let в Tcl нет.

а скорее всего, всегда хуже и намного.

Совершенно не значительно, можно не принимать эту разницу во внимание.

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

Всегда можно собрать вызов в Tcl_Obj-ы, я так изначально и планировал. Но потом решил генерировать Tcl, ибо замерил - разница не значительная оказалась.

синтаксис tcl на вид гораздо более читаем, чем у лиспа.

/0 Где 6 скобок? Вот CL:

(set 'x 5)

(def x 5)

(let [x 5] ...)

Это разные вещи по семантике.

Да. Но отступ необязателен. Можно понимать скоуп «от слова лет и вниз до закрытия текущего уровня отступа». Совсем необязательно «от слова лет, вниз и вправо до возврата на текущий уровень отступа». Очень редко бывает нужно закрыть let раньше, чем закрывается охватывающая его конструкция. Но лисперы не склонны понимать это. Я уже давно плюнул вас убеждать и в своём коде делаю как вот здесь на строке 188.

Всегда можно собрать вызов в Tcl_Obj-ы, я так изначально и планировал. Но потом решил генерировать Tcl, ибо замерил - разница не значительная оказалась.

Можно поподробнее? Сравнивал ли ты производительность сгенерированного тобой кода и производительность tcl, закачанного из файла. Т.е., допустим, у тебя есть лисповая функция, к-рая 6 раз обращается к tcl. И такая же по алгоритму функция, но написанная в виде одной команды proc. И что, ты хочешь сказать, разница незначительна?

Где 6 скобок?

Не жульничай.

Всё. Баста. Работать пора.

Можно понимать скоуп «от слова лет и вниз до закрытия текущего уровня отступа»

Все это прекрасно понимают. Совершенно очевидно, что это не let. К семантике let в Tcl будет ближе описание proc вместе с set - а это явно не короче let.

Очень редко бывает нужно закрыть let раньше, чем закрывается охватывающая его конструкция.

Ну конечно. В Tcl очень редко нужны, потому что это сделать по нормальному не возможно, только через задницу. А всем остальным для ясных и красивых вычислений конструкция let просто необходима.

Но лисперы не склонны понимать это.

Мне кажется ты переоцениваешь сложность Tcl. Что из себя представляет Tcl и как там всё делается изучается элементарно за пару вечеров и сразу же приходит понимание, что это такой кривой Lisp.

let - это скоуп-выражение со связыванием

Скоуп - это от слова «скопец»? :-) Кастрированное выражение? :-)

И что, ты хочешь сказать, разница незначительна?

Да, хочу сказать. Ведь Tcl предлагается использовать исключительно для рисование окошечек. Для всего остального - весь остальной CL, где производительность Tcl с его динамическим компилятором сольёт с подливой Common Lisp-у.

Лексическая область видимости, если угодно.

где производительность Tcl с его динамическим компилятором сольёт с подливой Common Lisp-у

В свою очередь, написать программы на Common Lisp, которая не сольёт на пару порядков программе на C++, не так то просто, если вообще возможно :-)

Лексическая область видимости, если угодно.

Угодно, сударь. Русский язык намного роднее всяких лиспов :-)

Да это я для краткости. Уж извините, стилистка это не про меня.

Сольёт, конечно сольёт. По поводу порядков - вопрос спорный. Но ведь мы используем Common Lisp далеко не performance-а ради. Просто на CL писать удобнее, быстрее и приятнее, чем на C++.

Да это я для краткости. Уж извините, стилистка это не про меня.

Дело не в стилистике. Когда ты умышленно стараешься выражать мысли на родном языке, ты настраиваешь свою же психику на «родной» лад. Тебе же самому, как личности, на пользу стараться выражаться красиво и на родном языке. :-)

Сам ты жулик.

Ты вообще не понял, что я хотел сказать. Смешно полагать, что я не знаю семантической разницы между let и set - можно было догадаться, что я знаю лисп и tcl чуть лучше. Значит, нужно было предположить, что я говорю о чём-то другом и постараться понять это.

Но оставим это, я вернулся из-за вопроса про скорость. Вообще-то, тут даже и вопроса нет. У меня просто нет выбора. Моя задача - это IDE для лиспа. Если tcl прилинкован через ffi, то я уже не смогу написать в этой IDE приложения для tcl, поскольку гнездо ffi для библиотеки tcl будет уже занято. Нужно, как минимум, переименовать библиотеку. Но это ещё не всё. Я столкнулся с проблемами при использовании ffi и понял, что единственный рабочий интерфейс - это сокеты. В этой ситуации понятно, что если код на tcl создан один раз - то это будет быстрее, чем передавать его каждый раз кусками по сети, а потом исполнять.

Моя задача - это IDE для лиспа.

Денис, это отлично, что кто-то хочет сделать что-то новое. Но у меня есть большие сомнения, что кто-то захочет переходить на твою IDE со SLIME. Просто подумай, а стоит ли тратить на это время? :-)

но я уже не смогу написать в этой IDE приложения для tcl

Почему нет? Это смотря что библиотека предоставляет. Я вот проектирую так, что создания Tcl интерпретаторов в образе Lisp доступен через публичный интерфейс. При необходимости возможно выполнять Tcl код как с использованием sexprs->tcl eDSL-а, так и raw Tcl скрипты.

Смешно полагать, что я не знаю семантической разницы между let и set - можно было догадаться, что я знаю лисп и tcl чуть лучше.

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

Я столкнулся с проблемами при использовании ffi и понял, что единственный рабочий интерфейс - это сокеты.

Не правильно понял. Не нужны никакие IPC, Tcl прекрасно встраивается с любыми последующими плясками.

Если уж хочется упростить let, то проще чем сделали в Clojure не сделать. В Clojure, кстати, ещё и деструктуризация зашита в let.

Денис, это отлично, что кто-то хочет сделать что-то новое. Но у
меня есть большие сомнения, что кто-то захочет переходить на твою
IDE со SLIME. Просто подумай, а стоит ли тратить на это время? :-)

Обычно в дискуссии с анонимусами не вступаю, но тут прямо волшебство.

Как раз 2 минуты назад вспомнил, что вывод на рефлексию - это одна из форм агрессии. И что нужно уметь распознать и отразить эту агрессию. Научил меня этому Конюхов. В его книжке написано, что если ты идёшь в кругосветное плавание, то рефлексия - это второй этап падения духа. Первый я забыл. Но состояние рефлексии уже очень опасно. Путешественник начинает думать «а зачем мне вообще нужно кругосветное плавание»? Отсюда уже шаг до слива, а может быть, и до смерти, если это, скажем, одиночная кругосветка в высоких южных широтах. И я даже вспомнил одного друга, который, зная НЛП, регулярно пытался и до сих пор пытается вывести меня на рефлексию с целью управления мной. Тут я вижу тоже такой паттёрн. Я надеюсь, это не он, но если это и он, то не выйдет ничего :)

Вспомнив это две минуты назад, я испугался, что я забуду этот урок. Но спасибо, ты мне это напомнил доходчиво.

Не захочет переходить - не надо. «Через время появятся новые люди» (C).

Не правильно понял.

Жду твои пулл реквесты.

При необходимости возможно выполнять Tcl код как с использованием >sexprs->tcl eDSL-а, так и raw Tcl скрипты.

Моё мнение - такой DSL не нужен. Это не просто мнение. Это мнение, основанное на практике.

Где ждёшь? :) Я занят написанием frontend-а поверх Tcl/Tk. Конкретно в существовании новой Lisp IDE не заинтересован, хотя допускаю, что это вполне полезное действо для сообщества. Пиши. Посмотрим что из этого выйдет.

Ну я имею обратное мнение. Тоже основанное на практике. На опыте программирования на Tcl. sexpr->tcl нужен мне минимум как прослойка для реализации. Что бы строчки не долбить, как в Ltk.

Вспомнив это две минуты назад, я испугался, что я забуду этот урок. Но спасибо, ты мне это напомнил доходчиво.

Не пугайся. :-) Стойкость духа есть, значит, что-то сотворишь. Удачи :-)

Если уж хочется упростить let, то проще чем сделали в Clojure не сделать

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

Здесь у меня есть окончательное мнение, не требующее обсуждений: в лиспе плохой синтаксис. В clojure тоже. Обычно я начинаю обсуждать и спорить, когда в чём-то не совсем уверен. Оружие быстрее всего разрабатывается во время войны.

А здесь я знаю уже давно: синтаксис лиспа плох. Чтобы это доказать, нужно понимать, как человек видит, понимать азы теории информации. Привлечь понятия «система координат» и «опорная точка». Практика показывает, что здесь ничейная земля и я не могу никому ничего доказать. Я это уже пробовал на страницах этого форума, но сдался.

Давай посмотрим поверх ситуации: почему количество современных проектов, используемых повседневно, на лиспе, так мало? Может же быть тому какая-то объективная причина кроме AI Winter, маркетинговых раскладов и всемирного заговора? А почему при этом tk широко используется?

Давай свернём эту тему. Если тебе больше интересна моя точка зрения, чем уличить меня в плохих сравнениях или незнаниях, то посмотри, на что я дал ссылку, осознай и задай вопросы, если они останутся. А если тебе интереснее меня уличить, то уже можно радоваться - уличил.

Ну я имею обратное мнение. Тоже основанное на практике. На опыте программирования на Tcl

Сколько кода, написанного на tcl через твою обёртку внедрено и решает задачи реального мира? Я написал с применением лисповой обёртки около мегабайта кода на SQL и этот код внедрён в двух проектах. Сначала я писал его через S-выражения. Но дело пошло на лад только после того, как я их выкинул и заменил строчками.

А почему при этом tk широко используется?

Я бы даже сказал - доминирует.

Давай посмотрим поверх ситуации: почему количество современных проектов, используемых повседневно, на лиспе, так мало? Может же быть тому какая-то объективная причина кроме AI Winter, маркетинговых раскладов и всемирного заговора? А почему при этом tk широко используется?

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

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

Вопрос специфики задачи. Я не представляю hu.dwim.perec или аналог той же мощности на строках, так как там надо генерировать SQL по семантике запроса. А если 90% того SQL — именно код на SQL со сложной логикой, то проще сразу текстом. Также как и с HTML.

А почему при этом tk широко используется?

Visual Basic ещё более широко. По той же причине.

А здесь я знаю уже давно: синтаксис лиспа плох. Чтобы это доказать, нужно понимать, как человек видит, понимать азы теории информации. Привлечь понятия «система координат» и «опорная точка». Практика показывает, что здесь ничейная земля и я не могу никому ничего доказать. Я это уже пробовал на страницах этого форума, но сдался.

Можно ссылку на доказательство? Или может оно где-то оформлено в виде статьи?

Можно ссылку на доказательство?

Извини, нельзя. Я писал на этом форуме много всего, теперь не найду уже, да тебя оно и не убедит.

Сколько кода, написанного на tcl через твою обёртку внедрено и решает задачи реального мира?

Ни сколько. Я ещё не выложил исходники в открытый доступ ещё.

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

А причём тут S-expressions? В чём заключалась проблема? Мне кажется, тут речь идёт о Plain SQL vs ORM or SQL-constructor.

А здесь я знаю уже давно: синтаксис лиспа плох. Чтобы это доказать, нужно понимать, как человек видит, понимать азы теории информации. Привлечь понятия «система координат» и «опорная точка». Практика показывает, что здесь ничейная земля и я не могу никому ничего доказать. Я это уже пробовал на страницах этого форума, но сдался.

А в чём проблема? Не нравится S-expressions? Не используй Lisp, пиши на каком-нибудь Tcl, раз тебе удобнее. Вот, например, пишешь ты Lisp IDE... Зачем? Раз Lisp так плох, пиши лучше IDE для Tcl и на Tcl :)

А причём тут S-expressions?

Если ошибка в сложном SQL выражении. то сообщение об ошибке трудней понять. На s-выражения плохо ложится create procedure.

теперь не найду уже, да тебя оно и не убедит

Жаль. Мне просто интересна точка зрения. До сих пор я думал (и пока продолжаю), что удобство синтаксиса — исключительно субъективный вопрос. Всё равно, что выяснять, удобней написать мысль по-арабски, по-русски или по-китайски.