[спец-ам]Надо ли знать C/C++ чтобы учить Lisp?

ТОЛСТО

Какой из Лиспов? :)

Для Scheme - нет. Хотя знать Си на базовом уровне полезно и для этого.

Языки не учат, языками овладевают.

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

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

Си знать надо, однозначно. C++ можно знать поверхностно, и желательно не иметь слишком уж глубокого опыта борьбы с его проблемами.

чтобы учить LISP надо уметь читать; хотя теоретически можно и по аудиокнигам освоить

>Языки не учат, языками овладевают.

пруфпик будет?

Спасибо. Значит C.

Сейчас будет сообщение, не примите за троллинг, но один знакомый тип вдруг заявил что будет изучать MASM - Microsoft Macro Assembler.

Говорит, что язык скриптов ERM (герои меча и магии 3.5) сложнее чем ассемблер.

>> Надо ли знать C/C++ чтобы учить Lisp?

Знать думаю не помешает, а вот привычка к C/C++ ИМХО сильно мешает.

P.S. Периодически ковыряю common lisp, но пока очень медленно, так как никак не могу выделить время чтобы и не занят был и мозги работали.

Сам ассемблер действительно не сложный. Сложны лишь алгоритмы программ на ассемблере. Кстати masm - УГ, лучший компилер для ассемблера это fasm.

>Говорит, что язык скриптов ERM (герои меча и магии 3.5) сложнее чем ассемблер.

Так ассемблер проще всех.

Он достал свой нефритовый стержень, и грязно овладел LISP-ом прямо в прихожей.

не стержень, а жезл!

а по сабжу, мне кажется, что лучше вообще не знать ни С ни С++. При овладевании лиспом они только мешают.

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

// wbr

>в конце-концов, Lisp ни чем не хуже коллекционирования бабочек или марок так что почему нет. кому что нравится.

Не могу удержаться).

Т.е. Вы намекаете на то, что прикладной пользы от Lisp'а не больше, чем от коллекционирования бабочек? Это 4.2. Причем жесточайшее.

> Вы намекаете на то, что прикладной пользы от Lisp'а не больше, чем от коллекционирования бабочек?

Он намекает, что в реальной жизни на Лиспе писАть не придется,

> Это 4.2. Причем жесточайшее.

И молодой паладин может привести список полезных вещей, которым может научить _только_ Лисп? ;)

>Он намекает, что в реальной жизни на Лиспе писАть не придется,

Я пишу. Я живу в нереальной жизни?)

>И молодой паладин может привести список полезных вещей, которым может научить _только_ Лисп? ;)

На вскидку таких, чтобы "_только Лисп_" -- не придумаю. Но, например, метапрограммирование наиболее приятно осваивать на Лиспе (думаю понятно почему?;))

> Он намекает, что в реальной жизни на Лиспе писАть не придется,

Откуда этому быдлу знать про реальную жизнь?

> И молодой паладин может привести список полезных вещей, которым может научить _только_ Лисп? ;)

defmacro.

>> Он намекает, что в реальной жизни на Лиспе писАть не придется,

> Я пишу. Я живу в нереальной жизни?)

За деньги и в команде? Если да, то ты одно из немногочисленных исключений.

> Но, например, метапрограммирование наиболее приятно осваивать на Лиспе (думаю понятно почему?;))

Не-а. Я его осваивал на lexx и yacc, когда оно еще не называлось "метапрограммированием". Ну и вообще интересно, чем качественно макросы Лиспа отличаются от какого-нибудь ocamlp4 или Nemerle (подозреваю, что ничем).

>За деньги и в команде? Если да, то ты одно из немногочисленных исключений.

Да. И с каждым днём таких "исключений" всё больше.

>Не-а. Я его осваивал на lexx и yacc, когда оно еще не называлось "метапрограммированием". Ну и вообще интересно, чем качественно макросы Лиспа отличаются от какого-нибудь ocamlp4 или Nemerle (подозреваю, что ничем).

Ocamlp4 и Nemerle не щупал, но подозреваю, что у них макры пишутся на чуть другом языке, нежели код. Лисповские же макры написаны на лиспе, и то, что можно делать вне макры, можно и внутри неё. Со всеми вытекающими...

> За деньги и в команде? Если да, то ты одно из немногочисленных исключений.

Думаю, тут таких "исключений" весьма немало наберётся.

> Не-а. Я его осваивал на lexx и yacc, когда оно еще не называлось "метапрограммированием".

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

> Ну и вообще интересно, чем качественно макросы Лиспа отличаются от какого-нибудь ocamlp4 или Nemerle (подозреваю, что ничем).

Тем, что ни в Nemerle, ни тем более в camlp4 нельзя определить макру и тут же ею воспользоваться для определения следующей макры.

В Лиспе метапрограммирование может быть сколь угодно многоуровневым, тогда как в Nemerle и в сторонних препроцессорах вроде camlp4 оно однопроходное.

В Nemerle это один и тот же язык. Все заморочки убраны в библиотеки работы с компилятором.

> Ocamlp4 и Nemerle не щупал, но подозреваю, что у них макры пишутся на чуть другом языке, нежели код. Лисповские же макры написаны на лиспе, и то, что можно делать вне макры, можно и внутри неё. Со всеми вытекающими...

В Nemerle макры пишутся на Nemerle, в CamlP4 - на OCaml. И quasiquotation там есть, и возможность прочитать AST (не так просто, как в Лиспе, но тоже более-менее доступно). Чего там нет, так это инкрементальной компиляции. В Nemerle надо скомпилировать макры в отдельную dll, и потом на эту dll ссылаться при компиляции кода, использующего эти макры. Нельзя, как в Лиспе, воспользоваться макрой сразу после её определения, ну а о локальных макрах не стоит даже и мечтать. Так что, возможности такого метапрограммирования очень ограниченны, максимум, что можно сделать (и что обычно и делают) - это добавлять новые примитивные конструкции в язык. Для серьёзной разработки DSLей этот подход не очень годится.

>> За деньги и в команде? Если да, то ты одно из немногочисленных исключений.

> Да.

Если это правда, то я рад за тебя.

> И с каждым днём таких "исключений" всё больше.

Смешно выразился :)

> Ocamlp4 и Nemerle не щупал, но подозреваю, что у них макры пишутся на чуть другом языке, нежели код.

В Немерле - на том же самом. Причем и синтаксис у него человеческий, а не Sexpr.

> то, что можно делать вне макры, можно и внутри неё. Со всеми вытекающими...

Ага, ага.

не, наврал. Там есть библиотеки И синтаксический сахар для макросов. Без сахара не взлетит.

> В Nemerle надо скомпилировать макры в отдельную dll, и потом на эту dll ссылаться при компиляции кода, использующего эти макры. Нельзя, как в Лиспе, воспользоваться макрой сразу после её определения, ну а о локальных макрах не стоит даже и мечтать. Так что, возможности такого метапрограммирования очень ограниченны

Мне это не кажется "очень ограниченным". Локальных макр нет - ну и что?

> Для серьёзной разработки DSLей

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

> И молодой паладин может привести список полезных вещей, которым может научить _только_ Лисп? ;)

ну "образ мышления - Форт" -- это вещь, которой в первую очередь может научить Форт. А в вторую -- лисп со смоллтоком, в последнюю -- какой-нибудь C/yacc. Наверное, и для скобочек что-то нативное есть.

В порядке упражнения, сделай на Nemerle что либо подобное примеру examples/ssheet/ssheet.al из MBase-0.6 (я знаю, что в принципе это возможно, только это будет заметно сложнее). На Схеме (с нормальным define-macro, конечно же) и на CL я такое легко могу сделать.

> Мне это не кажется "очень ограниченным". Локальных макр нет - ну и что?

Это от того, что ты не понимаешь, как пользоваться метапрограммированием.

Локальные макры - офигенно полезная технология, позволяет передавать информацию от одной макры к другой. Пример применения - eDSL для описания структуры данных, который генерит набор итераторов и визитёров для этой структуры (что гораздо удобнее чем pattern matching в Haskell или ML). Визитёр сам по себе определяется как макра, разворачивающаяся в код, содержащий локальные макры для определения структуры в каждом конкретном узле.

> Ну он позиционировался как язык общего назначения, а не для "разработки DSLей".

А DSLи везде и всегжа нужны. Более общей задачи сложно придумать.

> Причем и синтаксис у него человеческий, а не Sexpr.

Не особо человеческий - квазицитирование такое, что глаза в трубочку сворачиваются. С-выражения тут всё же гораздо проще.

> В порядке упражнения, сделай на Nemerle что либо подобное примеру examples/ssheet/ssheet.al из MBase-0.6

Ненене, я вяло осваиваю Окамл, а ты мне предлагаешь учить еще и MBase O_o

> На Схеме (с нормальным define-macro, конечно же) и на CL я такое легко могу сделать.

Анонимный брат, любую решаемую задачу можно решить более чем одним способом. Почему надо решать именно MBase-way?

>Причем и синтаксис у него человеческий, а не Sexpr.

В случае, когда работаешь с метапрограммированием, синтаксис только мешает.

Да и в остальных случаях _лично мне_ S-expr's наиболее удобны.

>синтаксический сахар для макросов. Без сахара не взлетит.

От сахара кариес бывает.

> Ненене, я вяло осваиваю Окамл, а ты мне предлагаешь учить еще и MBase O_o

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

> Анонимный брат, любую решаемую задачу можно решить более чем одним способом.

Некоторые способы намного проще всех остальных.

Традиционный Лисповский подход (инкрементальная компиляция) намного проще чем раздельная компиляция, и намного интуитивно понятнее. Отсутствие ограничений всегда почти лучше, чем их наличие.

Задумайся, почему в этой книге используется именно Лисп, а не какой либо ещё язык:

http://www.umcs.maine.edu/~chaitin/cup.pdf

>> Причем и синтаксис у него человеческий, а не Sexpr.

> В случае, когда работаешь с метапрограммированием, синтаксис только мешает.

А правила дорожного движения не мешают тебе ходить по улицам? Шутка, можешь не отвечать.

Для Ъ процитирую пример здесь:

(ssheet fact ( n -> A1 )
        	 A                              B
   1  "if (B2) then lazyref(B1) else 1"    "lazy(n*fact(A2))"
   2  "n-1"                                "n>1"
)

> В порядке упражнения, сделай на Nemerle что либо подобное примеру examples/ssheet/ssheet.al из MBase-0.6 (я знаю, что в принципе это возможно, только это будет заметно сложнее)

в детстве писал excel-подобный калькулятор на Turbo Pascal 5.5. У меня были определения функций, текстовый UI. Исходников было явно не на 5 Кб, как в MBase на лиспе, что-то килобайт на 20-50. И то, ленивостью в функциях естественно не пахло, стек можно было обвалить в первой версии, ну и стандартные заморочки вроде "сколько файлов надо перетряхнуть для добавления новой функции в интерпретатор".

> От сахара кариес бывает.

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

> Задумайся, почему в этой книге используется именно Лисп, а не какой либо ещё язык:

> http://www.umcs.maine.edu/~chaitin/cup.pdf

Это ясно из Acknowledgements - 1975, 1987, дальше куча ссылок на работы 70-х... тогда кроме Лиспа ничего распространенного и не было (Prolog и ML не катят для целей книги, как я понимаю).

Spreadsheet вообще написать очень легко. Интереснее сделать встраиваемый в код spreadsheet. Хотя, конечно же, это извращение, пусть и прикольное.

Но именно такие извращения показывают пределы возможностей языка.

> тогда кроме Лиспа ничего распространенного и не было (Prolog и ML не катят для целей книги, как я понимаю).

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

> показывают пределы возможностей языка.

да-да. Потом, макры -- это функции высокого порядка, описание спредшита -- это спецификация не только для калькулятора функций, но и GUI. И сгенерированный код как исполняемая модель, сразу по готовой спецификации, одна точка изменений для расширения/доработки.

> да-да. Потом, макры -- это функции высокого порядка, описание спредшита -- это спецификация не только для калькулятора функций, но и GUI. И сгенерированный код как исполняемая модель, сразу по готовой спецификации, одна точка изменений для расширения/доработки.

...а потом программы начинают писать сами себя и крутого лиспера увольняют. за ненадобностью. и в чём профит :-?

// wbr

> ...а потом программы начинают писать сами себя и крутого лиспера увольняют. за ненадобностью. и в чём профит :-?

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

>> тогда кроме Лиспа ничего распространенного и не было (Prolog и ML не катят для целей книги, как я понимаю).

> Почему же? Вполне катят. Более ранние работы Колмогорова по этой теме вообще были на основе машины Тьюринга.

<quote>I beleive that the best way to actually program a universal Turing machine is John McCarthy’s universal function EVAL</quote>

> Однако же, при всём богатстве выбора,

Не было тогда богатства выбора. По-моему, Пролог и ML вообще не упоминаются (хотя есть REXX :)).

> Не было тогда богатства выбора. По-моему, Пролог и ML вообще не упоминаются (хотя есть REXX :)).

Пролог уже существовал. И вполне мог бы подойти как универсальный язык для записи информации. Но - увы, увы, Лисп оказался универсальнее.

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

Нахрена интеллекту наладчики? %) Сам справится. УВЧ, короче говоря :D

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

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

// wbr

> Пролог уже существовал.

Пролог выбрался за пределы Марселя в конце 70-х, к тому времени Цейтин уже подсел на Лисп :) А менять Лисп на Пролог смысла нет, конечно.

> Нахрена интеллекту наладчики? %)

А на хрена живому интеллекту столько наладчиков? Психологи, психиатры, менеджеры, лайф-коучи, и т.п.

> Сам справится. УВЧ, короче говоря :D

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