[?]библиотеки для написания dsl на python

> И, в любом случае, даже если процессор стал быстрее, интерпретатор Tcl быстрее точно не стал.

Угу, nop -ы добавляют чтобы не обогнать пистон ))

> Закон Мура гласит не это.

Ну как-то ж связан с производительностью CPU ?

> nop -ы добавляют чтобы не обогнать пистон ))

Вот насчет того, чтобы обогнать Питон, Тиклю беспокоится точно не надо.

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

А это не цель.
И кстати , за это отдельный респект им.
Гонщики уже дано бы накормили всех нестабильностью и дурными рекордами.

>> Закон Мура гласит не это.

Ну как-то ж связан с производительностью CPU ?

Он связан с числом элементов на ИС. Увеличения непосредственно скорости он не обещает.

> А это не цель.

Ну да, цель - ни в коем случае не обогнать Питон. Если надо - вставлять в интерпретатор nop'ы.

> А можно сделать так, чтобы emerge не тормозил безбожно?

Можно. Предвосхищая вопрос «как»: так же, как всегда ускоряют тормозящие программы - профилирование, поиск узких мест, изменение внутренних алгоритмов и структур данных.

Хотя , происходит по факту.

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

Сбалансированность - это ключевой смысл понимания tcl + tk.

when ... do ... and do... - вот это говно.

Будь любезен развить мысль подробнее.

Он нарушает homoiconicity

(defmacro foo-loop ((var from to) form)
  `(loop :for ,var :from ,from :to ,to
         ,@form))

(defmacro foo-iter ((var from to) form)
  `(iter (for ,var from ,from to ,to)
         ,form))

(foo-loop (i 1 10) (:if (evenp i) :collect i :else :collect (/ i 2)))
;=> (1/2 2 3/2 4 5/2 6 7/2 8 9/2 10)

(foo-iter (i 1 10) (if (evenp i) (collect i) (collect (/ i 2))))
;=> (1/2 2 3/2 4 5/2 6 7/2 8 9/2 10)

LOOP делался как навороченный DSL для обработки последовательностей, но при этом совсем не дружит с окружающим его CL кодом, а я не хочу писать на loop-dsl, я хочу писать на лиспе.

Хотя iterate тоже не сахар, т.е. наоборот - тоже с лишним сахаром :)

А есть пример пакетного менеджера написанного на тикле? Чтобы можно было сравнить с питоновским emerge по скорости.

КЛ (в редакции sbcl) --- самый быстрый из высокоуровневых языков.

Сейчас КЛ находится в выигрышном относительно хаскеля положении: больше сообщество, больше библиотек, лучшие компиляторы, etc.

^ лучшие компиляторы

А ты почему так говоришь? На основании чего?

> Сбалансированность - это ключевой смысл понимания tcl + tk.

Что такого есть в tcl/tk, чего нет в питоне? В перле? В Scheme?

> Что такого есть в tcl/tk, чего нет в питоне? В перле? В Scheme?

По сравнению с питоном и перлом, интерпретатор более компактный и легче встраивается.

встречал в OpenACS такое, но это специфичная штука.
а так, лепил на tcl аналог wajig для себя, может и продолжу ))

> По сравнению с питоном и перлом, интерпретатор более компактный и легче встраивается.

ОК, а для программиста? Есть ли хоть одна причина предпочесть питон tcl/tk?

средства для метапрограммирования. зайдите на wiki.tcl.tk и введите в поиск «playing with». там будут примеры имитации на тикле синтаксиса форта, эрланга, брейнфака, лиспа и еще много всего

> а для программиста? Есть ли хоть одна причина предпочесть питон tcl/tk?

Нет. Самая интересная полезная часть Tcl/Tk, собственно Tk, доступен и в Питоне (правда, используется очень редко). Для прогера Python предоставляет всё то же, что и Tcl (и много чего еще), но в более привычном синтаксисе, ну и плюс готовые библиотеки для почти всего.

это по мелочам набирается )
на вскидку:
1. все просто, но есть и несколько инкарнаций OO, это ненавязчиво и ваш выбор.
2. стабильно и стабильный api, есть сильные шансы что ваш код будет работать долго и на многих платформах. Я это ценю особо.))
3. доставка и консервирование программ в метакитах. это уникально для tcl. Хотя, по идее, должно быть быстрее востребовано в python .
4. хорошая интеграция с С приводит к удачным биндингам.
5. встроенные защищенные интерпреторы.
6. нет проблем с юникодам.
7. встроенные сетевые возможности.
8. механизм обработки событий.
9. легкое расширение команд основного интерпретатора.

скорости ввода/вывода? :) обратиться к БД за зависимостями?

а еще я ношу спортштаны. тренируй бег, шпециалист.

немного о расширениях tcl (хотя я уже затрагивал это)
1. Это разумеется это Tk. связка tcl+tk беспрецедентно лаконична и компактна.
Драматически экономит время и нервы на создание GUI.
И все вместе занимает порядка ~1 Мб.

2. tcllib & tklib - набор вспомогательных плюшек на многие случаи жизни.
Все возможности тут не раскрыты и до сих пор.
Как пример /usr/bin/dtplite - Lightweight DocTools Markup Processor
Уверен, что никто не знает об этом.))

3. tclx - полезные расширения для лучшей интеграции с базовой OS.
tclx вошел в tcl 8.5 на постоянной основе.


4 Expect - автоматизация интерактивных процессов

5 xotl - OO расширение tcl, и послужившее прототипом для встроенного OO
в tcl 8.6. Т.о., tcl 8.6 уже будет ЯП с ОО в коробочном варианте.
Реализация OO в tcl 8.6 уже перекрывает возможности python.
----------------

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

> практический вопрос. А можно сделать так, чтобы emerge не тормозил безбожно? Ну или хотя бы тормозил в рамках приличий.

можно. Там тормозит в основном что: перебор файлов с ебилдами, мира /var/lib/portage/world/var/lib/portage/world и файлов в профиле + раскрытие переменных вроде USE-флагов, заданных в /etc/make.conf.
То есть, задача в основном IO-bound. Если сравнить по скорости emerge -vuDNp world / paludis -ip world видно, что палудис, хотя написан на С++ несильно-то по скорости и быстрее.
То есть, надо ускорять чтение с диска. Простой трюк с squashfs + aufs2 образом, где хранится /usr/portage + /usr/local/portage/layman (дистфайлы выносим за /usr/portage) — сильно ускоряет emerge. В squashfs хранится образ read-only с предыдущего синка, aufs2 оверлей смонтирован в read-write поверх него. Потом как-то при выключении или по крону раз часов в 4-8 rw образ сливается с ro и делается новый ro образ. В общем-то, если синка не было, образ может и не изменится.
paludis vs. emerge: paludis ещё ловит больше ошибок в некорректно написаных ебилдах. Что-то некорректно настроенное питон может проглотить, а палудис — сыпать исключениями с трассировкой.
Кстати, интересно а что если emerge собрать гугловским llvm python конпелятором, будет ли хоть какая-то разница вообще.

Комментарий безусловно полезный, но он вряд ли в чем-то переубедит ugoday. Для этого парня все проблемы современного софта аксиоматично решаются сменой python/java/c++/whatever на cl.

Простой трюк с squashfs + aufs2 образом, где хранится /usr/portage + /usr/local/portage/layman (дистфайлы выносим за /usr/portage) — сильно ускоряет emerge.

Благодарю. Надо будет попробовать.