Фраза о Лиспе...

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

Ну для CLOS там стоит 2006 год. А для lambda-gtk там все автоматически генерится. файл gtk.api сгенерен прямо из хидеров сишных. А так как GTK2.x у нас бинарно совместимы, то проблем нет. Должен же когда-то проект портирования иметь свой конец. Невозможно же постоянно решать такую задачу! У нее есть четкое логическое завершение -- реализация порта GTK. Порт работает? Работает! Другой вопрос, что нет такого Q&A, которого бы хотелось, чтобы быть уверенным, что проект не подохнет или просто не исчезнет к тому времени, когда появится, например, GTK3. Но тут никто дать гарантии не может. И для cells-gtk, и для clg тоже. lambda-gtk хорош тем, что это просто тупой 1:1 биндинг (atk, pango, glib, gtk) без наворотов. И он работает.

> там просто рекламный треск

ково же они рекламируют? какой им смысел? У них же на паге есь ссыло на в какой-то мере противоположную (как мне показалось при беглом досмотре и довольно ИМХО обективное http://www.norvig.com/python-lisp.html)

> Я не стараюсь держаться мэйнстрима

вроде ты единственный кто в этом топике начал ссылацо на майнстрим?

> я стараюсь держаться технологий, которые я считаю "правильными"

все стараюцо. Только критерий правильности разный.

> И вот если есть выбор из _таких_ технологий - я выбираю ту, которая мэйнстрим.

Я вообще скверно представляю себе, чётакое майнстрим. Но есть впечатление, что достаточно "правильная" технология сейчас майнстримом неприемлема.

Кстати, а зачем тебе вообще майнстрим?

> Не зарекайся

рабовладение запрещено в большинстве стран мира и осуждаецо ООН.

> Ты просто не в теме.

Возможно. Как я говорил по большей части официально моя работа связата с сями. Но я в огромных количествах просматриваю резюмы. Там не проблема найти чела знающего лисп, даже питон пару раз попадался и руби единова. А вот про кобол даже никаких упоминаний.

> А так как GTK2.x у нас бинарно совместимы, то проблем нет

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

> У нее есть четкое логическое завершение -- реализация порта GTK

а отслеживать и добавлять нововведения?

>> там просто рекламный треск

>ково же они рекламируют?

Себя, свой BioBike. Он написан на Лиспе, и они представляют это его преимуществом.

>> Не зарекайся

>рабовладение запрещено в большинстве стран мира и осуждаецо ООН.

Есть не менее эффективные методы принуждения 8) Или, например, предложат тебе писать компилятор CommonLisp для .NET - откажешься?

> есть впечатление, что достаточно "правильная" технология сейчас майнстримом неприемлема.

"Сейчас"... Извини за нескромный вопрос - тебе лет сколько? Как раз сейчас ситуация выправляется, спасибо FOSS (Линуксу в первую очередь)

> вот про кобол даже никаких упоминаний.

А ты где работаешь? Кобол в Союзе распространения не получил (у нас PL/I рулил). И даже на Западе Кобол - удел дорабатывающих свое ветеранов.

> не проблема найти чела знающего лисп, даже питон пару раз попадался

Хочешь сказать, что людей, знающих Лисп - больше, чем знающих Питон? Хм...

А вообще-то беру свои слова про ветеранов обратно. Кобол сегодня широко преподают в университетах - под именем Java 8)

>а отслеживать и добавлять нововведения?

Вообще, если взглянуть на проблему биндингов шире, то видно, что очень много сил распыляется впустую. Это даже не только проблема Лиспа, но и комьюнити. Человеки -- это тоже ресурс. При растущем числе проектов, число разработчиков растет не так быстро.

Считаю, что все биндинги в Лиспе должны генерироваться автоматически. Я не говорю о высокоуровневых реализациях типа cells-gtk. Я говорю о простых 1:1. Должен инспектирваться хидер, генерироваться независимый от языка файл, а потом преобразовываться в биндинг. Примерно так сделано в lambda-gtk. gtk.api сгененирован из хидеров программой ffigen (http://www.ccs.neu.edu/home/lth/ffigen/), а при запуске lambda-gtk он этот gtk.api в CL переводит. Вот так примерно или даже лучше должно быть в принципе. Тогда и нововведения отслеживать не надо будет.

> Считаю, что все биндинги в Лиспе должны генерироваться автоматически.

SWIG доведи. Там уже есть поддержка 2-х диалектов Scheme.

> они представляют это его преимуществом

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

> Есть не менее эффективные методы принуждения 8)

пускай попробуют

> Или, например, предложат тебе писать компилятор CommonLisp для .NET - откажешься?

Может и нет. Только вот работать на дотнетиненаде и генерить для нево код - существенно разное вещи всё-таки.

> Извини за нескромный вопрос - тебе лет сколько?

значит других аргументов нету?

> Как раз сейчас ситуация выправляется, спасибо FOSS (Линуксу в первую очередь)

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

> А ты где работаешь?

А без разницы.

> Хочешь сказать, что людей, знающих Лисп - больше, чем знающих Питон? Хм...

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

> Считаю, что все биндинги в Лиспе должны генерироваться автоматически

Не очень удачная идея, хотя положительные стороны у её есь. Главный ИМХО недостаток - первоначально "чужеродный" принцип построения тулзов, из-за этого код, построенный с применением, будет каряв, а работать - сложно.

>> Извини за нескромный вопрос - тебе лет сколько?

>значит других аргументов нету?

Чтобы увидеть перемены, нужно долго смотреть

> На мой взгляд стоит всётаки приглядецо к clg и cells-gtk, особо к последнему.

Одна беда: lambda-gtk у меня на машине завелась намного быстрее. Кстати, это можно считать одним из определений мэйнстрима. ;-)

> Чтобы увидеть перемены, нужно долго смотреть

а чтобы поверили, чё видел, нужно размахивать седой барадой и крутым дипломом? :D

> IMHO, computer science "не бывает" (С) ПНвС

Бывает. Только ее уже похоронили. Кажется, еще в 1982 году...

> Одна беда: lambda-gtk у меня на машине завелась намного быстрее. Кстати, это можно считать одним из определений мэйнстрима. ;-)

Умя все завелись как только так сразу. Помереемя у кого майнстримее? :P :D

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

А что, замена x86 на MIXAL II разве проблемы не решает?

> а чтобы поверили, чё видел, нужно размахивать седой барадой и крутым дипломом? :D

У меня нет ни седой бороды (вообще никакой), ни крутого диплома.

> Только ее уже похоронили. Кажется, еще в 1982 году...

Эээ... а можно подробнее об этом грустном событии?

> clisp на C написан, а sbcl на 99% процентов самина себе.

Да я уже понял. Хотя с хэшами для BDD проблема остается, однако это уже, скорее DSP, конечно, если не ввести BDD в базу языка (то бишь, "кастылем"). Думаю, для ее решения в любом языке придется писать свои хэш-множества, но для их хорошей реализации таки нужны структуры со временем выборки по индексу O(1). И вот ведь беда: если простота С-машины позволяет мне убедиться в том, что массивы в С таким свойством обладают, то для Лисп мне это кажется магией, потому как при попытке изучения array.lisp из SBCL мне поплохело уже от первых же строк. Мне вообще вот интересно, есть ли хоть какие-то (полу)формальные методы оценик эффективности Лисп-программ? Впрочем, так глубоко мне не надо. Я готов просто поверить на слово человеку, знающему Лисп, если он просто скажет мне, что массивы таки в самом деле обеспечивают эффективность доступа по индексу O(1). В доке я этого не нашел. У финнов тоже. Может, плохо искал...

Кстати, таки асилил первый том финнов. Я понял, почему у меня не получилось это в студенчестве: там 75% нужно читать по диагонали. Или вообще не читать. Аха. Если так делать, то освоить Лисп становится не страшнее, чем ту же Жабу. Более того, скажу по большому секрету лисперам-гуманитариям: если бы они меньше философствовали и больше писали по делу, то книжки типа "Как освоить Лисп за 24 часа" не были бы сейчас такой редкостью. Можно было бы этот совет адресовать непосредственно финнам, если бы не sicp, который тут усиленно рекомендовали _прорешать_. Скажу сразу: основной текст этой книги тоже можно не читать. Можно сразу начать с задачек. Больше половины решаются в уме. Результаты получаются изумительные: 124 страницы из 600 только лишь за один вечер. Не знаю, кого там и чему учит эта книга, но я бы скорее отнес рекомендовал ее для детского сада с углубленным изучением программирования. Ну, может последние главы -- для начальных классов средней школы.

Но это все так, лирика. Главный практический вывод: Лисп, это, оказывается, такой ассемблер. Аха. Совсем, как Брейнфак. Только Лисп -- это еще и макроассемблер. Потому, видимо, высокоуровневый. Правда, есть еще более высокоуровневый язык -- машинный код. Аха. Имеет всего две базовые конструкции: 0 и 1. Базовый стандарт задан еще в лохматом году фон-Нейманом. На сегодняшний день имеет десятки распространенных реализаций, самой распространенной из которых является x86. И единственный язык, в котором есть все и без кастылей, как, например, в том же Лиспе. Который, кстати, тоже своего рода DSL.

Ну ладно, это я, может быть, и утрировал. На самом деле, я теперь знаю, почему Лисп не получил распространения. Потому что его повсеместно вытеснил другой высокоуровневый макроассемблер. Если кто еще не догадался, то это я о C. Тоже имеет только два базовых типа: числа и указатели. Тоже имеет мощные средства функционального программирования и макрорасширения. В частности, и объектно-ориентированные. Правда, в отличие от Лиспа, у него меньше "батареек из коробки". В частности, поставляется без намертво вшитого сборщика мусора. С другой стороны, из-за мощности С на нем реализована уйма DSL, в том числе и C# и Jaba и Python. И даже большинство современных реализаций Lisp. А Эйфель, так тот вообще является чистым макрорасширением С, ибо после всех макроподстановок получается программа на чистом С, которая потом и интерпретируется системой.

Ну а если без стеба, то если Лисп силен своими макрорасширениями DSL, которые каждый лиспер якобы пишет по пять штук на неделю, то такой вопрос: почему нет ни одной приличной реализации хотя бы той же JVM или Python-машины на Лиспе? Почему нет ни одного приличного транслятора с Java или Python в тот же самый Лисп-код? Даже Эйфель, для которого генерация в высокоуровневые ассемблеры -- это фирменная фишка (СмартЭйфель генерит и С и JVM-код, причем оба переносимы минимум под три платформы), не имеет генератора для Лисп. Может, потому, что и нафик не нужно?

Впрочем, идейка реализации Эйфеля на Лиспе с промежуточной генерацией в Лисп-код мне кажется весьма привлекательной :-). Может быть, на пенсии попробую заняться. :-))

> У меня нет ни седой бороды (вообще никакой), ни крутого диплома.

Ну и нефих тогда левые сущности. Я не так давно на другом форуме типа видел который типо в крутой юниксовой конторе работал, на motif чёто кропал, а про layout manager вообще не вкурсе был, чё такое бывает :D

И ваще

http://emoglen.law.columbia.edu/LIS/discuss/264_On%20the%20Internet,%20nobody...'re%20a%20dog.JPG

можно чё угодно понаписать.

> С другой стороны, из-за мощности С на нем реализована уйма DSL, в том числе и C# и Jaba и Python.

Это пять, здорово сказано! :D Надо бы в фортунки, но без контекста не понятно, а контекста тут набралось блин уже 820 постов. :)

> Эээ... а можно подробнее об этом грустном событии?

http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1304.PDF

Правда, меня таки попутал эпиграф, датированный 1980 годом (потому я и написал осторожно -- "кажется"). На самом деле, статейка весьма свежая, датирована 2000 годом. То есть, даже если и померла, то трупик еще явно не остыл.

Впрочем, Дийкстра таки поставил это утверждение под вопрос, и явно с ним спорит. Однако, общая тенденция все же хорошо проглядывается. Да и Дийкстры уже нет...

> Хотя с хэшами для BDD проблема остается, однако это уже, скорее DSP, конечно, если не ввести BDD в базу языка (то бишь, "кастылем").

А можно узнать, чё за трабла с хешами? И зачем свои писать, если готовое есь?

> при попытке изучения array.lisp из SBCL мне поплохело уже от первых же строк

чё же там такого страшново? :D

> Я готов просто поверить на слово человеку, знающему Лисп, если он просто скажет мне, что массивы таки в самом деле обеспечивают эффективность доступа по индексу O(1).

Можно проверить, или спросить на канале #lisp в irc.freenode.net. Тестовая прога же с полстранички будет. Если несправишся, давай я накрапаю.

> почему нет ни одной приличной реализации хотя бы той же JVM или Python-машины на Лиспе? Почему нет ни одного приличного транслятора с Java или Python в тот же самый Лисп-код?

А зачем если лисп-код в десятки-сотни раз проще сделать чем жавовский или питоний?

>> У меня нет ни седой бороды (вообще никакой), ни крутого диплома.

> Ну и нефих тогда левые сущности.

Я никогда и не говорил, что у меня седая борода и крутой диплом. Только о том, что 16 лет работаю - ну так это правда, а научился я чему полезному или нет - суди сам, если можешь.

> можно чё угодно понаписать.

<shrug> Ну да, то же и к RL относится. И что?

> Ну да, то же и к RL относится. И что?

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

> А можно узнать, чё за трабла с хешами? И зачем свои писать, если готовое есь?

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

У финнов сказано, что ключом в хэш-массиве является ссылка на структуру в памяти, но здесь этого недостаточно. Кстати, можно ли в Лиспе получить числовое значение указателя на структуру? Тогда бы можно было, по аналогии, захэшировать три значения в одно и воспользоваться ассоциативным массивом. Но это только при условии, то ассоциативный массив имеет то же время доступа -- O(1). Ну или, если не имеет, то можно уже полностью развернуть структуру на обычных массивах но при том же условии. Правда, фиговость таких решений в том, что они очень чувствительны к настройкам: размеру ядра хэш-массива и виду хэш-функции. В своих наработках приходилось тюнить, были дажи мысли по автотюнингу. С контейнерами "из коробки" таких проблем, конечно же, нет. Но и уверенности в том, что там все сделано оптимально, тоже нет.

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

> чё же там такого страшново?

Количество вспомогательных сучностей. И объемы. Не знаю, может для кого тыща строк на Лиспе -- это "изящное и простое решение". К тому же, поговаривают, что на Лиспе, как пишется, так и читается. Можно объяснить вкратце, каким волшебным образом обеспечивается требуемое условие -- быстрый доступ по индексу? Можно предположить, что все это многообразие кода сворачивается загадошно сворачивается ну очень умным оптимизатором? И мне предлагают довериться этой железяке? Или там какое-то особое представление используется?

Ну вот, чтобы хоть как-то объяснить, чего мне нужно, то как массивы представляются внутри Лисп-машины? В виде линейных массивов? Тогда как в чистом Лисп-коде эффективно преодолевается разрыв между базовым представлением в виде списков и представлением в виде линейного массива? Или там над списками какие-то индексы надстроены?

> Можно проверить, или спросить на канале #lisp в irc.freenode.net.

Увы мне, совершенно не умею пользоваться irc.

> Тестовая прога же с полстранички будет. Если несправишся, давай я накрапаю.

А что тестировать? Что при линейном росте размера время доступа к произвольному элементу не меняется? А где гарантия, что это не обусловлено фазами луны?

Впрочем, на прогу посмотреть было бы интересно. Сам ниасилю, бо там нужна обработка времени вычисления, а я такое в Лиспе еще не освоил. Ну и вообще, в плане обучения было бы интересно. Кстати, а в Лиспе есть приличный профайлер "из коробки"?

> А зачем если лисп-код в десятки-сотни раз проще сделать чем жавовский или питоний?

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

А во-вторых, а зачем в таком случае вообще писать на лиспе DSL-расширения? Если на самом Лиспе все в десятки-сотни раз проще сделать?

> не должны затрагиваться вопросы, касающиеся опыта работы

Не согласен. Если человек высказывает резкие и необычные суждения, наличие у него большого опыта - это еще одно основание всё же задуматься над его словами. Если же есть обоснованное подозрение, что о наличии опыта он лгал (часто это заметно) - это основание в будущем игнорировать его слова, не задумываясь. Кроме того, иногда речь идет о том, что может видеть _только_ человек с опытом.

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

> полученново образования

Не согласен. Позволяет лучше понять собеседника.

> размера зряплаты

Согласен. Об этом и не спрашиваю никогда.

В любом случае, ты можешь не отвечать (ты и не ответил).

А можно узнать, почему именно хэши? А не деревья? ИМХО, AVL-дерево или RB-дерево вполне подошли бы. Время доступа там тоже O(logN), IIRC, зато поведение в худшем случае - гораздо лучше.

> иерархического хэш-массива

Это же дерево, нет?

> Если человек высказывает резкие и необычные суждения, наличие у него большого опыта

Смысел то каков в опыте, самом по себе? Практически вся теория программирования была разработана аж в 50х-70х годах прошлого века ещё, с математической точностью. Что может дать опыт дополнительно? А вот к аргументам я бы прислушался. Иначе получается "давление авторитетом". По жизни замечал, люди, склонные к таковому давлению авторитетом - недалёкие и безграмотные, больше всево боящиеся что их безграмотность выявится, отчего и неспособные к нормальному диалогу.

> Если же есть обоснованное подозрение

А зачем терзать себя сомнениями? Проверить всё равно не получицо.

>> полученново образования

> Не согласен. Позволяет лучше понять собеседника.

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

> В любом случае, ты можешь не отвечать (ты и не ответил).

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

> А можно узнать, почему именно хэши? А не деревья? ИМХО, AVL-дерево или RB-дерево вполне подошли бы.

Из деревьев знаю только двоичные и B-деревья. Об AVL и RB просто в первый раз слышу. Где можно почитать?

> Время доступа там тоже O(logN), IIRC, зато поведение в худшем случае - гораздо лучше.

Там основной алгоритм имеет сложность где-то O(n^2). Если еще умножить это на logN, то получится не очень хорошо. Кроме того, в авторской реализации тоже были хэши. Да и реализуются хэши проще, как мне кажется.

> Это же дерево, нет?

Ну, если массив массивов считать деревом, тогда да. Но это довольно таки специфическое дерево, не так ли?

> вся теория программирования была разработана аж в 50х-70х годах прошлого века ещё, с математической точностью

ROTFL Что, вот прям-таки ВСЯ? Если это кто-то и сделал, то нам, быдлокодерам, не сообщили, и мы мучаемся 8(

> Что может дать опыт дополнительно

Ну, это кому как. Обычно опыт дает знания. Я, например, 10 лет назад был гораздо худшим программистом, меньше знающим, более самоуверенным. А ты? Не 10, ну так 5 лет, 3 года назад - неужели ты не изменился с тех пор?

>>> полученново образования

>> Не согласен. Позволяет лучше понять собеседника.

>если собеседнику нечего сказать, кроме как похвастацо крутым дипломом

Кажеться, ты путаешь диплом и образование.

>> Если же есть обоснованное подозрение

> А зачем терзать себя сомнениями? Проверить всё равно не получицо.

Терзать - конечно, не надо. Проверять - тоже, мы же не суд. Если человек говорит, (например) что он читал "Джонни-Мнемоник", и тут же называет его главную героиню "Джейн", то с ним всё ясно. Или говорит, что он давно и с интересом следит за FOSS, и говорит, что GNU Manifesto написал Эрик Реймонд.

Хеши в CL имеют O(1), а ассоциативные списки -- O(n)

>Из деревьев знаю только двоичные и B-деревья. Об AVL и RB просто в первый раз слышу. Где можно почитать?

Есть еще деревья со штрафами, splay tree, interval tree. А! вот еще Radix Tree есть. Кстати, последнее применено в ядре Linux в подсистеме VM для поиска страниц.

Можно начать тут: http://en.wikipedia.org/wiki/List_of_data_structures

> об AVL и RB просто в первый раз слышу. Где можно почитать?

AVL-деревья обсуждаются у Кнута (в 3-м томе, неподалеку от B-деревьев), это "почти сбалансированные" двоичные деревья. RB-деревья (red-black trees) - IIRC, то же, но "почти балансируются" по-другому. Почитать - думаю, у Седжвика есть. Реализация RB-деревьев есть в GNU C++ STL.

Если MDD - это Mukti-Dimensional Data, для работы с ними есть какие-то свои деревья (R-деревья, кажется).

> Если еще умножить это на logN, то получится не очень хорошо

Ненамного хуже (там log по основанию 2, а то и больше). Кроме того, у хэшей (почти всех) плохой худший случай (хуже log(N)).

> Ну, если массив массивов считать деревом, тогда да.

Там говорилось о каком-то "иерархическом хэш-массиве" ;)

> ROTFL Что, вот прям-таки ВСЯ?

вся, абсолютно. А ты припоминаеш более свежие сурьёзные наработки в этой области, кроме всяково шаманства типо ХР?

> Если это кто-то и сделал, то нам, быдлокодерам, не сообщили, и мы мучаемся 8(

Надо было спросить.

> Ну, это кому как. Обычно опыт дает знания. Я, например, 10 лет назад был гораздо худшим программистом, меньше знающим, более самоуверенным. А ты? Не 10, ну так 5 лет, 3 года назад - неужели ты не изменился с тех пор?

Знания даёт (само)обучение. Если нету - и через 40 годов будеш писать код навроде boolean lol (boolean x) {if (x == true) return false; else if (x == false) return true; else return !false && !true; }

>> если собеседнику нечего сказать, кроме как похвастацо крутым дипломом

> Кажеться, ты путаешь диплом и образование.

если чел рассуждает о дипломе вместо предмета обсуждения - у нево нету образования. А если образование есть - диплом упоминает в резюмах а не на форуме.

> Терзать - конечно, не надо. Проверять - тоже, мы же не суд. Если человек говорит, (например) что он читал "Джонни-Мнемоник", и тут же называет его главную героиню "Джейн", то с ним всё ясно. Или говорит, что он давно и с интересом следит за FOSS, и говорит, что GNU Manifesto написал Эрик Реймонд.

Ну фих ево знает, мож очепяталсо или позабыл мелкий по ево мнению факт. А по ходу обсуждения зачастую бывает заметно, чё и главную героиню правильно назвал, и манифест наизусть зачитывает, а потом вдрух выдаст, чё функциональные наречия отличяюцо от всех других тем, что в них нету понятий из реальново мира например :D

>Не очень удачная идея, хотя положительные стороны у её есь. Главный ИМХО недостаток - первоначально "чужеродный" принцип построения тулзов, из-за этого код, построенный с применением, будет каряв, а работать - сложно.

Тулзов преобразования хидеров? Ну этот недостаток можно исправить, написав его на самом CL. :) Нет, серьезно. Только его надо научить не только функции из хидеров хватать, но и макросы сишные развертывать, которые в хидерах тоже встречаются. А некоторые и m4 засовывают (извращенцы). Если таким образом получится быстро создавать биндинги к LISP, то остальное уже -- вопрос техники. Вот CLOS-обвертка вокруг lambda-gtk тоже сгенерирована автоматически уже (я сам не смотрел, но так пишет автор), а это уже повод хвастаться перед другими средствами! :) Выгода в простых биндингах -- это то, что переучиваться не надо будет. Занешь, как программировать на GTK -- делаешь также и тут.

Если же ты имеешь в виду то, что само обращение к C -- это чужеродное, то и тут есть ортодоксальные подходы к графике: (i) LTK -- обмен через сокет строками с wish (Tk), (ii) GTK-сервер (http://www.gtk-server.org/index.html), (iii) CLIM/McCLIM и другие, которые используют CLX (соответственно, получаем на выходе чистый X-протокол без биндингов к xlib) ну и т. д. И никаких *FFI. :)

>> ROTFL Что, вот прям-таки ВСЯ?

>вся, абсолютно. А ты припоминаеш более свежие сурьёзные наработки в этой области

Не слежу за этим. Я далек от науки - я инженер.

>> Если это кто-то и сделал, то нам, быдлокодерам, не сообщили, и мы мучаемся 8(

>Надо было спросить.

Мне, пожалуйста, ссылки на выполненные в 50-70-х годах работы, в которых предлагались осуществимые на практике методы доказательства корректности параллельных программ.

>> А ты? Не 10, ну так 5 лет, 3 года назад - неужели ты не изменился с тех пор?

> Знания даёт (само)обучение.

Ты не ответил на вопрос, спрятавшись за банальностями.

> мож очепяталсо или позабыл мелкий по ево мнению факт.

Ну да, "Джейн" вместо "Молли", хорошая такая опечатка. И имя главной героини - это мелкий факт, конечно. А на самом деле он не читал "Джонни-Мнемоник" - он смотрел одноименный фильм.

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

Это значит, что он разбирается в творчестве Гибсона и истории FOSS, но не разбирается в функциональных языках. Соответственно, его мнение о функциональщине - не интересно. Об остальном - вполне.

дело не в функциях и макросах, а ином представлении. Например, 
народить диалог в clg:
    (dialog (make-instance 'dialog
        :title "йух" :default-width 200
        :child box
        :button (list "gtk-ok" #'(lambda (x) (go-to-south arg)) :object t)
        :button (list "gtk-cancel" #'widget-destroy :object t)
        :signal (list 'destroy #'(lambda () (setq dialog nil)))
        :show-children t)))
представь, скоко функций будет вместо если сохранить гткшное
 представление диалога?

> Выгода в простых биндингах -- это то, что переучиваться не надо
> будет. Занешь, как программировать на GTK -- делаешь также и тут.

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

> Если же ты имеешь в виду то, что само обращение к C
> -- это чужеродное

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

> Мне, пожалуйста, ссылки

боюсь, веб-серваки тех годов подзаржавели, хреново совсем работают :(

> Ты не ответил на вопрос, спрятавшись за банальностями.

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

> Ну да, "Джейн" вместо "Молли", хорошая такая опечатка. И имя главной героини - это мелкий факт, конечно. А на самом деле он не читал "Джонни-Мнемоник" - он смотрел одноименный фильм.

Мож и так, бывает. Однако на основании одново-двух подобных фактов рано делать выводы ИМХО.

> Это значит, что он разбирается в творчестве Гибсона и истории FOSS, но не разбирается в функциональных языках. Соответственно, его мнение о функциональщине - не интересно. Об остальном - вполне.

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

>> Мне, пожалуйста, ссылки

>боюсь, веб-серваки тех годов подзаржавели, хреново совсем работают :(

То есть - не можешь. Потому что эта задача не была решена (и не решена до сих пор). В 50-70-х годах было разработано множество классических алгоритмов и структур данных, _с математической точностью_, конечно. Но это такая малая часть "теории программирования", что просто смешно. А XP - это один из современных экспериментов, которые опираются на теорию программирования - только не математическую ее часть, а социально-психологическую.

> Однако на основании одново-двух подобных фактов рано делать выводы ИМХО

А мы не суд - в тюрьму не сажаем. Просто понижаем уровень доверия. Заслужит - повысим.

>представь, скоко функций будет вместо если сохранить гткшное представление диалога?

Ну так это уже совсем другой уровень! Это более высокоуровневая и заумная обертка, которую, увы, надо сопровождать, так как в случае изменения API придется чинить инструмент. Что несложно, так как API кардинально нигде не меняется.

Я же говорю только о биндингах типа 1:1, чтобы можно было работать уже. С таким же успехом может и clg умереть когда-то. Если говорить о долгожителях, то тут только CLIM/McCLIM приходит на ум. Даже стандарт есть, изложенный на бумаге (Common Lisp Interface Manager II specification), которого стараются придерживаться разные вендоры CL. Скоро в MCCLIM должен появится GTK/Cairo-бэкенд. Обещают, что в версии 0.9.3 уже что-то будет. А сейчас там есть PostScript, OpenGL, CLX и beagle (в первый раз слышу. по-моему, это что-то у эппл такое).

И разница в том, что CLIM идет сверху. От более общего к частностям, а clg (возможно) построен, отталкиваясь от GTK. Но в принципе все равны перед судом разработчика. Главное -- это чтобы лицензия была открытая :) Как говорил Джоэль Спольски: "В серьезной разработке пользуйтесь только тем инстументом, который можно починить". Поэтому даже lambda-gtk несложно будет починить, если очень потребуется. :)

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

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

> Так что время влияло неоднозначно.

Но влияло

> Но это такая малая часть "теории программирования"

благодаря этой малой чясти всё современное ПО работает.

> доверия

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

>> представь, скоко функций будет вместо если сохранить гткшное представление диалога?

> Ну так это уже совсем другой уровень! Это более высокоуровневая и заумная обертка, которую, увы, надо сопровождать,

Ребята, если вы еще не читали "Good news, Bad news, How to win big" - крайне рекомендую. Особенно - главу "Worse is better" 8)

> Я же говорю только о биндингах типа 1:1

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

> С таким же успехом может и clg умереть когда-то.

может, ктож спорит? Но пока с такого рода работать оптимально ИМХО.

> Скоро в MCCLIM должен появится GTK/Cairo-бэкенд.

Хорошё бы поскорее.

> Называется "переход количества в качество" 8) Диалектика, мать наша.

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

> Но влияло

А могло и не влиять.

>> Но это такая малая часть "теории программирования"

> благодаря этой малой чясти всё современное ПО работает.

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

> дык а зачем всё переводить в вопросы веры?

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

> Только в современных условиях того, что есть, уже не хватает.

Вообще, многие наработки тех времён ИМХО как следует не используюцо.

> Не веры, а доверия

А не один член?

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

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

> В техническом смысле всегда можно попросить аргументировать

Попросить - можно, если не пора спать (как сейчас :)). Если получишь ответ. Если тебе на понимание ответа и выдвигание контраргумента не требуются часы или дни. Да много всяких "если"...

Пойду я спать. Не хватает здоровья спорить с молодежью в других часовых поясах 8)

> Если получишь ответ.

Или если получиш ответ, с которым не знаеш чё делать...

> Если тебе на понимание ответа и выдвигание контраргумента не требуются часы или дни.

Куда торопицо то?