CL

> Закончились аргументы? Неожиданно...

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

>Обёртка на лиспе для DirectX. 16000 строк. Ох*еть.
Так мало это потому, что на лиспе, потому что макросы. Большая часть - буквальный перевод майкрософтовских хидеров в s-выражения.

Впрочем, вот это: http://love5an.livejournal.com/profile очень многое объясняет.

Что-то не нравится? :)

> Так мало это потому, что на лиспе, потому что макросы.

«Мало»? Это такой тонкий йумор?

Знаешь, сколько занимают биндинги, скажем, для языка Vala к GStreamer и OpenGL, вместе взятым? Девять тысяч строк. И это безо всяких макросов. Даже если сюда добавить SDL, то получится одиннадцать тысяч. И то их авторы бОльшей частью даже не пейсали, а генерировали автоматически. Вот это я понимаю — образцовый юз-кейс метапрограммирования и кодогенерации, и безо всяких извращений.

Ладно, чёрт с тобой... Ты скажи, ты под чем был, когда задумывал обернуть DirectX в лисп? :) Гамез, что ли, вздумал на лиспе запилить? Имхо если бы речь шла, скажем, о научной визуализации, тебе бы хватило и OpenGL за глаза.

> Не забудь опубликовать результаты ...

Вряд ли, не интересно и лор это не то место, где есть желание что-то обсуждать. Тут нормально спросить что-нибудь, а не дискутировать. :-)

Но согласись, значит, на разводку ты всё-таки повёлся? Раз решил проверить, а вдруг действительно лисп таков, как о нём проповедуют адепты?

Я даже не знаю, как тебе ответить. Про лисп я узнал, когда мне понравился emacs, сказать, что мне понравился лисп это неправда. Я чего-то там правил по мелочам, но никогда не испытывая от этого никакого удовольствия. Интерес же к лиспу появился, когда стал прислушиваться к объяснениям здесь про его макросы и возможность менять семантику языка, идея метапрограммирования мне всегда была симпатична, а имея некоторый опыт в этой области, хочу его обогатить.

>«Мало»? Это такой тонкий йумор?
Советую посмотреть объем кода для аналогичных частей DX(небольшая часть winapi, DXGI, D3D10, D3DX10) в SlimDX(тоже похожий биндинг к DX, но на C# написанный).

Знаешь, сколько занимают биндинги, скажем, для языка Vala к GStreamer и OpenGL

Обосраться и не встать.
ср. «Знаешь, сколько занимают биндинги CL к GMP?»

Ты скажи, ты под чем был, когда задумывал обернуть DirectX в лисп?

У разного говна есть биндинги, почему бы и для такого крутого языка, как CL, не сделать?

Потом можно написать игровой движок, к примеру.

> Представители ФП-сообщества относят Scheme к ФЯП.

а представители scheme-сообщества не столь категоричны в этом вопросе. кому верить?

Следовательно, CL (как язык, существенно не отличающийся от Scheme)

ты-то в теме, ага

> - «чистые» функции;

все функции? а то чистые функции практически на любом императивном языке писать можно

- рекурсия;

конкретней, а то тоже почти все императивные поддерживают рекурсию

- системы типов

опять же конкретней нужно

анонимус такой троллонимус. Ну ни как не пройдет мимо темы о лиспе, надо кирпичами посрать непременно.

> Какое отношение «функциональщина» имеет к CL? Сколько вообще уже можно уже, что Common Lisp не является функциональным языком?

Тому анонимусу, наверное, кто-нибудь на ногу наступил из функциональщиков. Или сразу на больную мозоль. А может быть, он стал жертвой «попыткы утереть нос быдлокодерам на работе и предложить ПМ-у решать задачу на CL». Всякое возможно.

Но независимо от этого, я все же не согласен с тобой и считаю, что CL - вполне функциональный язык. В нем нет разве что вывода типов, типоклассов и сопоставления с образцом. Первые два не особо то и нужны, а иногда они даже через чур ограничивающие (как создать гетерогенный список? - в лиспе легко). Паттерн-матчинг же нужен хаскелю и ML, потому что у них нет s-выражений и destructuring-bind. То есть, и без него можно жить. Более того, я считаю, что эти свойства не являются существенными для функциональной парадигмы. Не в них суть.

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

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

>Сколько вообще уже можно уже, что Common Lisp не является функциональным языком?

Нет, мультипарадигмальным: объектно-ориентированным, функциональным, императивным.

То есть и функциональным в том числе.

>> Представители ФП-сообщества относят Scheme к ФЯП.

а представители scheme-сообщества не столь категоричны в этом вопросе. кому верить?

Пущай они уже определяются, ато я не знаю как javascript позиционировать.

>> - «чистые» функции;

все функции? а то чистые функции практически на любом императивном языке писать можно

<telepaty>Похоже имелись в виду замыкания</telepaty>

Чтож ты за мудак-то такой, уж не tia ли в костюме анонимуса? А ну свали отсюда, скотоложец.

Ололо. Какие к чорту замыкания. Чистая функция - это такая функция, которая всегда даёт один и тот же результат для одного и того же набора входных значений. time() - не чистая функция.

Я от последней наркотической зависимости(никотин) избавился в октябре еще.

o_O А бухать-то, бухать не бросил?!

>Сочувствую,...

надеюсь, ты догадался. что я про «местные» 3 звезды? =]

Я смотрел раздел «Реализующие Common Lisp»

ну не трудно-же по ссылке каждой реализации лиспа (может тот-же гугл их знает больше) перейти на «домашнюю страницу» и посмотреть специфику?

Насчёт вопроса по документации, я читал разные реализации по-разному какие-то вещи в стандарте имплементировали

все стараются от стандарта отходить как можно меньше (в смысле, расширять - можно, «сужать/изменять» - ни-ни, «недореализовывать» - очень плохо) и, соответственно, собственную документацию делают только по отличиям от стандарта, и получается она всяко много меньше CLtL и/или HyperSpec

я пока не знаю, насколько большие различия есть и есть ли они, поэтому и вопрос возник.

По основным нестандартным различиям (FFI, сокеты и прочее) есть унифицирующие библиотеки.

>Ололо. Какие к чорту замыкания. Чистая функция - это такая функция, которая всегда даёт один и тот же результат для одного и того же набора входных значений. time() - не чистая функция.
Чистая функция - это функции, не имеющие побочных эффектов, так точнее. А замыкания тут действительно не при чём.

дык это, какой этанол наркотик, это же растворитель обычный :)
тут надо говорить о токсикомании

таки да, вообще говоря, надо бросать

> Но независимо от этого, я все же не согласен с тобой и считаю,

что CL - вполне функциональный язык.

В SICP рассматриваются две модели вычислений: подстановочная и модель вычислений с окружением. Так же в SICP есть размышления на тему того, что «подстановочная модель вычислений» имеет большие преимущества, просто она не всегда применима на практике. Это можно рассматривать как основной критерий для оценки принадлежности языка к ФП. И, например, haskell пытается во всю эксплуатировать те преимущества, которые предоставляет подстановочная модель, при этом, правда, обладая тем интересным свойством, что предоставляет доступ к другим моделям вычислений через монады. Дизайн же Common Lisp кажется хочет опровергнуть утверждение о том, что подстановочная модель даёт существенные преимущества и предлагает чрезвычайно развитую модель вычислений с окружением. Т.е. с точки зрения используемой модели вычислений Common Lisp является полной противоположностью ФП.

Другой моментом, который достаточно глубоко рассматривается в SICP - это подходы к декомпозиции, которых известно два: на основе потоков и объектная (не путать с ООП). ФП неразрывно связано с декомпозицией на основе потоков, а Common Lisp совершенно явно стимулирует объектную декомпозицию.

Т.е. хотя на Common Lisp и можно писать в функциональном стиле (это также можно делать и на С++, а на Haskell можно заниматься ООП), но по своей сути дизайн Common Lisp глубоко противоречит принципам ФП.

> Чтож ты за мудак-то такой, уж не tia ли в костюме анонимуса? А ну свали отсюда, скотоложец.

Нет, tia так тупо не троллит. Он просто слишком привязан к «интуитивному» синтаксису.

>Какие к чорту замыкания.

Вместо «чистые функции» прочитал «чисто функции», вот и подумал что чтото тут не то...

> Это можно рассматривать как основной критерий для оценки принадлежности языка к ФП.

а как же, например Алгол (не помню который точно), который широко использовал вызов по имени? в «Практике ФП», вроде 1-й выпуск, упоминали об этом.

>> Т.е. хотя на Common Lisp и можно писать в функциональном стиле (это также можно делать и на С++, а на Haskell можно заниматься ООП), но по своей сути дизайн Common Lisp глубоко противоречит принципам ФП.

Забыл добавить слово IMHO?. Вообще странно, что язык в котором само понятие ФП была реализована раньше всех вдруг стал противоречить ФП. Строить рассуждения по типу «если не так как в хаскеле, то не ФП» - глубочайшая ошибка.

> Забыл добавить слово IMHO?

Нет, не забыл.

Вообще странно, что язык в котором само понятие ФП была реализована

раньше всех вдруг стал противоречить ФП.

Вы о каком языке говорите? Я о Common Lisp, который появился в 1984 году.

Строить рассуждения по типу «если не так как в хаскеле,

то не ФП» - глубочайшая ошибка.

Я использую два основных критерия: модель вычислений и подход к декомпозиции, при чём тут haskell?

> В SICP рассматриваются две модели вычислений: подстановочная и модель вычислений с окружением. Так же в SICP есть размышления на тему того, что «подстановочная модель вычислений» имеет большие преимущества, просто она не всегда применима на практике. Это можно рассматривать как основной критерий для оценки принадлежности языка к ФП.

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

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

Мне кажется, что основная черта ф.п. - это функции высшего порядка. Такая тавтология получается. Плюс замыкание. И, конечно, это предполагает gc за кулисами...

Вот, возьмем знаменитую статью Филиппа Вадлера «Сущность функционального программирования», посвященную монадам. Монады строятся через функции высшего порядка. Там же используется замыкание. Если есть эти две вещи, то можно построить и использовать монады. В лиспе это возможно. Значит, язык вполне функционален. Впрочем, с такой позиции многие современные языки можно назвать функциональными. Но не везде это развито так как в лиспе и окамле или, тем более, в хаскеле.

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

чистые функции практически на любом императивном языке писать можно

и как проверить чистоту функции на «любом императивном языке»? толку от чистоты, если она ничем не гарантирована

> Тогда по-твоему хаскель действительно является ф.п. языком,

а вот окамл - нет. Противоречие.

В чём противоречие? OCaml кажется и не претендует на чистоту... Впрочем, я совершенно не разбираюсь в OCaml.

Потоки - это, кажется, бесконечный ленивый список,

но до этого места я еще не дочитал :)

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

Мне кажется, что основная черта ф.п. - это функции высшего порядка.

JavaScript, Lua, .. о ужас, Perl... - это всё ФЯП? Тогда в ближайшее время останется только один не ФЯП - С. Впрочем, это проясняет многие аргументы о превосходстве ФЯП над другими языками, коих остался только один гы :))

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

Но сейчас есть тенденция притянуть к атрибутам ф.п. вывод типов

и паттерн-матчинг. Мне кажется, что это уже неправильно.

Как раз очень правильно. Ибо эти свойства возможны именно из-за акцента на подстановочную модель вычислений и в развитом ФЯП обязательно должны присутствовать.

>> Я использую два основных критерия: модель вычислений и подход к декомпозиции, при чём тут haskell?

Так сам же сказал, что в лиспе не так как в хаскеле, значит лисп не ФП: "... например, haskell пытается во всю эксплуатировать те преимущества, которые предоставляет подстановочная модель... ".

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

Из этого есть два инетересных вывода:
1. Хаскель реализует обе модели.
2. CL реализует обе модели.

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

> Так сам же сказал, что в лиспе не так как в хаскеле,

значит лисп не ФП

Я такого не говорил, я привёл Haskell как пример ФЯП.

Почему модель вычислений с подстановкой относит тот или иной язык

к ФП? Потому, что модель с окружениями не даст ничего нового для

чистого ФЯП, а реализуется сложнее подстановочной.

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

Из этого есть два инетересных вывода:

1. Хаскель реализует обе модели.

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

2. CL реализует обе модели.

С чего вдруг и каким это образом?

>> В чём противоречие? OCaml кажется и не претендует на чистоту...

Противоречие в том, что есть языки с поддержкой парадигмы ФП, и чистые ФЯП. И приверженцы второго лагеря с пеной у рта доказывают, что только чистые ФЯП имеют право называться функциональными.

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

Блин, покажи мне язык в котором нельзя написать функцию/процедуру, значение которой зависит только от входных параметров.

>> Не понял, подстановочная модель обеспечивает наличие функций в математическом плане

Не так, она не дает возможность создавать все остальные типы функций.

А модель вычислений с окружением этому препятствует и матан отдыхает.

Ни разу не препятствует. Ты же читал SICP, там половина примеров - чистые функции.

Точнее следует сказать, что в Haskell существует механизм, позволяющий использовать любую модель вычислений, но при этом основной акцент сделан на подстановочной. [...] С чего вдруг и каким это образом?

Перефразирую тебя же «в CL существует механизм, позволяющий использовать любую модель вычислений».

> Противоречие в том, что есть языки с поддержкой парадигмы ФП

Блин, покажи мне язык в котором нельзя написать функцию/процедуру,

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

Я правильно понимаю, что Fortran также поддерживает ФП? Тогда вообще о чем разговор?

Ни разу не препятствует. Ты же читал SICP,

там половина примеров - чистые функции.

Ну и что? Опять вспоминаем про Fortran... Чистое ФП позволяет использовать серьёзную математическую теорию для анализа код. И говорить сейчас о ФП имеет смысл только в этом плане: можно ли привлечь «суровый матан» для анализа кода на данном языке. В случае с haskell - ответ утвердительный, в случае с Scheme - нет.

>> Я правильно понимаю, что Fortran также поддерживает ФП? Тогда вообще о чем разговор?

Цитата: «Нет, термин ФП подразумевает наличие функций в математическом понимании.»

И говорить сейчас о ФП имеет смысл только в этом плане: можно ли привлечь «суровый матан» для анализа кода на данном языке.

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

Чистое ФП позволяет использовать серьёзную математическую теорию для анализа код.

Ничего сложнее доказательства св-в функций по индукции там нет.

>> Чистое ФП позволяет использовать серьёзную математическую теорию

Императивщина тоже имеет под собой серьезную математическую теорию

Он не указывает, он просит указать. Лисперы не видят разницы?

> Таки у тебя есть определение термина «функциональный язык

программирования» или нет? То критерий у тебя модели вычислений с

потоками, то возможность анализировать код ср-вами сурового матана.

Я с самого начала указал их два. А «возможность анализировать код ср-вами сурового матана» является следствием подстановочной модели вычислений. Что непонятного? А в CL всегда используется модель вычислений с окружением, не зависимо от того, как реально написана функция и что о ней думает программист.

Императивщина тоже имеет под собой серьезную математическую теорию

И какой из этого следует сделать вывод?

>> И какой из этого следует сделать вывод?

Можно применить «суровый матан» для анализа кода.

Я с самого начала указал их два. А «возможность анализировать код ср-вами сурового матана» является следствием подстановочной модели вычислений. Что непонятного?

см. выше.

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

Подстановочная модель - частный случай модели с окруженими, когда эти окружения пустые. Берем схему, берем force/delay, забываем про set!/set-car!/set-cdr! Вуаля! Ничего кроме подстановочной модели и потоков не осталось.

ЛОР ТОРТ.

Ладно, очень глубокие рассуждения. Только в чём заключается мысль? Что все существующие языки являются ФЯП? И такой наводящий вопрос, является ли C объеткно-ориентированным языком программирования, раз для него есть GObject? И кстати, можно ссылку на какой-либо реальный код на Common Lisp написанный в функциональном стиле?

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

> В чём противоречие? OCaml кажется и не претендует на чистоту... Впрочем, я совершенно не разбираюсь в OCaml.

Окамл совершенно не чист. Противоречие в том, что в окамле тоже используется модель с окружением, но он при этом - ф.п. Просто между подстановочной моделью и _чистым_ функциональным языком программирования можешь ставить знак эквивалентности. Одно следует из другого.

JavaScript, Lua, .. о ужас, Perl... - это всё ФЯП? Тогда в ближайшее время останется только один не ФЯП - С. Впрочем, это проясняет многие аргументы о превосходстве ФЯП над другими языками, коих остался только один гы :))

Разве в JavaScript есть функции высшего порядка, и язык поддерживает замыкание? А вообще, в ф.п. нет ничего экзотического. Парадигма проста как сама математика. Но не во всех языках есть удобная поддержка ф.п. Вот, в чем проблема. Например, шарповские делегаты с трудом можно назвать заменой функций. Аналогичные проблемы в других языках. В этом плане лисп выглядит намного приятнее и продвинутее многих других языков. И как всегда, дьявол кроется в деталях. Например, в питоне лишь однострочные лямбды... Непонятно, смеяться или горевать? ;)

Нет, термин ФП подразумевает наличие функций в математическом понимании.

В матаматическом понимании функции чисты. Я же говорю о ф-циях высшего порядка типа REDUCE. Есть разница.

>Только в чём заключается мысль? Что все существующие языки являются ФЯП?

Что очень многие языки в той или иной степени поддерживают ФП. Но «чситый» - да, хаскел и Co.

> Разве в JavaScript есть функции высшего порядка,

и язык поддерживает замыкание?

Конечно.

Что очень многие языки в той или иной степени поддерживают ФП.

Что не делает их ФЯП.

Конкретно, в Common Lisp нет ничего такого, что выделяло бы его возможности ФП по сравнению с многими другими языками, типа: JavaScript, Lua и т.д., которые никогда никто с ФП не связывает.

И ещё, на Common Lisp просто не пишут в функциональном стиле. Даже пресловутые map и reduce встречаются в реальном коде весьма редко, и при этом вместо них обычно более практично, выразительно и т.п. использовать глубоко императивную библиотеку iterate.

>Что не делает их ФЯП.

Ну да - их мультипарадигменными называют ;)

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

Ну вопервых пользоватся декораторами(они и придуманы для восполнения этого упущения).

Разве в JavaScript есть функции высшего порядка, и язык поддерживает замыкание?

JavaScript ВНЕЗАПНО такой же функциональный язык как и Scheme и OCaml.

> и как проверить чистоту функции на «любом императивном языке»? толку от чистоты, если она ничем не гарантирована

а в окамле чистоту как-то можно проверить?

а в CL? а то анонимус-то приводил критерии в попытках доказать, что лисп такой же ФЯП, как и хаскелл

я и указал, что критерии эти несколько расплывчаты

а в окамле чистоту как-то можно проверить?

я не пишу на окамле, так что не скажу. но скорее всего - нет

я и указал, что критерии эти несколько расплывчаты

дык кто ж спорит-то?