За что не любят Common Lisp?

Чем что на сишечке?

qsort

Это заметно.

а это плохо? Зачем это понимать?

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

ну это смотря как посмотреть на эту функцию. Давайте что-ли мне примеры алгоритмов, которые «ничего не вычисляют», и функций «алгоритмически невычислимых».

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

в рамках алгебры 6го класса - вполне даже и «лепо». Например рассмотрите тождество квадратов разности с т.з. тождества алгоритмов вычисления. Т.е. это тождество даёт нам два алгоритма, которые хотя и разные, но дают один и тот же результат.

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

ага. Это ответ на вопрос «что за бред?».

А на аватарке у тебя тоже лисп изображен?

А на аватарке у тебя тоже лисп изображен?

Знак свыше.

это тебе так кажется. Просто ты знаешь, что такое «п-большое», и знаешь, как считать произведение 1*2*3...

Очевидно, ты тоже должен знать, как делать A*B. А так, да, факториал можно задать и системой из четырех: x! = {x - целое, x>=0, if x<2 -> 1, -> x * (x-1)!

К сожалению, данная формула (n!=n*(n-1)!) мало годна для практики, ибо требует n ячеек дополнительной памяти.

То есть ты и сам признаешь, что выкатил чисто схемное решение с чисто схемной оптимизацией. Как ты после этого смеешь утверждать, что привел обычную математическую формулировку? Если бы ты написал что-то вроде

(defun fac (x)
 (if  (>= x 0) 1 (* x (1- x))))

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

ты не понял - любая итерация это рекурсия, но не любая рекурсия - итерация.

Ну как же, опять всем в CS вдалбливали эти простые истины, а ты чем-то другим занимался, наверное SICP читал. На {},if,goto ты можешь сам реализовать абстракции вида функция, а если постараешься - и сопрограмму замутишь!

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

Хвостовая рекурсия в схеме(!) сводится к итерации. В clisp она не свелась к итерации. Теоретически же любую рекурсию можно развернуть в итерацию.

разве что с помощью костыля, из массива N временных значений контекста.

Вот, ты уже начинаешь понимать.

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

И это можно сделать вручную.

Что касается ХР, то тут нет ничего сложного - при входе в ХР сохраняется адрес возврата, и одни и те же переменные, которые _не_ используются после выхода(т.к. рекурсия хвостовая).

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

Очевидно, ты тоже должен знать, как делать A*B. А так, да, факториал можно задать и системой из четырех: x! = {x - целое, x>=0, if x<2 -> 1, -> x * (x-1)!

мы A*B уже считаем определённым. умножение - тривиальная операция, определять её не имеет практического смысла. То, что число целое и больше нуля - ну у нас простой пример, мы иначе просто не можем.

К сожалению, данная формула (n!=n*(n-1)!) мало годна для практики, ибо требует n ячеек дополнительной памяти.

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

при чём тут схема? в таком виде формула не годится для любого ЯП, именно по причине наличия временного массива. Т.е. если буквально следовать формуле, надо:

1. создать массив [6,5,4,3,2,1]

2. посчитать произведение с конца массива до начала.

Где и как хранить массив - не играет роли.

Сишный вариант с циклом тоже не очень катит на математическое определение в силу его императивности.

катит. можно написать с malloc(x*sizeof(int)) и в две фазы. Но зачем?

Ну как же, опять всем в CS вдалбливали эти простые истины, а ты чем-то другим занимался, наверное SICP читал. На {},if,goto ты можешь сам реализовать абстракции вида функция, а если постараешься - и сопрограмму замутишь!

да я в курсе. в brainfuck'е так вообще всего один условный переход вперёд + один безусловный возврат назад. Дело-то совсем не в этом.

Хвостовая рекурсия в схеме(!) сводится к итерации.

не только в схеме. В любом достаточно мощном компиляторе.

В clisp она не свелась к итерации.

это интерпретатор. Вот и не свелась. Там есть режим компиляции, но я не в курсе про его мощность.

Теоретически же любую рекурсию можно развернуть в итерацию.

разве что при наличие памяти, размер которой пропорционален числу итераций.

Вот, ты уже начинаешь понимать.

см. выше, про n! - я это с самого начала тебе объясняю. В конце концов - рекурсия, это тоже итерация, когда у тебя есть стек, для хранения контекстов, и ты его используешь. Свёртка рекурсии в цикл - исключение стека с контекстами. Частный случай - TCO.

И это можно сделать вручную.

TCO можно делать вручную, никто же не спорит. Вопрос - а нужно-ли?

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

не только схемка, но и сишечка.

Clojure?

Код не разделен с данными. Это все портит.

Меня, увы, не покидает ощущение поповщины (продвинутой, правда, поповщины)...

Код не разделен с данными. Это все портит.

это не баг, а фича. (только криво реализованная. Кроме как для подключения плагинов без рестарта ни к чему не годна).

Лучше бы этого не было...

Из ФП я выбрал для себя Scala на данный момент. Самый практичный ЯП для JVM/.Net сейчас.

при чём тут схема? в таком виде формула не годится для любого ЯП, именно по причине наличия временного массива.

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

да я в курсе. в brainfuck'е так вообще всего один условный переход вперёд + один безусловный возврат назад. Дело-то совсем не в этом.
см. выше, про n! - я это с самого начала тебе объясняю. В конце концов - рекурсия, это тоже итерация, когда у тебя есть стек, для хранения контекстов, и ты его используешь. Свёртка рекурсии в цикл - исключение стека с контекстами. Частный случай - TCO.

Вот ты и прозрел, итак я еще раз повторяю свое утверждение: любую программу мужно записать на {},if и goto - теперь, как я понимаю, ты с ним согласен.

TCO можно делать вручную, никто же не спорит. Вопрос - а нужно-ли?

Не только TCO, любую рекурсию можно развернуть в цикл. Иногда автоматически, иногда вручную. Нужно?.. Ну, иногда нужно. Итерация обычно эффективней рекурсии, да и запись часто проще. Вот схемный вариант обычной рекурсии- простой, с хвостовой (и аккумулятором) - сложней. Если ты внимательно читал SICP, то должен был видеть примеры, когда сложные рекурсивные функции разматывают в портянки хвостовой рекурсии. И это ради сферической идеи использовать хвостовую рекурсию вместо более наглядного цикла (я не знаю, есть ли он вообще в схеме).

разве что при наличие памяти, размер которой пропорционален числу итераций.

Так ведь вызов функции так и работает.

это интерпретатор. Вот и не свелась.

Интерпретатор, компилятор... А какая разница?:) Я, написавши несколько компиляторов и интерпретаторов, с уверенностью могу сказать, что граница чертовски размыта и оптимизировать рекурсию можно в обоих случаях.

Лучше бы этого не было...

тогда-бы LISP был-бы давно мёртв. Со всеми производными. Это единственное, что держит данное зомби в условно-живом состоянии.

ну это смотря как посмотреть на эту функцию.

Если уж прозвучало «математическая функция», то так и следует рассматривать. ;)

Давайте что-ли мне примеры алгоритмов, которые «ничего не вычисляют»

Для машины Тьюринга с алфавитом A={a} и множеством состояний Q={q}:

qa→qaN

и функций «алгоритмически невычислимых».

Решение произвольных диофантовых уравнений; поиск колмогоровской сложности; задача остановки; задача единичной матрицы и еще десяток-другой.

ага. Это ответ на вопрос «что за бред?».

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

Из ФП я выбрал для себя Scala на данный момент. Самый практичный ЯП для JVM/.Net сейчас.

Тут надо быть поаккуратнее с терминами. Scala - это не только (и не столько) ФП. Весь цимес в том, что Scala является гибридным языком, вобрав в себя множество плюшек и фишек.

Этим и обусловлена практичность Scala.

При том, что ты не записываешь математическое определение факториала, ты реализуешь его на конкретном языке!

как-же «не записываю»? n! = c*(n-1)!; c++ (где c0 <= 1, 0! <= 1, c<=x). т.е. тоже умножаю, но наоборот. Варианты в виде ФП для сишечки и для CL я привёл, вариант цикла на сишечке - тоже.

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

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

Всякие разные оптимизации - дела компиляторов и программистов, математикам до балды

тут простой пример, и несложно доказать, что последовательность 6,5,4,3,2,1 эквивалентна 1,2,3,4,5,6 (переместительный закон умножения же), но в общем случае доказать это сложно даже математику. Оптимизации до балды, но вот сам алгоритм ломать нельзя.

Вот ты и прозрел, итак я еще раз повторяю свое утверждение: любую программу мужно записать на {},if и goto - теперь, как я понимаю, ты с ним согласен.

я с этим никогда и не спорил. проблема в другом: то, что _можно_ записать - это конечно радует. Вот только никто не знает _как_ это делать. А вот ХР - особый случай: тут не только _можно_, но и известно - как это сделать.

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

вот ты так и не развернул мне рекурсию в qsort...

разве что при наличие памяти, размер которой пропорционален числу итераций.

Так ведь вызов функции так и работает.

угу. почти. Бесконечный цикл работает бесконечно, бесконечная рекурсия мгновенно сегфолтится. Они эквивалентны только в сферическом вакууме при бесконечном стеке.

Интерпретатор, компилятор... А какая разница?:) Я, написавши несколько компиляторов и интерпретаторов, с уверенностью могу сказать, что граница чертовски размыта и оптимизировать рекурсию можно в обоих случаях.

разница в том, что CL вообще ничего не оптимизирует. (для интерпретатора это нормально. Для компилятора - странно. Хотя конечно оптимизирующий интерпретатор - годная вещь).

Что у вас тут новенького?

Да всё то же самое, только ещё унылее, чем раньше :)

Уж я бы тряхнул стариной

старину аккуратнее нужно трясти :)

Именно!

Если уж прозвучало «математическая функция», то так и следует рассматривать.

ну да - исключительно с позиций матанализа. «произведение ОО на ОЗ с однозначностью». довольно узкое толкование, ну да ладно, как скажете.

Давайте что-ли мне примеры алгоритмов, которые «ничего не вычисляют»

Для машины Тьюринга с алфавитом A={a} и множеством состояний Q={q}: qa→qaN

если я правильно понял, то на си это

while(1)
    ;

;

и функций «алгоритмически невычислимых».

Решение произвольных диофантовых уравнений; поиск колмогоровской сложности; задача остановки; задача единичной матрицы и еще десяток-другой.

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

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

это лор, тут так принято. да, я тоже уже отсюда уходил... Только хуже стало. Факт в том, что для меня функция === алгоритм, это не аксиома и не теорема, это просто точка зрения. И она имеет право на жизнь, ибо ваша т.з. мне ничего на практике не даёт полезного.

а где здесь «функция»?

вообще-то диофантово уравнения - это целочисленная функция

P(x0, x1, ... , xn) = 0

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

Функцианальщики - это секта. Типа секс-меньшинств - пруф http://en.wikipedia.org/wiki/Gay_lisp

while(1)
;

или даже
;

тебе сказать про разницу или сам поймешь?

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

иди в каждый тред про ФП поднасри, благо их много.

Сектанты сами себе поднасирают.

В реальные проекты функцианальщиков не берут - дабы г@вно за ними подчищать не пришлось.

«Как раз после того как это существо выперли из библиотеки занюханного провинциального НИИЧАВО, откуда он на весь LOR тявкал, он отчаянно пытался найти работу программистом. К нам вот приходил на собеседование, претендовал на роль Java-программиста. Junior, конечно же. Это был цирк! Попросил его написать метод, разворачивающий строку, классическая такая проверка на вшивость. Мелкое тощее горбатое существо с рожей и голосом профессионального алкаша бубнило и булькало чтото с полчаса, ничего родить не смогло, потом начало втирать, что вот зато в мегаязыке Хаскель строки сделаны односвязными списками и что это типа тру, а все остальное ламеризм. Еще чтото втирал что кулькакеры на Вакс использовали мегаформат для строк ASCIID, а ламеры не поняли и теперь везде позорный ASCIIZ (внимание: собеседование вообще про Java было). Угадайте - мы его взяли?» (с) [ЖЖ] Луговский

Оно конечно очень интересно с практической точки зрения.

Ага, deadlock называется.

а где здесь «функция»?

Про CH, который изоморфизм, я тебе уже ссылку давал. Теперь надо бы дать ссылку про CT, который тезис.

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

Не очень-то оно и тру, реально всё равно используются байтомассивы, utf на байтомассивах и stringbuilderы (1, 2, 3).

если я правильно понял, то на си это

Правильно (в некотором приближении).

т.е. отсутствие алгоритма.

Неправильно. while(1) - это полноценная алгоритмическая конструкция. Ради хохмы можно было бы в теле цикла задать какое-нибудь 1+1. Но суть не поменяется: не существует (математической) функции, значение которой вычислялось бы данным алгоритмом.

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

Это неверно. Для диофантовых уравнений это будет функция ℤⁿ→ℤ₂, принимающая коэффициенты уравнения и возвращающая 0 или 1 в зависимости от его разрешимости. Определение корректно, однозначность соблюдена. Алгоритмическая неразрешимость доказывается. Увы, на ЛОРе (вроде бы?) нет математической разметки, мог бы привести формальное определение, а городить псевдографикой лень.

оно может и есть, но невычислимо, и никак вами, математиками, не записано.

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

Так какое вы право можете давать мне эти ваши функции

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

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

И она имеет право на жизнь, ибо ваша т.з. мне ничего на практике не даёт полезного.

Ваш собеседник (даже на ЛОРе) ВНЕЗАПНО может оказаться более старшим и опытным. Так пользуйтесь же этим!

А теперь представь читаемость этого на циклах

отменная но раздутая.

в области преобразования колекций все эти map, flatMap, foldLeft и прочие плюшки ужасно читаемы.

«все эти» как раз наоборот, более читаемы, так как минимизируют сущности

Ну вот в скале я глянул и понял. В Java я упражняюсь во владении колесиком мышки и не могу увидеть весь алгоритм.

«все эти» как раз наоборот, более читаемы, так как минимизируют сущности

вопрос спорный. То есть конечно, если вводить строгие ограничения на код, допустим, пусть не больше одного преобразования коллекции в цепочке, тогда да, хорошо. А если лепить a.map(x=>x.foldLeft(true)((acc,v)=>acc && v>0)).bla-bla-bla, то ад читаемости, опять же мне вот больше нравится через точку записывать, а кто-то в виде операторов записывает. Разброд и шатания, в общем, а в итоге и получается что лучше брать java, там с младенчества разработчику говорят о lowerCamelCase и прочих соглашениях, дабы все как один были.

a.map(x=>x.foldLeft(true)((acc,v)=>acc && v>0)).bla-bla-bla,

это в scala такой сотонизм?

Разброд и шатания

никто не мешает определить стандарты написания кода

это в scala такой сотонизм?

ну это в скала вобщем-то удобности работы с коллекциями.

никто не мешает определить стандарты написания кода

они наверное есть, только ковбои же все, кто же их читал.

a.map(x=>x.foldLeft(true)((acc,v)=>acc && v>0)).bla-bla-bla

a map (_ forall (_ > 0)) bla-bla-bla

;)

qsort

Кому нужен этот qsort? Ты бы ещё пузырёк вспомнил.

Зачем это понимать?

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

Из ФП я выбрал для себя Scala на данный момент. Самый практичный ЯП для JVM/.Net сейчас.

У него есть большой недостаток. Там код отделён от данных.

вот так и мне больше нравится

Там код отделён от данных.

В скале уже есть (http://scalamacros.org) цитирование кода, expression trees, макросы и их раскрытие позволяющее делать разную кодогенерацию.

Проблемы в головах лисперов, считающих, что ничего лучше с 94 года появиться не могло. Отсюда куча велосипедов (ага, раз лучше Лиспа ничего не изобрели, то лесапед на лишпе с квадратными колесами ездить будет не хуже других), не интересуются новым (а нафига? лучший язык уже изобретен Маккарти), непонимание и праведный гнев в сторону программистов на других, не столь «продвинутых» языках (ведь только лисперы знают, какой язык на самом деле лучший). При этом лисперы не в состоянии ответить на вопрос, почему столь чудесный язык остается маргинальным, и испытывают комплексы по поводу невостребованности его в индустрии, иными словами, не способны дать адекватную оценку месту и роли Лиспа в сегодняшней реальности.

P.S. Все описанное следует восприминать как домыслы, преследующие цели троллинга лисперов в лучших традициях лиспосрачей.

«Структ суп ньюсуп маллок сайзоф ньюсуп, пожалуйста».

fxd ftgj

если лепить a.map(x=>x.foldLeft(true)((acc,v)=>acc && v>0)).bla-bla-bla, то ад читаемости

ты конечно же можешь показать как то смотрится на яве? ну чтоб как-то попредметнее было ;)

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

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

fxd ftgj

А куда каст дел?

Каст не нужен и даже вреден (если мы о C говорим)

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

В этих конторах работают индусы, азиаты и прочие русские (на визах), женщины (отпуск по беременности бОльше) и белые мужчины предпенсионного возраста (401k, бонусы, страховка). Молодые белые мужчины работают в стартапах, во все руки используют всякую экзотику. Соответственно, уровень программистов в этих конторах, скажем так, низковат.

Приводить корпорации и их выбор языков в качестве примера - это пример или неосведомлённости, или неадекватности.

вообще-то диофантово уравнения - это целочисленная функция

я знаю. У нас речь про однозначное отображение пространства _всех_ диофантовых уравнений в пространство их решений. Ну например пространство всех квадратных уравнений(функций) можно перевести в пространство их решений(пар точек на комплексной плоскости) используя формулу(алгоритм) y=(-b±sqrt(D))/2/a. А в случае диофантовых решение не определено.

Типа секс-меньшинств - пруф http://en.wikipedia.org/wiki/Gay_lisp

ты свою ссылку-то хоть прочитал? (для Ъ: речь в ссылке идёт про речевые особенности английских педерастов, и никакого отношения к ЯП не имеет)

Переусложнённая нечитаемая каша, вроде [..] эрланга

а вот это уже диагноз

тебе сказать про разницу или сам поймешь?

просто в сишечке все пустые «ячейки» терминальные, и нет оператора N.

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

мои «программы» тоже успешно выполняются.

Про CH, который изоморфизм, я тебе уже ссылку давал. Теперь надо бы дать ссылку про CT, который тезис.

спасибо. А что ты сказать-то хотел?