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

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

Не все библиотеки, к которым вынужденно приходится цепляться, требуют какой-то переорганизации. Предположим, какая-нибудь libssl, libstroke (на вскидку) и т. д. Из хидера функции вытащил, в пакет SSL засунул и все. Что в C, что в CL -- вызовы будут плоские. Не такие псевдо-объектно-ориентированые, как в GTK. Так что в общем смысле утверждение "вот только практической пользы с них поменее" не совсем истинное. :)

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

>И вот ведь беда: если простота С-машины позволяет мне убедиться в том, что массивы в С таким свойством обладают, то для Лисп мне это кажется магией, потому как при попытке изучения array.lisp из SBCL мне поплохело уже от первых же строк.

Я код просто для справки дал. Разбираться в нем -- дело тяжелое. В любом коде большого проекта сразу не разберешься. Вот дадут тебе коды MySQL, и ты фиг чего там поймешь. Это для любого языка. Я сейчас тут контрибьюшн в Xorg пытаюсь делать -- драйвер одной старой видеокарточки для поддержки EXA переписываю. Так я уже неделю въезжаю в код (документации на карточку нет). А это только драйвер. :)

Между прочим, авторы SBCL завели хороший ресурс, куда делают коммиты. Не бросают. Он специально сделан для тех, кто хочет поскорее въехать во внутреннее строение SBCL: http://sbcl-internals.cliki.net/index

> А это вообще ни в одной версии под amd64 успешно не собралось. Как говорится, выживает самый приспособленный. Пока что останусь на SBCL.

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

> Если не все - то вопрос снимается, всё ясно.

Это было ясно любому здравомыслящему _всегда_, ибо нет и не может быть серебрянной пули. Лиспом не заменишь узко-специализированные языки (скажет так - заменить можно, но нерационально): тот-же SQL, си как портабельный ассемблер тоже заменить трудновато будет, всякие перлы с шеллами скорее всего тоже не надо (пока :) на лисп переводить прямо сейчас - тяжеловат он для этого. Нормальных vm на лиспе на данный момент я не знаю :(

> Если не намного - тоже снимается по тем же причинам.

По тем же самым причинам специализированным языкам лисп может проигрывать по тем или иным характеристикам. Сводную объективную оценку получить трудно :)

> Как следует, что выгоден экономически: ты делаешь намного больше (он же намного превосходит!) за то же время...

Если рабы-кодеры практически бесплатны и легко возобновляемы, то комбайнам-лисперам трудно получить превосходство на полях софтостроения :)

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

А ещё дешёвую, экономичную и легкоуправляемую, а то все бы ездили на болидах ф1 и летали на стелсах или чём там ещё... :)

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

> Я уже понял, что не получу ответа на _этот_ вопрос ;(

_Здесь_ - не получишь. По многочисленным ссылкам при наличии желания - запросто :)

> Человечество конечно несовершенно конечно, но не безнадёжно. Есть пути введения лисп в мейнстрим не уничтожая человечество.

Очень на это надеюсь... ;)

> > рабовладение существовало тысячелетия, если не десятки тысячелетий, хотя оно экономически невыгодно для общества.

> Ну а эта фраза выдает всего лишь невежество^Wнезнание истории. Рабство появилось всего несколько тысяч лет назад, и появилось именно потому, что было _экономически_ выгодно.

Это зависит от того, включать или нет рабов в понятие "общества", ибо речь шла о "невыгодно для общества" :)

> Ну, тут где-то пробегало (в версии от yyk), что чистый лисп -- это (T NIL CONS CAR CDR QUOTE). А все остальное -- или от лукавого или можно выразить через эти божественные сучности.

Херасе... А вы читать умеете? Там-же: CL - стандарт. А большинство лиспов объединяет вот этот вот набор... Из которого таки всё остальное _можно_ вывести, но это будет неоптимально.

Вы сначала укажите, какой именно лисп вы имеете в виду, а потом уже устраивайте здесь плачь Ярославны...

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

Так эти 1:1 составляют малую часть, ибо чаще нужно именно привести ипользование биндинга "в человеческий вид". Вот здесь и расходятся пути: аж три (если не больше) магистральных биндинга к gtk. Простейшие так не плодяться :)

> Аха. Если так делать, то освоить Лисп становится не страшнее, чем ту же Жабу.

Вы наступаете на старые грабли - _какой_ лисп? Фины описывают тот лисп, который вписывается в десяток основных понятий и форм. CL - стандарт, включающий в себя намного больше, и он вам так быстро не "дастся", хотя он, имхо, больше готов для "продакшн", чем какая-либо другая "реинкарнация" лиспа.

> Главный практический вывод: Лисп, это, оказывается, такой ассемблер.

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

> мощные средства функционального программирования и макрорасширения.

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

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

Это тебя куда-то не туда понесло. Ладно бы ещё спросил почему нет vm на лиспе. Или лиспа для jvm (есть какие-то, но до полноценного CL ни один не дотягивет).

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

Не, это Multiple Decision Diagrams.

> Ненамного хуже (там log по основанию 2, а то и больше).

При тех алгоритмах и на тех объемах, что там используются, замедление в два раза уже заметно. А логарифм 100000 по основанию 2 уже дает 17-кратное замедление.

> Кроме того, у хэшей (почти всех) плохой худший случай (хуже log(N)).

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

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

Не совсем так. Это типа хэш-таблицы, элементами которой опять являются хэш-таблицы, элементами которой опять являются опять хэш-таблицы, а уже ее элементами являются искомые объекты.

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

> Фины описывают тот лисп, который вписывается в десяток основных понятий и форм. CL - стандарт, включающий в себя намного больше, и он вам так быстро не "дастся", хотя он, имхо, больше готов для "продакшн", чем какая-либо другая "реинкарнация" лиспа.

Как и в sicp. Речь не идет о продакшн. Речь идет о быстром обучении. В учебниках типа "Java за 24 часа" тоже ведь весь стандарт и передовые продакшн-фичи не дают.

> то о макрорасширениях лучше и не вспоминайте.

Исключительное ИМХО, как я понял. Ибо макросы в Сях есть, и они позовляют его изуродовать до полной неузнаваемости так же, как и макросы Лиспа.

> Или лиспа для jvm (есть какие-то, но до полноценного CL ни один не дотягивет).

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

> _Здесь_ - не получишь. По многочисленным ссылкам при наличии желания - запросто :)

Диалога ничем не заменишь

>> Если не все - то вопрос снимается, всё ясно.

>Это было ясно любому здравомыслящему _всегда_, ибо нет и не может быть серебрянной пули.

"Серебряная пуля" - это совсем из другой оперы. Языки, которые были некоторое время стандартами разработки _во всей отрасли_ - были (Си, Си++, Java). И мой вопрос был - если Лисп _настолько_ хорош, то почему он не стал таким стандартом?

>> Рабство появилось всего несколько тысяч лет назад, и появилось именно потому, что было _экономически_ выгодно.

> Это зависит от того, включать или нет рабов в понятие "общества", ибо речь шла о "невыгодно для общества" :)

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

> В учебниках типа "Java за 24 часа" тоже ведь весь стандарт и передовые продакшн-фичи не дают.

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

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

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

> Ибо эмулировать один ассемблер на другом -- это извращение. Все равно, как жаловаться, что нет приличного С для JVM.

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

> О, вспомнил, почему это неприменимо.

"Это" == "дерево"?

> числу ветвлений в вершине.

"Число ветвлений" - это число дочерних вершин? IIRC, и у AVL-деревьев, и у RB-деревьев оно == 2.

> в наиболее важных практических случаях это уже не 3, а 5 и 10 вложений

"Вложений" или уровней дерева?

> Демагогия.

Не согласен.

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

С этим согласен. Но вопрос был - "выгодно для общества", а не для государства, страны, хрена лысого. Для вас это одно и то же? Так вот, с выгодой "для общества" возникают сложности :)

> И мой вопрос был - если Лисп _настолько_ хорош, то почему он не стал таким стандартом?

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

Почему не все остальные языки из вашего списка? Так по той-же причине, что и фаст-фуда и женских романов продаётся больше, чем нормальной еды и литературы :) Нужна аналогия с производством, а не потреблением? Ну, паровые двигатели тоже очень долго в промышленность прорывались ;) А мы всё ещё на стадии кустарных ремесленников находимся...

> Так вот, с выгодой "для общества" возникают сложности :)

Не возникает никаких сложностей. Рабство тогда способствовало прогрессу _общества_ (благодаря которому оно потом было проклято и запрещено - но потом, гораздо потом).

>> И мой вопрос был - если Лисп _настолько_ хорош, то почему он не стал таким стандартом?

> Почему не лисп, а си - потому что лисп вопреки вашему утверждению не является портабельным ассемблером

Это не я утверждал, а юджин_косенко 8)

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

Я не припомню каких-то сильных препон на пути прорыва паровых машин - как они стали приемлемо эффективными, так и стали применяться в промышленности. Кроме того - _такие_ аналогии с промышленностью в компьютерной области не катят - на одном и том же компе одинаково хорошо (и одновременно!) могут работать Си, Лисп и Жаба. И, наконец, у Лиспа было 40 лет на то, чтобы прорваться. Огромный срок по меркам нашей отрасли.

> "Это" == "дерево"?

Массив массивов. Или точнее, таблица таблиц.

> "Число ветвлений" - это число дочерних вершин?

Число дочерних вершин в MDD -- это ведь тоже граф. Видимо, мы друг друга не понимаем.

Суть BDD/MDD в том, что это компактные ациклические графы, свернутые из деревьев. То есть, если взять дерево и выбросить из него все повторяющиеся фрагменты и замкнуть соответствующие связи на оставшиеся уникальные, то получится BDD/MDD. Разница в том, что BDD бинарны, то есть у каждого промежуточного узла только два потомка, а у MDD их может быть больше.

Типичный алгоритм над BDD принимает две структуры, в каждом узле производятся примерно следующие действия:

1. Выполняется рекурсивный вызов обработчика для левых ветвей, получается левый результат.

2. Выполняется рекурсивный вызов обработчика для правых ветвей, получается правый результат.

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

4. Если они не идентичны, то строится новое дерево с левым и правым результатами, как потомками. Однако тут срабатывает фишка, что если такой узел уже был построен раньше (например, в другой ветви вычислений), то нужно не строить новый узел, а возвращать ссылку на уже существующий. Именно на этом этапе необходим кэш узлов, и ключом в нем должна быть не просто ссылка на объект, а тройка "левый результат"-"правый результат"-"код вершины".

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

> IIRC, и у AVL-деревьев, и у RB-деревьев оно == 2.

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

> "Вложений" или уровней дерева?

Вложений таблиц. Но на мой взгляд, это не имеет значения.

> Не возникает никаких сложностей. Рабство тогда способствовало прогрессу _общества_ (благодаря которому оно потом было проклято и запрещено - но потом, гораздо потом).

Только при условии _невключения_ рабов в определение этого самого общества. Рабам прогресс принесла только отмена этого самого рабства.

> Это не я утверждал, а юджин_косенко 8)

Принимается... :)

> Я не припомню каких-то сильных препон на пути прорыва паровых машин - как они стали приемлемо эффективными, так и стали применяться в промышленности.

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

> Кроме того - _такие_ аналогии с промышленностью в компьютерной области не катят - на одном и том же компе одинаково хорошо (и одновременно!) могут работать Си, Лисп и Жаба.

А вот здесь вы уже говорите о "потреблении", а не о "производстве" :)

> И, наконец, у Лиспа было 40 лет на то, чтобы прорваться. Огромный срок по меркам нашей отрасли.

У лиспа было 40 лет для того, чтобы обкатать большинство технологий, которые только сейчас (или недавно) стали внедряться в другие языки. А для прорыва не хватило желающих сделать из него "мэйнстрим" любой ценой :)

>> Почему не лисп, а си - потому что лисп вопреки вашему утверждению не является портабельным ассемблером

> Это не я утверждал, а юджин_косенко 8)

Видимо, они нас в одну команду записали :-)).

А если серьезно, то хотелось бы поконкретнее узнать, в чем именно заключается непортабельность Лиспа?

>> _Здесь_ - не получишь. По многочисленным ссылкам при наличии желания - запросто :)

> Диалога ничем не заменишь

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

>> Это зависит от того, включать или нет рабов в понятие "общества", ибо речь шла о "невыгодно для общества" :)

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

Это какие же сроки? Наиболее ранние официальныо признанные источники относяцо если не ашыбаюсь, к VII-V вв. до н.э., зарождению древнево египта. Достоверных более ранних просто нету.

> А если серьезно, то хотелось бы поконкретнее узнать, в чем именно заключается непортабельность Лиспа?

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

> Рабство тогда способствовало прогрессу

хм. did you know what рабство жестоко ограничивало применение разного рода механизмов? Или ты будеш утверждать, что механизмы нейдут на пользу прогресса?

> как они стали приемлемо эффективными, так и стали применяться в промышленности.

наоборот, они стали эффективными как только понадобились. До этого просто никто (со времён Нерона!) не работал над их эффективностью.

> И, наконец, у Лиспа было 40 лет на то, чтобы прорваться.

Прорваться куды? Я приводил кучю ссылок только на коммерческие реализации, стоимостью до нескко килобаксев. А сколько ты можеш назвать разных компилеров сей, с++ и жабы? Это приблизительно всёодно чё говорить "самолёты и вертолёты маргинальны и не получили распространения потому что по гаражам у всех лисапеды и жигулёнки"

> Только при условии _невключения_ рабов в определение этого самого общества. Рабам прогресс принесла только отмена этого самого рабства.

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

> А если серьезно, то хотелось бы поконкретнее узнать, в чем именно заключается непортабельность Лиспа?

http://www.cons.org/cmucl/FAQ.html 8й вопрос. ИМХО главным образом из-за того, что высокоуровневые абстракции нужно привязывать к конкретной модели жылеза и оси. Для портабельного макроассемблера навроде сей это намного проще, потому что в неоптимизированной форме ево операторы более-менее однозначно соответствуют группе асмовых комманд.

> требование _качества_ кода

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

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

Зыть, я же о том, что рабство самим рабам никакого прогресса не принесло

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

Спасибо за уточнение :) (Я думал, что это и так понятно... и не ошибся ;)

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

А я о том, что и остальным тоже сравнительно никаково.

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

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

Опять на радость оппонентам поспорить не удалось... ;)

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

А что можно тюнить в хеше, кроме собственно хэш-функции и количества (политики аллокации) этих, как их по русски, "ведер"?

У плюсового hash_map первое - параметр шаблона. Наверняка есть и реализации, где второе настраивается через policy.

> Какого рода аргументация тебя бы устроила?

Что-нибудь вроде: "Лисп не получил распространения, это факт. Потому что его огромные и несомненные были скомпенсированы следующими недостатками: <здесь перечень недостатков>"

> Наиболее ранние официальныо признанные источники относяцо если не ашыбаюсь, к VII-V вв. до н.э., зарождению древнево египта.

Я люблю ЛОР, блин! Куда нас занесло, а? 8) VII-V вв. до н.э. - это период распада и упадка Египетского царства. Зарождение, IIRC - это примерно 3-4 тысячелетие до н.э. Официально зафиксированное рабство - примерно 5 тысячелетие до н.э. Правда, это курс истории 5-го класса, могу немного ошибаться (на тысячу лет :))

> Достоверных более ранних просто нету.

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

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

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

Да ты что! До 500 г.н.э (примем, что именно тогда рабство стало невыгодным) не было никакого прогресса? Древние Египет, Ассирия, Персия, Греция, Рим - это нифига не прогресс? "Водопровод, сработанный еще рабами Рима" - не прогресс?

8))) Отличный, отличный топик

> Рабство тогда способствовало прогрессу

хм. did you know what рабство жестоко ограничивало применение разного рода механизмов? Или ты будеш утверждать, что механизмы нейдут на пользу прогресса?

Это где такое было? Это больше похоже на городские цеха веках так в 8..13-ом. > наоборот, они стали эффективными как только понадобились. До этого просто никто (со времён Нерона!) не работал над их эффективностью.

Не было у паровых машин непрерывной истории от Нерона до этого, как его (смотрит в яндекс), Ватта, да. В Риме это была игрушка, и на тех задачах, которые решались тогда (сельское хозяйство+ремесло), она была сильно хуже, чем рабы/тягловые животные. А потом ее переизобрели заново в 18-м веке. И когда Ватт приделал к ней автоматический регулятор - тут же завоевала практически всю энергетику (ж/д и морской транспорт, фабричные и рудничные приводы - а больше тогда ничего и не было).

> этих, как их по русски, "ведер"?

"Букетов" 8) Перевод неформальный, но классный.

>http://www.cons.org/cmucl/FAQ.html 8й вопрос.

А это уже половые проблемы CMUCL. :) Поэтому и сделали от него fork под названием SBCL, чтобы перестроить по-нормальному код, который портируется куда веселее, чем CMU. Думаю, что скоро планомерно возьмутся все высоты. Это и было основной целью проекта SBCL, который теперь своей жизнью зажил.

>> Рабство тогда способствовало прогрессу

>хм. did you know what рабство жестоко ограничивало применение разного рода механизмов?

Ключевое слово - "тогда" (речь, напомню, о Древнем Египте). И, естественно, со временем рабство превратилось в тормоз прогресса, и в основном исчезло, а потом вообще было объявлено вне закона.

И еще: по-моему, в таких случаях нужно писать "did you know THAT", не "what". Нет?

<невнятное про паровые машины поскипано>

> Лисп не получил распространения, это факт

какой же се факт? 8()

> Потому что его огромные и несомненные были скомпенсированы следующими недостатками: <здесь перечень недостатков>"

У всех есь недостатки. С недостатками мы боремсо.

> Куда нас занесло, а?

ёпт! мя глюкнуло. Я имел введу 5-7 тыс лет до н.э. вместо 5-7 века :( нуфсё, я аблажался и теперя мне никто не поверитнахъ :'(

> Да ты что! До 500 г.н.э (примем, что именно тогда рабство стало невыгодным) не было никакого прогресса? Древние Египет, Ассирия, Персия, Греция, Рим - это нифига не прогресс? "Водопровод, сработанный еще рабами Рима" - не прогресс?

А какой там прогресс? Ну строили чёто, выращивали, киляли друх друха. Или ты знаеш там были НТР про котороя я не ведаю?

> До 500 г.н.э (примем, что именно тогда рабство стало невыгодным)

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

Рабство стало невыгодным эдак чуть позже Цезаря (Гая Юлия), да и то больше из-за истощения африканских земель.

А в Конфедерации оно оставалось выгодным до середины 19-го века, и сохранилось бы и дольше - но северяне не позволили.

И, кстати, выгодность политического строя для общества имеет смысл мерить по высшим достижениям этого общества - нет никаких сомнений, что Египет и Микены, Рим и Карфаген были большим шагом вперед по сравнению с племенными кланами пастухов...

> речь, напомню, о Древнем Египте

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

> И еще: по-моему, в таких случаях нужно писать "did you know THAT", не "what". Нет?

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

>> Лисп не получил распространения, это факт

> какой же се факт? 8()

Голый!

> > Куда нас занесло, а?

> ёпт! мя глюкнуло. ... я аблажался и теперя мне никто не поверитнахъ :'(

Ни за чьто!

> А какой там прогресс? Ну строили чёто, выращивали, киляли друх друха.

Да, Вавилон, Персеполис, Афины, Александрия, Рим - это так, "чёто". Мореплавание - какя мелочь. Ирригационные системы - тоже фигня. То, что "киляли друх друха" с ипользованием всё более совершенного оружиея и тактики - тоже ни разу не прогресс.

Ну а греческие театр и изобразительное исскуство, греческая и римская философия - они даже упоминания не стоят - это же не НТР. Только НТР стоит нашего просвещенного внимания!

> А если серьезно, то хотелось бы поконкретнее узнать, в чем именно заключается непортабельность Лиспа?

Не непортабельность, а более сложный процесс. Если взять CLISP, то у него с платформами все просто, так как он есть байт-код интерпретатор, написанный на C. Где скомпилится, там и пойдет. А вот с компиляторами LISP сложнее, так как поимио обеспечения нативной кодогенерации, надо еще иметь привзяку к операционной системе.

Если ты внимательно посомтришь на исходник SBCL в разделе runtime, то там все увидишь. Большой набор C-файлов, зависящих от ОС (в названиях) и архитектуры. Они там так и встречаются: alpha-osf1-os.c, alpha-linux-os.c, и т. д. :

http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/runtime/

А если ты о непортабельности кода на CL в разных реализациях, то и такое случается. Если взглянешь на серьезный проект, то увидишь там условные дела: #+sbcl #+allegro, #+openmcl и т. д. Это от того, что когда речь заходит о вещах, не описаных в стандарте, то у многих реализаций развязаны руки. Делают свое. А ты должен иметь в виду, что если ты используешь библиотеку sb-posix в SBCL, например, то ее не будет в другой реализации или она совсем другая. Или sb-bsd-sockets, например.

>>> Лисп не получил распространения, это факт

>> какой же се факт? 8()

> Голый!

в бане вместе парились, да?

> Да, Вавилон, Персеполис, Афины, Александрия, Рим - это так, "чёто". Мореплавание - какя мелочь. Ирригационные системы - тоже фигня. То, что "киляли друх друха" с ипользованием всё более совершенного оружиея и тактики - тоже ни разу не прогресс.

ну сравни с 19-20 веками.

> Только НТР стоит нашего просвещенного внимания!

в рамках данново топика, да. Ибо в противном случяе придёцо всякое типо методики ХР за прогесс признать.

> Что-нибудь вроде: "Лисп не получил распространения, это факт. Потому что его огромные и несомненные были скомпенсированы следующими недостатками: <здесь перечень недостатков>"

Ни кто не говорит, что у лиспа (CL?) нет недостатков _как у ЯП_. (И когда-то он таки был довольно распространён в процентном соотношении). Но он не получил массового распространения в большей степени не из-за своих недостатков. Лисп тоже не сразу стал CL-м. И макры в нём появились не сразу. И CLOS. И т.д., и т.д. С учётом оверхеда на "символьные вычисления" и ограниченности ресурсов можно было найти/создать более эффективный (в машинном плане) язык для конкретной области (си, кобол и т.д.). А с появлением писишек на рынок вылезли совсем другие "правила игры". К моменту появления железа, на котором на оверхед лиспа можно было не смотреть, у него была куча "конкурентов", которые имели уже довольно "широкие слои комьюнити", через которые не так-то легко пробиться, учитывая, что очень многие стали руководствоваться личными предпочтениями/привязанностями, а не строгой оценкой и прочее. Опять же мифы и предвзятое отношение...

>> До 500 г.н.э (примем, что именно тогда рабство стало невыгодным)

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

У тебя проблемы с датами или чтением? А.Ф.Македонский умер в 325 г до н.э, Пунические войны закончились (IIRC) к 210 г. до н.э. А к 500 г н.э. готы уже 4 года как взяли Рим.

> Египет и Микены, Рим и Карфаген были большим шагом вперед по сравнению с племенными кланами пастухов

При этом зижделись на использовании рабского труда.

>> Да, Вавилон, Персеполис, Афины, Александрия, Рим - это так, "чёто". Мореплавание - какя мелочь. Ирригационные системы - тоже фигня. То, что "киляли друх друха" с ипользованием всё более совершенного оружиея и тактики - тоже ни разу не прогресс.

> ну сравни с 19-20 веками.

Ну заметь разницу в 3-4 тысячи лет.

Или сравни 20-й век с 50-м :-P

>> Только НТР стоит нашего просвещенного внимания!

>в рамках данново топика, да

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

> Ибо в противном случяе придёцо всякое типо методики ХР за прогесс признать.

Лет через 10 увидим, что это было.

И нафиг я паровую машину вспомнил?... :-\

>А если серьезно, то хотелось бы поконкретнее узнать, в чем именно 
заключается непортабельность Лиспа?

Проще приведу пример из произвольного кода:

#+lispworks
(eval-when (:compile-toplevel :load-toplevel :execute)
  (require "comm"))

#+sbcl
(eval-when (:compile-toplevel :load-toplevel :execute)
  (require :sb-bsd-sockets))

;; managing processes

(defun current-process ()
  "Return the object representing the current process"
  #+lispworks mp:*current-process* 
  #+abcl (ext:current-thread)
  #+openmcl ccl:*current-process*
  #+sb-thread sb-thread:*current-thread*
  #+allegro sys:*current-process*
  #-(or lispworks abcl openmcl sb-thread allegro) nil)

(defun kill-process (process)
  "Kill the process represented by the object process"
  #+lispworks (mp:process-kill process)
  #+abcl (ext:destroy-thread process)
  #+openmcl (ccl:process-kill process)
  #+sb-thread (sb-thread:terminate-thread process)
  #+allegro (mp:process-kill process)
  #-(or lispworks abcl openmcl sb-thread allegro) process)

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

>> ну сравни с 19-20 веками.

> Ну заметь разницу в 3-4 тысячи лет.

> Или сравни 20-й век с 50-м :-P

Дык и я про чё. За 2-3 века было прогрессу больше чем за тыщелетия.

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

Почему? Замечятельный. Главное чёбы модераторы не подтянулись, не к нощи будут упомянуты. А так, мож РФВС догоним если уж до форматоф недотянем.

>> Ибо в противном случяе придёцо всякое типо методики ХР за прогесс признать.

> Лет через 10 увидим, что это было.

Я предпочитаю сам создавать то, чё лет чз 10 смотреть будут.

Вродебы я ево первый вспомнил?

http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1602845