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

> Выполнябельник всё-таки удобнее ИМХО. А ево-то и негенерят :(

Дык, говорили уже - sbcl могёт

тут же пара человек из германии есть? не подскажете, в германии можно найти работу новичку-лисперу? желательно в районе karlsruhe-stuttgart

> Но присоединюсь, конечно: СКОБАЧКИ САСУТ!!!!

Замените их на то, что у вас не сосёт... А то того... последствия могут быть ;)

> Но присоединюсь, конечно: СКОБАЧКИ САСУТ!!!!

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

> Причём ограничение принципиальное видимо. На случяй eval. Хотелось бы иметь возможнось скомпилить минимальный бинарь без возможности eval в ём ибо всёодно невсегда нужный.

Штука в том, что сие не оговаривается стандартом. Далее брехать не буду, ибо не знаю :)

> Дык, говорили уже - sbcl могёт

небось бинарь получицо как в хаскеле, писятмех?

> небось бинарь получицо как в хаскеле, писятмех?

Пустой - почти в два раза меньше (вроде) ~ 26 мег :)

> Пустой - почти в два раза меньше (вроде) ~ 26 мег :)

дзен-бинарь? Нах? Ведь для этово Кнопка есь: http://knopka.ushmanov.ru/ . Я всегда пользуюсь.

>> Но присоединюсь, конечно: СКОБАЧКИ САСУТ!!!!

> Замените их на то, что у вас не сосёт... А то того... последствия могут быть ;)

Какие? Делись опытом!

> Какие? Делись опытом!

Опыта нет. Есть информация из малой медицинской энциклопедии :)

> дзен-бинарь? Нах?

Чтоб прикидывать, сколько в бинаре твоей проги ;)

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

не, Кнопка всётаки лучше ИМХО...

Ладно, орлы: до штуки - без меня. Режим :(

А вопрос вида компилированного кода рано или поздно встанет у всех, кто начал уже писать программы. Когда-нибудь придет человек и скажет: "А если я не хочу делать программу в виде огромного core? А также не хочу отдавать программу в fasl, так как они очень медленно загружаются?" И тут будет еще нечего ответить (хотя не знаю, как там дело в коммерческих реализациях обстоит). Рано или поздно проблема решится, но сейчас, например, сохраненное ядро save-lisp-and-die с монстром MCCLIM, простейшей рисовалкой clim-fig и основным ядром уже занимает 50 Мб! Бинарный монолит: весь компилятор, REPL, CLOS, все библиотеки функций стандартного CL, графический тулкит, программа. При большом проекте все это дело займет уже больше.

А еще пока нет fasl-совместимости между разными версиями SBCL. поэтому при каждом обновлении все компилируется заново. Вот такие вот в этом плане недостатки есть.

> Хотя, возможно, скопки всё-таки не...

Фраза внезапно обрывается... Ты там в порядке?

Да, эт точно. Раскидать бы пакажи по дллам и лиспмашину в виде микроедра...

>> Хотя, возможно, скопки всё-таки не...

> Фраза внезапно обрывается... Ты там в порядке?

Я тут нормально. А у тя как?

Тож. Но дальше без меня - пора спать.

P.S. оставьте мне 1024-й пост! 8)

ладно, только с условием чё ты оставшиеся до нево ты тож сам забивать будеш.

>Если спросить 10 случайно выбранных программистов, не знакомых ни с >Лиспом, ни с Питоном, что им понятнее - текст на Лиспе или на >Питоне, все 10 скажут - на Питоне. Но ты-то знаешь, что они все >извращенцы...

А что это:

def permutations(e):
    if not e:
        yield []
    else:
        for p in permutations(e[1:]):
            for i in xrange(len(e)):
                new = list(p)
                new.insert(i, e[0])
                yield new

читается намого лучше, чем:

(defun permutations-my (x)
  (if (null x)
    (loop for e in x append
       (loop for p in (permutations-my (remove e x :count 1 :test 'eq))
                 collect (cons e p)))
      '(nil)))

Пример на Лиспе IMHO больше смахивает на английский язык.

Полный core Lispworks в архиве около 5 метров получается, Corman Lisp - около трех. Если выкидывать компилятор, eval, а также неиспользуемые функции, то на практических приложениях EXE для Lispworks ужимается до 1.5М в архиве, Corman Lisp до 2-х метров добивал.

Так что при современных линиях связи это даже для Shareware уже не проблема. SBCL конечно толст, но для серьезных приложений это тоже не проблема, подумаешь какие-то 50 метров, даже в смартфон влезет запросто ;-) Если семейство приложений распространять, то одно ядро можно как .NET Runtime прикладывать один раз на все, уже экономия получится.

Вот тут говорили, чем мол Лисп лучше, Питоне не хуже, зачем нужны макры и т.д.

А где например для Питона аналог CELLS взять ?
http://common-lisp.net/project/cells/

Пример кода:
(defmodel motor ()
  ((status :cell t :initarg :status :accessor status :initform nil)
   (fuel-pump :cell t :initarg :fuel-pump :accessor fuel-pump 
	      :initform (c? (ecase (^status) (:on :open) (:off :closed))))
   (temp :cell t :initarg :temp :accessor temp :initform (cv 0))))

(def-c-echo status ((self motor))
  (trc "motor status changing from" old-value :to new-value))

(def-c-echo fuel-pump ((self motor))
  (trc "motor fuel-pump changing from" old-value :to new-value))

(def-c-echo temp ((self motor))
  (trc "motor temperature changing from" old-value :to new-value))

(defparameter *motor1* (to-be (make-instance 'motor 
		 :status (c? (let ((filtered-temp (^temp self (fsensitivity 0.05))))
			       (if (< filtered-temp 100) :on :off))))))

(dotimes (x 2)
  (dotimes (y 10)
    (let ((newtemp (+ 99 x (random 0.04) -.02))) 
      (setf (temp *motor1*) newtemp))))


Результат:

0> motor temperature changing from NIL :TO 0 
0> motor temperature changing from 0 :TO 98.99401 
0> motor temperature changing from 98.99401 :TO 99.01954 
[snipped 8 intermediate readings] 
0> motor temperature changing from 99.00016 :TO 100.00181 
0> motor status changing from :ON :TO :OFF 
0> motor fuel-pump changing from :OPEN :TO :CLOSED 
0> motor temperature changing from 100.00181 :TO 100.0177 
0> motor temperature changing from 100.0177 :TO 99.98742 
0> motor temperature changing from 99.98742 :TO 99.99313 
[snipped 6 intermediate readings] 

>Полный core Lispworks в архиве около 5 метров получается, Corman Lisp - около трех. Если выкидывать компилятор, eval, а также неиспользуемые функции, то на практических приложениях EXE для Lispworks ужимается до 1.5М в архиве, Corman Lisp до 2-х метров добивал.

Ситуации с коммерческими CL-ями я не знал. Это хорошо. Я обязательно взгляну.

>Так что при современных линиях связи это даже для Shareware уже не проблема. SBCL конечно толст, но для серьезных приложений это тоже не проблема, подумаешь какие-то 50 метров, даже в смартфон влезет запросто ;-) Если семейство приложений распространять, то одно ядро можно как .NET Runtime прикладывать один раз на все, уже экономия получится.

Ну если говорить о sbcl, то ядро 25 метров. Это я еще с MCCLIM посчитал. Да вся проблема в том, что вот не шарится ядро sbcl между приложениями. Каждое приложение сейчас с ним должно быть собрано. Как запустить одновременно несколько приложений, используя одно ядро, как runtime, я ума не приложу (пока). Просто этим вопросом не занимался. Сейчас все больше математику смотрю. Как-то временно отошел от вопросов инфраструктуры и графических интерфейсов, как второстепенных.

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

>А где например для Питона аналог CELLS взять ? http://common-lisp.net/project/cells/

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

CELLS -- это такая надстройка над CLOS, но с таким функционалом, что позволяет делать вычисляемые слоты. Создаешь объект, у которого есть набор слотов (тут температура, статус (датчика?) и состояние нагнетателя топлива (on/off)). А потом определяются правила (rules) для экземпляра этого объекта "мотор1" от внешних воздействий. Когда температура датчика переваливает за 100, то датчик сообщает статус off, а когда меньше 100, то -- on. А в самом объекте "мотор" написано, что если status (наверное, датчика) перескочил в в cостояние on, то fuel-bump открывается. И, наоборот, если off, то закрывается. А дальше в (dotimes...) запускается некая модель внешних воздействий на систему, состоящую из объекта "мотор1". В данном случае игра температурой. В результате -- лог поведения системы.

Пример классической объектной rule-based системы. Такие в большом количестве создавались в рамках экспертных систем. Cells наглядный пример, как это изящно и красиво делается на LISP. Отлично подходит для всяких симуляций и т. п.

Очень интересно и для интерфейсов, поэтому Cells-Gtk очень интересная вещь получается. Если задать поведение какого-то чекбокса правилами от того, что происходит снаружи, то он при происхождении событий будет включаться или выключаться сам. Ну то есть получается интерфейс, построенный на правилах.

А, ну еще и диапазон нечувствительности к колебаниям 0.05 градуса задан, чтобы слабые случайные колебания температуры вокруг отметки 100 не переключали fuel-bump.

> То же и с Фортом - байткодный (ну ладно, косвенно-шито-кодный), интерпретируемый.

Ну не совсем; многие Форты вполне способны разворачивать шитый код в машинный и пробегаться по нему оптимизатором. Тот же SP-Forth, например.

Был уже апдейт:

def permutations(e):
    if not e:
        yield []
    else:
        for p in permutations(e[1:]):
            for i in xrange(len(e)):
                yield p[:i] + [e[0]] + p[i:]

А по поводу похожести на английский:

1. Не припомню в английском слова "cons"

2. Слова в лиспе английские, но вот предложений как-то не образуется.
   Или Йода мастер лиспе сказал это на?

3. Надо поменять опрос, сменить его на: "какая из этих программ более
   читаемая?"

4. COBOL ваще от английского не отличить. И что?

> Когда-нибудь придет человек и скажет: "А если я не хочу делать программу в виде огромного core? А также не хочу отдавать программу в fasl, так как они очень медленно загружаются?"

В сад! А если он ещё попросит охрененный портал на php 10-летней давности? "Хочу/не хочу" - не "катит". Будут обоснованные ТУ, в которые данная схема не вписывается - будем думать ;) И таки fasl не так уж и медленно загружаются.

> А еще пока нет fasl-совместимости между разными версиями SBCL. поэтому при каждом обновлении все компилируется заново. Вот такие вот в этом плане недостатки есть.

...и в ближайшем будущем не планируется. Это как откомпилированные модули от одного ядра к другому ;)

> Раскидать бы пакажи по дллам и лиспмашину в виде микроедра...

А нафига dll, если кроме лиспа их никто использовать не сможет (если это не gcl/ecl, конечно; и то не уверен)?

> А по поводу похожести на английский:

Сейчас опять чукчу вспоминать буду... ;)

"Пример на Лиспе IMHO больше смахивает на английский язык."

Ты слово _больше_ видишь? А смысл понимаешь? Он в том, что "код на лиспе больше смахивает на английский язык чем код на питоне". Или ты будешь доказывать, что код на питоне похож на английский больше?

А о том, что лисп таки отличается от английского - так это ты пальцем в небо ;)

> Сейчас опять чукчу вспоминать буду... ;)

Шутка, повторенная дважды, причем неуместно... причем очень старая шутка

> Или ты будешь доказывать, что код на питоне похож на английский больше?

Вообще-то это не надо доказывать - это очевидно. По крайней мере в обновленной Питоньей версии меньше не-слов (это "def" и "xrange"), не говоря уже о том, что синтаксис ближе к естественному языку.

> А о том, что лисп таки отличается от английского - так это ты пальцем в небо ;)

ЕМНИП, "попасть пальцем в небо" - это значит "сильно ошиьится". Ты хочешь сказать, что лисп _не_ отличается от английского? :-O

> Вообще-то это не надо доказывать - это очевидно.

:-Е Дальше можно не читать...

> ЕМНИП, "попасть пальцем в небо" - это значит "сильно ошиьится".

Ок, тогда это я "попал пальцем в небо" :)

> > Именно в последнее время проснулся интерес к интерпретируемым/байткодным.

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

Ну, собственно, фишка с ними, имхо, в "запускаемом исходнике". Т.е. нету выделенного (интерфейсно) этапа компиляции => упрощается цикл разработки. И с поддержкой/внедрением проще - можно "править по живому", если надо, не парясь со сборкой. И переносимость, все же, выше - я одну и ту же перловую программу пускаю линуксе/amd64 и freebsd/x86, и даже могу делать вещи типа

open F, '| ssh runner\@other_os perl > local_result.txt');

print F $generated_source_code;

что на си довольно затруднительно.

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

>А где например для Питона аналог CELLS взять ?

>http://common-lisp.net/project/cells/

Ну, в интересах поддержки захиревшего флейма и доведения числа постов до 1024: а почему библиотекописатели не лабают к своим либам биндинги к Lisp? Вот я хочу поставить Ogre3d "на поиграться", а у него нет биндингов к Лисп! :-P А к Питону - есть ;) Где вообще SWIG для Lisp?

2Zubok

> CELLS -- это такая надстройка над CLOS, но с таким функционалом, что позволяет делать вычисляемые слоты.

Ты, наверное, не всё говоришь. В чем проблема сделать вычисляемый слот средствами самого CLOS, зачем там еще и надстройка?

> Пример классической объектной rule-based системы.

Ну, не знаю. Как-то просто, непонятно, зачем аж целая надстройка. И где Rete? ;)

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

> а почему библиотекописатели не лабают к своим либам биндинги к Lisp?

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

> Где вообще SWIG для Lisp?

А что, его уже из SWIG-a выкинули?.. 8-О :)

> В чем проблема сделать вычисляемый слот средствами самого CLOS, зачем там еще и надстройка?

Чтобы ты не заморачивался с этим каждый рах сам, а взял котовый пакет :)

>> > Именно в последнее время проснулся интерес к интерпретируемым/байткодным.

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

>Ну, собственно, фишка с ними, имхо, в "запускаемом исходнике". Т.е. нету выделенного (интерфейсно) этапа компиляции

Ты сказал "интерпретируемый" другими словами :-P

По-моему, фишка именно в более высоком уровне при больше простоте использования - там, где на Си++ (тем более Java) нужна нудная писанина, на Питон/Ruby всего пара строк

> Ты сказал "интерпретируемый" другими словами :-P

Отсутствие _выделенного (интерфейсно) этапа компиляции_ не означает отсутствие компиляции (в натив) вообще. А это уже к интерпретируемым не относиться (имхо)

> По-моему, фишка именно в более высоком уровне при больше простоте использования - там, где на Си++ (тем более Java) нужна нудная писанина, на Питон/Ruby всего пара строк

Так было уже - с лиспом имеем и простоту использования, и компиляцию в натив (инкрементальную), да - в некоторых реализациях.

>> Где вообще SWIG для Lisp?

> А что, его уже из SWIG-a выкинули?.. 8-О :)

В SWIG у меня на машине - 2 диалекта Scheme: Guile и какой-то MzScheme. Ни одного из многочисленных Common Lisp'ов :-P

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

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

> Так было уже - с лиспом имеем и простоту использования, и компиляцию в натив

Воот, но волну интереса к динамическим и функциональным языкам подняли Python и Ruby :-P

> В SWIG у меня на машине - 2 диалекта Scheme: Guile и какой-то MzScheme. Ни одного из многочисленных Common Lisp'ов :-P

Что-то у тебя не так... И даже упоминания о cffi и uffi нет? Обновись ;)

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

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

> Воот, но волну интереса к динамическим и функциональным языкам подняли Python и Ruby :-P

Угу, это сродни "научно-популярной литературе" :)

> > Воот, но волну интереса к динамическим и функциональным языкам подняли Python и Ruby :-P

> Угу, это сродни "научно-популярной литературе" :)

Хотя нисколько не умаляю их вклада в это дело - сам пришёл к лиспу "через"питон :) Надо лишь отдать себе отчёт, что это не "венец творения", а робкая попытка приблизиться ;)Ь

>> В SWIG у меня на машине - 2 диалекта Scheme: Guile и какой-то MzScheme. Ни одного из многочисленных Common Lisp'ов :-P

> Что-то у тебя не так... И даже упоминания о cffi и uffi нет? Обновись ;)

А у тебя есть такое? Какая версия SWIG?

> Нафига "внутренняя механика либы" - достаточно (должно быть) доки и описания интерфейса.

"Теоретически, теория и практика - одно и то же. Практически они разные." (C) незнаюкто. А если учесть, что дока может быть неадекватно (или ее может не быть)...

> А у тебя есть такое? Какая версия SWIG?

$ swig.exe -version

SWIG Version 1.3.29

$ swig.exe -help
Target Language Options
     -allegrocl      - Generate ALLEGROCL wrappers
     -chicken        - Generate CHICKEN wrappers
     -clisp          - Generate CLISP wrappers
     -cffi           - Generate CFFI wrappers
     -csharp         - Generate C# wrappers
     -guile          - Generate Guile wrappers
     -java           - Generate Java wrappers
     -lua            - Generate Lua wrappers
     -modula3        - Generate Modula 3 wrappers
     -mzscheme       - Generate Mzscheme wrappers
     -ocaml          - Generate Ocaml wrappers
     -perl           - Generate Perl wrappers
     -php            - Generate PHP wrappers
     -pike           - Generate Pike wrappers
     -python         - Generate Python wrappers
     -ruby           - Generate Ruby wrappers
     -sexp           - Generate Lisp S-Expressions wrappers
     -tcl            - Generate Tcl wrappers
     -uffi           - Generate Common Lisp / UFFI wrappers
     -xml            - Generate XML wrappers
...

> А если учесть, что дока может быть неадекватно (или ее может не быть)...

Ха, и такому автору ещё и биндинг доверить? Нет уж - спасибо за библиотеку ;)

> Угу, это сродни "научно-популярной литературе" :)

> сам пришёл к лиспу "через"питон :) Надо лишь отдать себе отчёт, что это не "венец творения", а робкая попытка приблизиться ;)Ь

Это сродни применению наработок кабинетных ученых на практике.

> SWIG Version 1.3.29

Значит, добавили. Неплохо.

>> А если учесть, что дока может быть неадекватно (или ее может не быть)...

>Ха, и такому автору ещё и биндинг доверить?

Да, и сказать "спасибо" за работу. А неадекватная документация - это повсеместная проблема, в опенсорсе и в коммерции.

> Это сродни применению наработок кабинетных ученых на практике.

Ну, можно и так, только очень хочется спросить: "Если вы спёрли^Wскопировали форму конфетки - почему рецептом самой конфетки не воспользовались?" :)

>> Это сродни применению наработок кабинетных ученых на практике.

> Ну, можно и так, только очень хочется спросить: "Если вы спёрли^Wскопировали форму конфетки - почему рецептом самой конфетки не воспользовались?" :)

Ох уж мне эти аналогии... "Всякое сравнение хромает" -- (С) Немецкий народ. А у этого твоего сравнения - вообще ДЦП. Ни форму, ни обертку, ни рецепт ни Руби, ни Питон не копировали. Взяли то, что практично.

> Да, и сказать "спасибо" за работу. А неадекватная документация - это повсеместная проблема, в опенсорсе и в коммерции.

Ну, сказать "спасибо", слать багрепорты, а лучше - сразу патчи - святая обязанность :) А "повсеместная" лучше заменить на "не редкая" - не все же идут с неадекватной докой. Согласен. Это шутка была. Но я настаиваю на своём - биндинг - не дело "либописателя" (за исключением тех случаев, когда автор одинаково хорошо разбирается в обоих вещах).