Да ну?!? Примерчик слабО привести, когда это код генерился бы на C++. В ходе выполнения. Динамически. Переносимо (платформонезависимо).

Я же показал, что бывают вполне формализуемые, имеющие однозначный ответ _символьные_ задачи. Вроде того же уравнения Пуассона, и других извратов из методов матфизики.

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

Да. Я глянул на эту страничку. И ничего (_н_и_ч_е_г_о_) разумного там не нашел. Кроме единственной вещи, опровергающей все твои сентенции - ты пользуешься продуктами Free Software World (Free Databses и проч), при этом очень и очень яростно на него нападая. Никаких толковых аргументов против Linux я не обнаружил (кроме, вестимо, "монолитным ядром пользуются только казлы!"). Вобщем, стандарт. Ровно то же самое, что... как же это, бишь... ПионЭры (ух, как любишь ты это словечко, видимо сам себя считаешь по меньшей мере комсомольцем?) говорят про Windows. Ничего особенного. А жаль. Разумный вроде бы человек...

С++-ый код не обязательно должен динамически генерить именно машинный код. Он может просто использовать интерпретатор любого языка (слинковавшись с интерпретатором) и генерировать либо statements того языка, либо байткод того языка (если есть - как например Perl, Python). Исполнение полученного кода (просто текста или байткода) займет скорее всего меньше времени, чем код на лиспе, реализующей тот-же алгоритм (если конечно та реализация lisp не CLOS - то есть если она не компилирует лисп в машинный код налету). А для high-performance computing - когда динамически-сгенерированный код будет прогоняться очень много раз - имеет смысл сгенерить C или Fortran - исходник, откомпилировать его в динамическую библиотеку (компиляция займет около 2х секунд), а потом динамически подгрузить скомпилированную динамическую библиотеку, взять адрес точки входа и просто вызвать машинный код.<br> Ты, vsl, будешь наверное говорить о том, что компиллеры с некоторыми ОС не поставляются. Я это возражение не принимаю.<br> О linux vs others: У всякой вещи есть своя денежная стоимость. Не забывай про это, vsl. Если удовлетворяющий уровень надежности можно достичь при материальных затратах в 5 раз меньше на решения, которые ты предлагаешь, то зачем выкидывать бабки на ветер на VAX/VMS или alpha/DGUX? Если стабильность сильно важна то (больше для морального успокоения, чем по об[ктивным причинам) можно поставить *BSD на сервер. Что ты скажешь про *BSD? Примерно то же и с программированием на lisp'е - код красивее, но все равно lisp-программа работает медленне, чем С- или Fortran- программа. Хотя лет через 20, когда CPU будут мощнее в 100 раз, возможно за производительностью так уж гоняться не будут, и возможно будет маркетинговый бум на AI и различные lisp, *ML, etc.

Ну так какая разница? Что лисп этот код сгенерит, что C++ - сам код все равно будет лиспообразным. Кроме того, прежде чем предлагать подобное решение, надо бы его самому хоть раз попробовать. Подозреваю, что трах обеспечен нехилый... ;)

Ну а *BSD я уважаю. В свое время много сил потратил на NetBSD-vax, возможно, там в ядре мой код сохранился...

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

P.S. Я сам все, что делаю не для внутреннего использования, делаю под GPL. И это не мешает мне на FSF наезжать.

To vsl: как оперативно ты ответил :-) ! (да и я тоже... :-) Если ты сомневаешься насчет того, сколько будет трахания - то значит либо ты не понимаешь, как это реализовывать (то есть ты плохой программер на С/С++), либо это твоя попытка (криво) защититься. ОК. Мне кажется, что это реализовать эелементарно ( fopen; fprintf*; fclose; system; dlopen; void (*fn) () = (void (*)())dlsym; fn();) Вот и все. Но подход с компиляцией оправдан, если сгенерированный код будет очень много раз исполняться. Если скорость не важна - то возможно проще сгенерить кусок на перле и его исполнить.<br>
Куда бы не пошел Линус, линукс пойдет туда, куда захочет большинство - это гарантирует GPL. Просто Линус сознательный человек. А насчет бета тестера - чего-то я не чувствую что я работаю с софтом бета-уровня (по-крайне мере я не рвусь к бета софту). Если же работаю, то либо я сам это хочу (чего-нибудь меня в софте не удовлетворяет), либо просто выгоднее довести библиотеку до высокого качества и бесплатно ее использовать в своем коммерческом софте. Да и вообще, на BSD ли, на линуксе ли, на DGUX, - бесплатный софт один и тот же, не так ли? Эти системы только и отличает ядро ОС. А вот с линуховым ядром я проблем совсем не имел (ну ладно - 1 раз за 2 года на одной машине - и то при нетипичном ее использовании :-). Будут серьезные проблемы - перейду на BSD (халявщик я), ну или на солярку - славо богу это все unix - компилю где хочу!<p>
А чей-то ты на GPL едешь - просто привычка что-ли - идти против течения (мода быть не как все)?  И вообще, чегой-то ты здесь тусуешься (извини, если грубо) - тебя же от линукса тошнит? Да и в твоем возрасте сейчас все кто хотел, с мозгами как у тебя, двинули за бугор и получают хорошие бабки (а ты вот тут молодежь развращаешь)? 

Мне платят. Платят тем, что я использую (бесплатно!) это программное обспечение для заработка денег. И бытие бета-тестером в этом случае меня вполне устраивает, тем более что ошибки встречаются настолько редко (и они столь незначительны) что говорить о них - просто позориться. Берем SCO. За деньги. Наблюдаем ошибку (своими глазами), коими она полнится. Что делаем? Пишем в службу поддержки, ждем, ждем, ждем, грузим патч, затыкаем. Идем на начало. Linux? Да, то же самое. Но я не заплатил N+1 Kbucks, что бы иметь такое же счастье. Воруем Windows. Наблюдаем ошибку. Пишем в службу поддержки. Видим фигу. Живем с ошибкой. Что же касется "пойдет туда, куда партия прикажет", так это можно почитать kernel developer's mailing list. И заметить, что далеко не все диктуется Linus'ом. Да, естественно, общая координация проекта ведется им. Но давайте не будем в этом смысле говорить про коммерческие системы, OK? Я думаю, ты писал программы для фирм, и вполне знаешь, кто и как осуществляет планирование и управление проектом. А о монолитном ядре, так это стоит просто взглянуть на общее число пользователей (очень красивого внутри) Hurd и Linux. Результат очевиден. Почему? Честно, не знаю. Может, потому что A:AIAAEI IAA *OAA IAANO GNU. iIO:AAO, D-IOIIO THOI *OAA D-OE *UEIE E USG Unix. Я достаточно аргументирован?

"потому что... USG Unix". Классно. :-) Да, где-то ты прав :-) Связка Lynx - Vim сработала не то что бы очень здорово... Но это ни о чем не говорит, паки это моя собственная криворукость :-) Там было написано вот что: "многие не любят GNU. Может, потому что все привыкли к USG Unix".

Я вот об том и говорю, что сгенерить кусок к примеру на Perl-е средствами C/C++ - это именно трах, и ничего более. Не предназначен сей язык для подобных целей. По этой вот причине и спрашиваю, пробовал ли ты это делать. btw, для любителей катить бочку на Лисп: есть такая его реализация - GNU Common Lisp, так вот, он очень хитро делать умеет - переводит те части кода, какие можно, в C, компилит, и потом это можно просто подлинковать к чему угодно.

Ну а тут я тусуюсь лишь по той причине, что таки этот ваш линух использую. А что еще прикажете на писюку ставить? ;) И за бугор я не хочу - мне и тут хорошо. Я же не программист, я физик.

Ну ты попал! Сравнил число пользователей Hurd и число пользователей Linux - и при этом забыл, на сколько порядков больше пользователей Windoze, чем пользователей всего остального ;) Ну а то, что тебя пользуют на халяву - я имел в виду не то, что ты будешь посылать баг-репорты, а то, что скорее уж найдешь и исправишь ошибку сам, и после этого следуя лицензии ОБЯЗАН будешь отдать свое исправление авторам. То есть, напишет кто-то глюкало для своих личных целей, может даже бабки за это получит (e.g. по гранту), а весь остальной мир ему на халяву это глюкало до ума доведет.

To vsl: Ну ладно - ты сказал о себе что-то похожее на правду (что ты не программер). Насчет генерации куска на перле и его исполнения - в моем софте я такого не делал (но проблем не вижу) - просто такого не требовалось. Но ты пожалуйста делай свои наезды технически конструктивными и мотивированными (с экономическими обоснованиями Ж:-). А то, что ты любишь VMS и DGUX - возможно потому, что ты не видел их исходного кода (может, тебе бы плохо стало) - linux внешне (не глядя на код и исключая "краевые задачи") достаточно крут. Наличие исходного кода позволяет сделать его крутым и изнутри. Ну и поменьше флейми про lisp (все твою точку зрения на языки программирования прочувствовали).

Да, кстати, почему именно на Перле? Чем он так крут, почему его можно считать хоть в чем-то лучшим, чем Лисп? (warning - это флейм!).

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

Не надо грязи! Common Lisp - вещь абсолютно переносимая. See CLtL2.

А по поводу перла - для задач ПАРСИНГА перл подходит мягко
говоря НИКАК. Покажи, как ты на нем деревья будешь строить?

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

ic 

To vsl: почему перл? Да так - в голову взбрело. Можно код и на лиспе генерить, и на чем хошь, сразу на нескольких языках. C bindings почти ко всем языкам есть... А чегой-то ты linux используешь? А не твою любимую винду (так на твоей homepage написано), или *BSD, или солярис, или еще чего?

Действительно, худшего примера применимости Перла и придумать было нельзя. Парсинг - совсем не для него. Вообще, единственный резон его пользовать - это DBI. Больше в этом язычке ничего хорошего нет. И кода на нем не так уж и много писано, если сравнивать с Лиспом. Так что, все мимо тазика.

Дык вот, генерить Лисповый или какой еще код на C - это совершенно идиотское развлечение. Кто работал с MATHlink, тот меня поймет ;)

То есть, гораздо лучше генерить код какого-то языка на самом этом языке. Tcl генерить из Tcl-я, Lisp из Lisp-а, и т.д. Кстати, обратное неверно - из Лиспа очень хорошо получается автоматом генерить Сишный код. Так что, все наезды на Лисп и ему подобные скриптовые языки остаются совершенно неубедительными - даже мнение об их "тормознутости" не имеет под собой ничего реального. Лично мне не жалко 5-10% торможения, если это цена хорошего языка и жесткого контроля. Time critical модулей как правило в обычных проектах очень мало.

Про Виндовс - я бы его использовал, да только под него нет ничего из того, что мне нужно. Так что я предпочитаю любить его со стороны, без контактов. Солярис - денег стоит. BSD - поставил бы, хотя бы из большой любви к NetBSD, да только лениво было. Попался под руку Линух - его и поставил. Теперь вот жалею, но не так сильно, чтобы тратить время на переход на другую систему. Да, еще - солярис бабок нехилых стоит, а я человек честный, воровать не привык.

2All Flamers: Господа! Сходил по ссылке "http://ontil.ihep.su/~vsl/whylinux.html" - Действительно никакой аргументации там нету.( если честно - только большая ненависть к авору :) Мне вот стало интересно, а не пропаганда ли это Виндозы? И, действительно, ведь, что там за отстой написан по типу Архитектуры и т.д. ФриБСД - Хорошо, не отрицаю, но Линух хорошо продуманная и хорошо написанная ОС. Так что приволите веские аргументы, когда Флэймите :)

Из C можно генерить код любого языка. Я не думаю, что это такое уж извращение. И еще надо посмотреть, как используется память lisp реализацией. Ну а все скриптовые языки как основной язык для реализации всего приложения (коммерческого, по крайней мере распространяемого в России) на нем - имеют один недостаток - их надо либо либо распространять в исходнике, или в байткоде, который очень легко дизассемблируется. У компилируемых языков такой проблемы нет. Ну ладно, хватит про это трепаться - у меня нет времени

Про солярис: по крайне-мере раньше он стоил $9 для учебных (и личных?) нужд. А украсть $9 - я думаю совесть может простить. А про винду - ты наверно с ней вообще дела не имел как C/C++ программер - а то бы ты без мата о ней ни слова сказать не мог. Ну ладно, у меня нет времени тут чат разводить.

Я же уже говорил про стандарт Common Lisp'а где-то раньше, и про то, что разные трансляторы его ой как по разному воспринимают... Я со 100%-ой уверенностью могу сказать: код написанный на CL для CMUCL придется править, чтобы он работал на Allegro. Да и какая разница вообще: (и об этом я уже тоже говорил) Lisp'а - 90 диалектов (плевок в сторону CL - а мне, например MacLisp нравится. Что мне делать? По нему стандартов еще не придумано...) А перла - (во всяком случае, пока) только один (какой-то фирмы, я уж и не помню, какой) который отличается не поведением, а только скоростью исполнения... Под парсингом имелся ввиду, безусловно, _не_ анализатор грамматики и прочее. Имелось ввиду вот что: (случай из реальной практики) Не очень разумный web-мастер письма с заполненными анкетами от читателей просто складывал в один здоровый файл. Необходимо: (с учетом пропусков, переводов строк, незаполненных полей) занести все сведения из файла в SQL-базу. На перле я писал это... около 30 минут. Это задача - не для Лиспа, хотя я могу ее написать и на нем. И утверждать, что кода для перла меньше, чем для лиспа - по меньшей мере, глупо. Да, Symbolics написала за свою долгую жизнь кучу кода. Но где они, те Лисп-машины? Ты на них свой линух держишь? А вот для перла существует безумное количество кода для решения именно повседневных (!) задач, в которых речи о высотах Computer Science и близко нет... Просто нудной обязаловки.

Ну так все же попробуй погенерить код чего попало из C++. Я пробовал, и знаю, насколько это сложнее, чем из Лиспа или же SML. Ну и про компиляцию скриптовых языков - попробуй дизассемблировать Mathematica Kernel. Не выходит каменный цветок? И правильно делает - хорошо скомпилено, качественно. Да и компилить можно в нейтив не хуже чем C, тем же GCL, к примеру. Так что все наезды мимо тазика.

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

Ну не поймаете вы меня на пропаганде Виндовс, как бы не старались! Не могу я виндовс пропогандировать, ибо и близко к этой Самой Рулезной ОС не подхожу, дабы не разочароваться. Мне хотелось бы услышать грамотные ответы по поводу архитектуры (чем микроядерность не нравится, и т.д.), а не пустой флейм.

...вы тут конечно все спорите. А сказать по сути есть кому? у меня есть прога, где в качестве расшерения используется slang. Ну надо дальше развивать, кол-во скриптов, если по уму делать растет катострофически, и... что-то страшновато становится. Уж больно на бейсик становится похоже - концев не найти. Мне тут guile - чем нибудь поможет? Как у него с модульностью(мне пакеты в xemacs'е сильно нравятся)? Переносимостью (я собирал под rh и cygwin с небольшим патчем)? Под dos я так понял никак?(да и фиг с ним). Стабильностью? - а то судя по ихнему mailing-list'у тот еще междусбойчик. Отладчики есть? А они ему нужны? И еще (понимаю что обнаглел) - нельзя ли на нескольких примерах показать то самое отличие "функционального" программирования от ОО, и как эффектно генерить на lisp'е код на perl. Особенно второе, а то у меня создалось впечатление, что как раз здесь Lisp "сосет" так же, как и с, а тут утверждают обратное. Интересно. btw. Только для информации. Дискутировать не буду.С perl'ом становится тяжело работать, как только появляются сложные структуры данных. Ошибки трудно отлавливать. Очень тяжелый язык для прог больше сотни строк. Я на нем по с-шным хидерам генерил с-шные исходники для кода извлечения структур из БД - умаялся.

_librep_

Привет всем!

_librep_-на мой взгляд отличный lisp_interpreter
* компилятор есть в байткод, кстати от которого не легче понять
  закрытую программу, т.к. он aka 

(defun foo (x y)
  (if (> x y)
      (- x y)
    (- y x)))

After compilation and disassembly, the following is produced (but without the annotations): 

Disassembly of function foo:

Arguments: (x y)
Interactive spec: nil
Doc string: nil
[Uses 15 code bytes, 2 constants, and 2 stack slots]

Disassembly:

0               refq    [0] x   ;load x onto the stack
1               refq    [1] y   ;load y onto the stack
2               gt              ;greater-than comparison
3               jn      12      ;if x > y goto 12
6               refq    [0] x
7               refq    [1] y
8               sub             ;x - y on stack
9               jmp     15      ;goto end
12              refq    [1] y
13              refq    [0] x
14              sub             ;y - x on stack

* на нем написаны подписи к sawmill, есть gtk_wrapper!
* переносим говорят даже на 64bit hardware.
* общается с базами данных ( см сайт) MYSQL ,etc.
  Динамическая подгрузка (для LISP это обычное дело, но мы же все перечисляем)
  обращение к tar.gz и _ftp_
* Ну и наконец он довольно чисто написан и очень быстр
  (хороший garbage_collector, парень даже свою malloc писал )
 

В Схеме очень хорошая система пакетов, так что будет тебе модульность. Короче, попробуй Guile, а еще лучше - KSI. Код Перла на Лиспе генерить не пробовал, а вот Лисп из Лиспа - на ура делается. Как-нить потом, когда время будет, поэкспериментирую с перлом, тогда и покажу.

Ну, парни! Мне казалось что гуй слизали со смолтолка. В таком возрасте это надо уже знать. А вообще, есть три нормальных языка Smalltalk, Lisp and Forth.

ГУЙ намного раньше появился, чем смоллтолк. Да и лажа он, ибо чистый ООП. Нормальные языки - функциональные языки. Посмотри на SML, O'Caml, O'Label - тебе понравится.

Я одного не понял. Где в Windows микроядро. Если там даже GUI в ядре. Ну, если это микроядро, то у Юниксов наноядро, я у QNX я даже не знаю что:)

Относительно коммерческого софта и лиспа как скриптового языка для этого софта: guile и librep - GPL-ные, то есть динамически линковаться коммерческому софту нельзя. Так что вроде как Perl, TCL, Python - все что остается для скриптовых языков приложения. Конечно, вы сразу предложите писать софт целиком на lispе.

Относительно дизассемблируемости лиспового кода: приведенный фрагмент "ассемблера" IMO не менее понятен, чем лисповый код. А вот unrolled inlined код, распараллеленый на несколько конвейров PII, или такой же код для alpha или sparc (у которых 32 или 64 регистров - вот его да - его хрен разгадаешь).

Нет в виндовс микроядерности. В NT - жалкое подобие, основанное на кастрированном Mach2.5. Но интересно, где ты нашел, чтобы я говорил о микроядерности Виндозе? Я говорил в первую очередь о Digital Unix и Hurd.

AFAIK, есть и LGPL-ные интерпретаторы.

librep?

Из librep manual(librep-0.9/man/librep.texi):
"Если это Вам и так не очевидно, то сообщаю, что программы, написанные
на librep не есть его производные, их лицензирование остается за Вами"
In case it isn't obvious, scripts written to use librep are not considered
derived works, and therefore may be licensed however the author wishes.
 

Дизассемблируемость

> Относительно дизассемблируемости лиспового кода: приведенный фрагмент
> "ассемблера" IMO не менее понятен, чем лисповый код. А вот unrolled inlined код,
> распараллеленый на несколько конвейров PII, или такой же код для alpha или sparc (у
> которых 32 или 64 регистров - вот его да - его хрен
> разгадаешь).

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

Спасибо за перевод :) -я имел ввиду не написание всего софта на лиспе, а использование языка лисп как внутреннего скриптового языка для этого софта (как VisualBasic в софте от MS). В этом случае интерпретатор нужен в виде динамической библиотеки, а она в guile и librep только под GPL.

_GPL_

Я не думаю, что с этим могут возникнуть проблемы. В конце концов можно написать
автору, я думаю он сам напишет как использовать librep как встраивиемый в licenced software.
Более того, можно просто прилагать интерпретатор librep. Кстати даже
native functions можно не открывать (которые общаются с основной программой)
Но неужели Вам мешает GPL????? Вы пишете "шпионов_на_продажу"? ;-) 

_GPL_ (offtopic)

Я все никак не уймусь: многие (SUN,etc) открывают исходный код, Вы же хотите писать совершенно секретно.

Ну блин, надо знать GPL и LGPL. Если софт вызывает функции GPL-ной библиотеки (неважно как слинкованной), то он сам должен быть GPL-ным. Это конечно не интересно. В принципе можно связаться с автором на предмет лицензирования librep для использования в софте - но это встанет в большие бабки. Ну а то что другие открывают код - это маркетинговый прием, а также метод сокращения расходов на поддержание софта (что другие будут фиксить баги). Ну а насчет GPL еще хочу сказать - она достаточно неудобна для GPL-ного софта, проддерживающего плагины (такой софт, как gnumeric) - плагины тоже должны будут расространяться под GPL так как они вызывают код самого софта. Для того, чтобы поддерживать коммерческие source-closed плагины, выход один - весь софт с плагинами оформлять как LGPL-ную библиотеку, или выпускать под другой лицензией (например Perl Artistic).

Ну блин, надо знать GPL и LGPL. Если софт вызывает функции GPL-ной библиотеки (неважно как слинкованной), то он сам должен быть GPL-ным. Это конечно не интересно. В принципе можно связаться с автором на предмет лицензирования librep для использования в софте - но это встанет в большие бабки. Ну а то что другие открывают код - это маркетинговый прием, а также метод сокращения расходов на поддержание софта (что другие будут фиксить баги). Ну а насчет GPL еще хочу сказать - она достаточно неудобна для GPL-ного софта, проддерживающего плагины (такой софт, как gnumeric) - плагины тоже должны будут расространяться под GPL так как они вызывают код самого софта. Для того, чтобы поддерживать коммерческие source-closed плагины, выход один - весь софт с плагинами оформлять как LGPL-ную библиотеку, или выпускать под другой лицензией (например Perl Artistic).

_GPL_/LGPL

Я не думаю, что автор попросит деньги. Писать для широкой публики закрытые
вещи- a la Opera, Borland, BillG (http://www.enemy.org ;-) ) .....
Но небольшой переносимый пятидневный проект за 500$ для небольшого числа
абонентов(терминология КГБ ;-) ). Почему бы и не дать им исходники? Правда надо
заморочить их с тем, чтобы когда опять нечего будет делать, они наняли тебя. 

А я думаю попросит - порядка $20K (по крайне мере запросит столько с буржуев, IMO). А насчет того, что все открывают код - SUN например, только общеала выдать исходники Solaris и Staroffice, но по-моему ничего так и не выдала.

_librep_

Я имею в виду следующее: делаем на librep короткую закрытую программу, это можно
и _она_ вызывает модуль (закрытый) на C/C++ все! А librep поставляем оттдельно, отлично.
 

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

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

Великий и могучий годится только на то, чтобы по пьяни песни матом орать. Или же флеймить в форумах. А документацию надо на нормальном языке читать, на http://www.cons.org/ и http://www.schemers.org/ - там и документация, и туториалы, и вообще все, что угодно.

ОН у тебя, возможно велик, и временами даже могуч, но зачем же ты размахиваешь им здесь ? Для этого существуют другие (более подходящие) места. А вопрос был правильный.

Предидущее относилось к vsl, я просто не на тот линк нажал. Мои извинения.

Мда, действительно. Лично я знаю 4 языка - и все равно русский намного лучше. Вот только надобно им владеть. Если же уровень соответсвтует уровню орания песен на пьянках - можно лишь посочувствовать.. А насчет доки по лиспу - так это есть великолепная книжка, назвается "Мир Лиспа", в двух томах, издательства "Мир". По-моему, единственное издание, вышедшее у нас в стране, столь подробно рассматривающее Лисп. К vsl: Видишь ли, нигилизм хорош лишь в рамках здравого смысла. Если выходить за них - ни к чему созидательному это не приведет... Wart

и еще: слово "туториал" отлично говорит о том самом уровне владения критикуемым языком ;-) Ну да ладно.