Здравствуйте, alex_public, Вы писали:

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

_>Ты покажи не математическое моделирование ссылок и указателей, а покажи наличие их самих в математике. )

Тебе именно это и показали. Computer sciense и information science это математика в чистом виде. Просто тебе удобно называть это "математическое моделирование"

I>>У тебя уникальное понимание функциональщины. Именно ты хочешь применять часть оптимизаций для части кода и игнорируешь любые аргументы, почему это работать не может и не работает. Именно по этой причине тебе нравится D — в нем реализован подход, с которым ты согласен. Собственно дело не в D, а твоих уникальных взглядах на любую из обсуждавшихся областей.

_>Хы, да просто ты пока ещё думаешь, что в мире есть только действительные числа, а я уже оперирую комплексными.

Мне кажется, ты давно сам запутался в своих аналогиях. Если мы говорим про чистоту функций, то надо смотреть откуда она растет. В D она не сводится к pure, как ты хочешь доказать. D — это ручной контроль чистоты за счет pure и иммутабельных параметров.


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

_>Чего чего? ) Я же первый везде писал, что для не иммутабельных параметров оптимизацию не применяем (точнее на самом деле тоже кое-что можно, но это уже заметно более сложных вопрос — пока для простоты считаем что ничего не возможно).

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

Здравствуйте, Ikemefula, Вы писали:

I>А раз так, то чистая функция это не pure, а pure у которой аргументы immutable, то есть, те самые значения про которые говорит alex_public.

Да, получается так. "Реально чистая" функция должна быть объявлена не только pure, но и с иммутабельными типами параметров. Я, честно говоря, пока для себя так и не понял, почему в компиляторе нет запрета на модификацию параметров pure функций. То есть — в каком случае и что именно — такая возможность дает.

Здравствуйте, alex_public, Вы писали:

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

Все еще непонятно почему для хаскеля нужны какие-то радикально иные инструменты.

_>Нет языка удобного сразу во всех областях. Каждый (из популярных) хорош в своей специфической области. А вот насчёт Хаскеля я что-то не могу представить себе эту область...

У языков программирования общего назначения не бывает никаких "специфических областей". Вот какие специфические области у C++, например?

K>>Смотрим какой-нибудь langpop

_>Хы, данный рейтинг вообще ни о чём, т.к. на гитхабе живёт весьма специфическая аудитория.

Ну так что? А на stackoverflow совсем другая специфическая аудитория, тем не менее, по графику видно что где-то после 0.1% корреляция между популярностями в таких разных и специфических аудиториях достаточно хорошая. Т.е. этот рейтинг сам себя проверяет.

_>Лучше смотреть например здесь http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

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

_>Но в любом случае, даже если бы они были в точности равны, то это всё подтверждает мою мысль — достаточно взглянуть на дату рождения Хаскеля и Го...

Ну давайте взглянем: Go мог бы быть таким, какой он сейчас и в 1968-м году, а хаскель хорошо если к 2028-му доделают.

(Если серьезно, то популярность хаскеля начала расти с нуля примерно тогда же, когда и популярность Го, а "дата рождения хаскеля" вообще вопрос нетривиальный)

_>А что не так с тем примером? Он позволяет функции иметь побочные эффекты? )

Да, конечно.

_>Ну так никто не против контроля эффектов.

Например вы против.

_>Просто не надо делать это обязательным,

А вот и подтверждение.

_>т.к. из этого тогда следует куча проблем.

Например? Одну ужасную проблему мы обнаружили: вместо $ приходится <$> писать. А какие еще проблемы есть?

_>Если есть сомнения в быстродействие работы с иммутабельными данными в D, то можем сравнить на каком-нибудь тесте...

Особого сомнения нет, скорее есть — наоборот — уверенность. Если для уменьшения лишних копирований иммутабельных массивов там еще можно что-то сделать (и я подозреваю, что это даже сделано), то с деревьями/списками с таким-то сборщиком мусора D вообще ничего не светит.

_>Ничего подобного. С иммутабельными данными тоже всё нормально.

Причем, как мы выяснили, под "все нормально" подразумевается, что их можно и даже нужно не использовать.

_>Не нужны именно оптимизации, позволяющие Хаскелю работать с иммутабельными данными в стиле мутабельных — в таком случае в D используем нормальные мутабельные.

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

_>И не надо думать, что если что-то использовать необязательно, то это не будут использовать.

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

_>К примеру const в C++ можно не использовать вообще. Но весь нормальный код кругом в этих const'ах и т.п.

K>>Да ничего плохого, как нет ничего плохого в том, чтоб использовать в 2014-ом году калькулятор HP-35 и ездить на Ford Falcon, например.
_>Ага, ага... Вот теорема Пифагора тоже в общем то устарела — не учитывает искривление пространства. Но что-то большинство народа по прежнему использует именно её, а не продвинутый вариант.

Это потому, что теорема Пифагора вовсе не устарела. А вот HP-35 — наоборот — устарел.

_>Это всего лишь вопрос области видимости.

Всего лишь!

_>Скажем вариант на C++/Java/C# опять же покажет другое.

Нет, штатные sequence comprehension из C# сделают как раз то, что делает код на haskell и F# выше. И что собственно и ожидает увидеть человек знакомый с языками, в которых вопрос области видимости уже не стоит (таких языков большинство). В плюсах и яве такой фичи нет, там все зависит от того, что считать аналогичным кодом, но в целом там с областями видимости все в порядке, это не питон.
В питоне такие милые детали, кстати, еще и от версии зависят.

_>Хыхы, википедию пишут Д'Артаньяны? ) Типа каждому выделяется по статье и больше никто на свете не способен её править? )))

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

Здравствуйте, Ikemefula, Вы писали:

I>Это ручной контроль, неинтересно.

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

I>Немного не понял. Ты показал разницу — для иммутабельных одно, для остальных другое. И внезапно оказывается, что разницы нет

I>Мы говорим про чистоту, а не гарантии отсутствия побочных эффектов. Чистота это отсутствие побочных эффектов + детерминизм. pure означает первое, а pure + параметры immutable — второе.

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

Понятие чистоты как в языке D (модификатор pure) даёт бонусы в нескольких областях:

1. В области оптимизации (вызова функции):
— для вызовов с иммутабельными параметрами (т.е. имеющими тип immutable T) — полный аналог классического лямбда-исчисления со всеми вытекающими последствиями (кэширование, ленивость и т.п.)
— для вызовов с мутабельными параметрами — теоретически тоже возможны определённые оптимизации (например для локальных переменных без ссылок компилятор вполне способен чётко отслеживать их области изменения и соответственно внутри них возможно проведение аналогичных оптимизаций), но это уже всё гораздо сложнее, менее формализовано и не факт что где-то реализовано.

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

Здравствуйте, alex_public, Вы писали:

_>А как ты ещё хочешь, если в языке есть и мутабельные и иммутабельные данные? И кстати чёткое разделение по типу как раз отлично работает. Оно даже проще чем const, т.к. это именно отдельный тип и соответственно компилятор всегда укажет, если его где-то забыть.

Ручной контроль эффектов это неинтересно. Мулька навроде checked exceptions — в одном месте поменял, повлияло на все возможные случаи вызова. То есть, надо вдруг думать, "кака унутре неонка", то есть, очевидное нарушение инкапсуляции на ровном месте.

Здравствуйте, Ikemefula, Вы писали:

I>Тебе именно это и показали. Computer sciense и information science это математика в чистом виде. Просто тебе удобно называть это "математическое моделирование"

Это математика описывающая компьютерные процессы. А я говорю о наличие чего-то типа указателей в самой математике. Но не думаю, что ты сумеешь найти что-то подобное. Соответственно поэтому классическое лямбда-исчисление является ограниченной вещью и требует адаптации и расширения при переносе в практическое программирование. А то, что в Хаскеле этого не сделали и взяли именно голый математический вариант, в итоге сильно ограничило сам язык — теперь в нём с трудом делаются самые обычные для классического программирования вещи.

I>Мне кажется, ты давно сам запутался в своих аналогиях. Если мы говорим про чистоту функций, то надо смотреть откуда она растет. В D она не сводится к pure, как ты хочешь доказать. D — это ручной контроль чистоты за счет pure и иммутабельных параметров.

Что значит ручной? То, что надо указывать у функций этот модификатор и т.п? ) Безусловно. А иначе не получится выделить этот вид функций. Иначе придётся считаться все функции не чистыми (как в C++) или все чистыми (как в Хаскеле). Конечно же был бы совсем приятен некий третий вариант, в котором компилятор сам мог определять вид функции и т.п. без всяких модификаторов, но боюсь такое уже далеко за пределами современных возможностей и уже восходит к проблеме остановки, про которую тут говорил gandjustas.

Здравствуйте, AlexRK, Вы писали:

ARK>Да, получается так. "Реально чистая" функция должна быть объявлена не только pure, но и с иммутабельными типами параметров. Я, честно говоря, пока для себя так и не понял, почему в компиляторе нет запрета на модификацию параметров pure функций. То есть — в каком случае и что именно — такая возможность дает.

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

Здравствуйте, Ikemefula, Вы писали:

I>>>Было бы по твоему, то без малого все бы умели программировать хоть чуть-чуть.
EP>>Тем не менее, непосредственно программирование тоже встречается в повседневной жизни — разве трудно составить рецепт, или например описание маршрута?
I>И где здесь вычислитель навроде машины тьюринга или регистровой машины ?

Сам человек — ему дают команды, условные переходы, а он их выполняет. Точно также он может составить "программу" для другого человека: "едь пока не увидишь памятник и дерево, после 20:00 можно прямо, иначе сверни направо — в объезд".

I>>>Для того, что бы понять твою итерационную версию, надо освоить простейший вычислитель. У ребенка нет в голове модели этого вычислителя. Когда появится, вот тогда можно будет начать объяснять итерационную версию фибоначчи.
EP>>Ему не нужна модель вычислителя — у него вычислитель уже есть в голове.
I>Машина тьюринга или регистровая машина ? Жжош !

Тьюринг-полный вычислитель как минимум.

EP>>Итеративную версию чисел Фибоначчи можно элементарно объяснить ребёнку даже если он не умеет складывать числа — с помощью линейки и циркуля.
I>Для ребенка в этом возрасте это будут просто линии и квадраты, а не фибоначчи.

Алгоритм ребёнок выполнит, даже может запомнит, количество отрезков посчитает и скажет результат. Что ещё нужно?

EP>>Попробуй объяснить вот этот "идиоматичный ФП" код ребёнку:
EP>>

EP>>fibs = fix $ (0:) . (1:) . (zipWith (+) <*> tail)
EP>>fibs !! 10
EP>>

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

Я предлагаю объяснить то, что в этом топике называют "идиоматичным ФП".

I>Нужно объяснять вот такой или классический рекурсивный
I>

I>def F(n):
I>    return ((1+sqrt(5))**n-(1-sqrt(5))**n)/(2**n*sqrt(5))
I>

I>Теперь скажи, что здесь будет непонятно школьнику 10 класса который никогда не пробовал программировать ?

Всё будет понятно, но:
1. Для ручного вычисления этого выражения он будет применять те же итеративные алгоритмы, которым он научился в первых классах.
2. Используется относительно современная символьная нотация, хотя первоначально/исторически выражения записывались в словесной, то есть императивной форме, вплоть до XV века — потому что она естественней и легче для понимания.
3. Как сказали выше, идиоматичный ФП это комбинирование комбинаторов — ничего этого в этом выражении нет.

Здравствуйте, alex_public, Вы писали:

I>>Тебе именно это и показали. Computer sciense и information science это математика в чистом виде. Просто тебе удобно называть это "математическое моделирование"

_>Это математика описывающая компьютерные процессы.

Да, вот так новость !

>А я говорю о наличие чего-то типа указателей в самой математике.

"Computer sciense и information science" @

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Итеративную версию чисел Фибоначчи можно элементарно объяснить ребёнку даже если он не умеет складывать числа — с помощью линейки и циркуля.
I>>Для ребенка в этом возрасте это будут просто линии и квадраты, а не фибоначчи.

EP>Алгоритм ребёнок выполнит, даже может запомнит, количество отрезков посчитает и скажет результат. Что ещё нужно?

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

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

EP>Я предлагаю объяснить то, что в этом топике называют "идиоматичным ФП".

Ты думаешь идиоматичное императивное программирование или ОО будет легче ?

I>>Теперь скажи, что здесь будет непонятно школьнику 10 класса который никогда не пробовал программировать ?

EP>Всё будет понятно, но:
EP>1. Для ручного вычисления этого выражения он будет применять те же итеративные алгоритмы, которым он научился в первых классах.

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

EP>2. Используется относительно современная символьная нотация, хотя первоначально/исторически выражения записывались в словесной, то есть императивной форме, вплоть до XV века — потому что она естественней и легче для понимания.

Императивный != словесный

EP>3. Как сказали выше, идиоматичный ФП это комбинирование комбинаторов — ничего этого в этом выражении нет.

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

Здравствуйте, Ikemefula, Вы писали:

EP>>>>Итеративную версию чисел Фибоначчи можно элементарно объяснить ребёнку даже если он не умеет складывать числа — с помощью линейки и циркуля.
I>>>Для ребенка в этом возрасте это будут просто линии и квадраты, а не фибоначчи.
EP>>Алгоритм ребёнок выполнит, даже может запомнит, количество отрезков посчитает и скажет результат. Что ещё нужно?
I>Не сможет выполнить, например потому, что считает он еле-еле, раз числа складывать не умеет,
I>а отрезки может считать как ему нравится, и циркулем-линейкой скорее будет играться и рисовать свои кружочки-линии.

Не проблема, даже считать не обязательно. Главное сделать циркулем несколько шагов и ткнуть пальцем в клетку с готовым числом — алгоритм выполнен. Что может быть проще?

I>>>В этом примере ты предлагаешь объяснять оптимизации хаскеля и хвостовую рекурсию, то есть, конкретный вариант а не фибоначчи. То есть, проблема в том что явно привязался к вычислителю
EP>>Я предлагаю объяснить то, что в этом топике называют "идиоматичным ФП".
I>Ты думаешь идиоматичное императивное программирование или ОО будет легче ?

Идиоматичное ИП на порядок легче объяснить.

EP>>1. Для ручного вычисления этого выражения он будет применять те же итеративные алгоритмы, которым он научился в первых классах.
I>Нет в первых классах никаких итеративных алгоритмов.

Сложение, вычитание, умножение, деление

EP>>2. Используется относительно современная символьная нотация, хотя первоначально/исторически выражения записывались в словесной, то есть императивной форме, вплоть до XV века — потому что она естественней и легче для понимания.
I>Императивный != словесный

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

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Не проблема, даже считать не обязательно. Главное сделать циркулем несколько шагов и ткнуть пальцем в клетку с готовым числом — алгоритм выполнен. Что может быть проще?

Нужно осмысление. Как это в твою идею вписать — не ясно.

EP>>>Я предлагаю объяснить то, что в этом топике называют "идиоматичным ФП".
I>>Ты думаешь идиоматичное императивное программирование или ОО будет легче ?

EP>Идиоматичное ИП на порядок легче объяснить.

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

Здравствуйте, Ikemefula, Вы писали:

EP>>Не проблема, даже считать не обязательно. Главное сделать циркулем несколько шагов и ткнуть пальцем в клетку с готовым числом — алгоритм выполнен. Что может быть проще?
I>Нужно осмысление. Как это в твою идею вписать — не ясно.

Осмысление чего и зачем?

EP>>Идиоматичное ИП на порядок легче объяснить.
I>Ну не знаю, многие неплохо решают задачи по математике, а вот простецкий алгоритм на ассемблере не могут осилить за целых два семестра И собтсвенно не надо тому удивляться.

Это элементарное отсутствие желания/мотивации.

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

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

Здравствуйте, Klapaucius, Вы писали:

K>Все еще непонятно почему для хаскеля нужны какие-то радикально иные инструменты.

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

K>У языков программирования общего назначения не бывает никаких "специфических областей". Вот какие специфические области у C++, например?

Ага, ага) Ассемблер и Питон ну совсем не имеют специфических областей и применяются абсолютно везде.)

K>Ну так что? А на stackoverflow совсем другая специфическая аудитория, тем не менее, по графику видно что где-то после 0.1% корреляция между популярностями в таких разных и специфических аудиториях достаточно хорошая. Т.е. этот рейтинг сам себя проверяет.

Это типа юмор такой? )))

Смотрим например C#: SO — 624 930, GH — 1 873 009 420.
И к примеру C: SO — 135 602, GH — 5 975 490 485.

Явно полностью противоречащие друг другу тенденции.

Более того, эти товарищи похоже ещё и вообще считать не умеют. Т.к. они там заявляют, что считают общий рейтинг (который в процентах) как среднее от результатов на SO и GH. Но по факту там явно считается просто процент от SO, т.к. скажем тот же JS имеет чуть меньший процент чем C#, но при этом имеет в 13 раз больше строк на GH и чуть меньшее количество (чем C#) тем на SO.

Т.е. всё это — полная неадекватность, очевидная каждому вменяемому человеку даже после самого поверхностного взгляда. По сути их рейтинг — это чистый рейтинг SO, а рейтинг SO=популярность_языка*проблемность_языка. Т.е. даже реально самый популярный язык, будет в далеко не во главе рейтинга, если он при этом ещё и простой. Ну в общем то мне понятно почему фанаты Хаскеля любят данный неадекватный рейтинг...

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

Угу, tiobe далеко не идеален. Только вот ничего лучше мне пока никто не показывал...

K>Ну давайте взглянем: Go мог бы быть таким, какой он сейчас и в 1968-м году, а хаскель хорошо если к 2028-му доделают.

K>(Если серьезно, то популярность хаскеля начала расти с нуля примерно тогда же, когда и популярность Го, а "дата рождения хаскеля" вообще вопрос нетривиальный)

Какие дохленькие отмазки. )

_>>А что не так с тем примером? Он позволяет функции иметь побочные эффекты? )
K>Да, конечно.

Каким образом? Продемонстрируйте... )

K>Особого сомнения нет, скорее есть — наоборот — уверенность. Если для уменьшения лишних копирований иммутабельных массивов там еще можно что-то сделать (и я подозреваю, что это даже сделано), то с деревьями/списками с таким-то сборщиком мусора D вообще ничего не светит.

Ну так давайте замерим, в чём проблема?

K>Причем, как мы выяснили, под "все нормально" подразумевается, что их можно и даже нужно не использовать.

Да, их можно и нужно не использовать там, где по условию задачи данные реально мутабельные.

K>Ну я про то и говорю — иммутабельные структуры объявляются ненужными — значит и оптимизации не нужны — все логично. Не понятно только, зачем нужен контроль эффектов, если нет ничего из того, для чего контроль эффектов как раз и нужен.

Почему не нужными то? ) Если мы взглянем скажем на какой-нибудь нормальный C++ код, то увидим, что даже при написание в чисто императивном стиле там кругом стоят const, хотя никто этого не требует силой. Т.е. использование чего-то типа иммутабельных данных (всё же const в C++ это не 100% гарантия, в отличие от immutable в D) является стандартной практикой во многих императивных языках.

K>Если что-то использовать не нужно, но зато можно — это, конечно, будут использовать. А вот если что-то использовать по факту нельзя — то это использолвать не будут. А если ничего для поддержки иммутабельности нет — то и пользоваться ей нельзя, ну, можно пользоваться для того, чтоб показывать какая это бесполезная вещь.

Ну вот в C++ и D различные виды иммутабельные данных используются повсеместно.

K>Как и кто пишут википедию (конкретную ее часть) я уже объяснил выше. Не говоря уже о том, что не каждый может править все что угодно в вики, то что там будет написано большую часть времени будет результатом правки человеков, которым больше всего не все равно. А даже в этой теме можно наблюдать, как неравнодушный человек может про любой X на голубом глазу утверждать одновременно, что X есть, X не нужно и что отсутствие X равно наличию X.

Ну да, ну да, какая жалось что те, немногие избранные, которые посвящены в истину, являются лишь пассивными наблюдателями. А человечество в итоге ведут вперёд активные невежды. Знаем такую точку зрения... )))

Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Нужно осмысление. Как это в твою идею вписать — не ясно.

EP>Осмысление чего и зачем?

вычисления последовательности Фибоначчи. Затем, что бы знание можно было применить повторно, тем самым ребенком которому ты собираешься чего то объяснять.

EP>>>Идиоматичное ИП на порядок легче объяснить.
I>>Ну не знаю, многие неплохо решают задачи по математике, а вот простецкий алгоритм на ассемблере не могут осилить за целых два семестра И собтсвенно не надо тому удивляться.

EP>Это элементарное отсутствие желания/мотивации.

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

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

EP>Просто посмотреть на идиоматичное решение одной и той же задачи, например генерацию чисел Фибоначчи итерационным методом vs функциональное комбинирование комбинаторов.

Не ясно, почему ты выбрал комбинаторы, по какому принципу ? Почему не монады, не реактивный код, не асинхронщина, а именно комбинаторы ? И почему надо сравнивать с простым итерационным методом, а не брать модный MVC-фремворк с серверным бакэндом ?

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

Здравствуйте, alex_public, Вы писали:

K>>У языков программирования общего назначения не бывает никаких "специфических областей". Вот какие специфические области у C++, например?

_>Ага, ага) Ассемблер и Питон ну совсем не имеют специфических областей и применяются абсолютно везде.)

Ассемблер это не язык общего назначения, а Питон применяется везде.

_>Угу, tiobe далеко не идеален. Только вот ничего лучше мне пока никто не показывал...

JS знает почти каждый первый, а Tiobe показывает его неизвестно где внизу, хотя он должен быть на первых строчках

Здравствуйте, alex_public, Вы писали:

K>>Все еще непонятно почему для хаскеля нужны какие-то радикально иные инструменты.
_>Видимо потому, что существующие заточены под императивный стиль или ООП, а не под чистое ФП,

Ну, можно сказать, что sequence diagram под императивный стиль заточена (причем для них применения найти как раз можно — для описания взаимодействия легких потоков, например, которые в ФЯ достаточно популярный инструмент). Но остальные-то? По поводу заточенности на ООП, на той же диаграмме классов отношения это: ассоциация, композиция, агрегация, обобщение, имплементация и зависимость. Тут под ООП-специфику разве что "имплементацию" можно попробовать подтянуть, да и то соответствующие отношения и в тайпклассах хаскеля и параметрических модулях ML-ей есть.

_> о чём фанаты последнего и говорят в приведённых мною ссылках.

Они там пишут, в основном, что в принципе не любители таких диаграмм. Я и сам не любитель, вот я и интересуюсь — в чем же должно быть отличие? Вы сами говорите, что не знаете, но при этом почему-то уверены, что оно должно быть.

_> Ассемблер и Питон ну совсем не имеют специфических областей и применяются абсолютно везде.)

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

_>Смотрим например C#: SO — 624 930, GH — 1 873 009 420.
_>И к примеру C: SO — 135 602, GH — 5 975 490 485.
_>Явно полностью противоречащие друг другу тенденции.

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

_>Т.е. всё это — полная неадекватность, очевидная каждому вменяемому человеку даже после самого поверхностного взгляда.

Никакой "очевидной неадекватности" там точно нет.

_>По сути их рейтинг — это чистый рейтинг SO, а рейтинг SO=популярность_языка*проблемность_языка.

А рейтинг на гитхабе это популярность_языка*многословность_языка.

_>Т.е. даже реально самый популярный язык, будет в далеко не во главе рейтинга, если он при этом ещё и простой.

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

_> Ну в общем то мне понятно почему фанаты Хаскеля любят данный неадекватный рейтинг...

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

_>Угу, tiobe далеко не идеален.

Это показанный мной рейтинг не идеален, а tiobe — полностью непригоден. Недавно заглянул туда и обнаружил, что F# у них внезапно прыгнул с 60-какого-то места чуть ли не в десятку. Чудеса адекватности, короче говоря. Я помню, там как-то раз, несколько лет назад, популярность D подскакивала из за индексации его багтрекера.

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

_>Только вот ничего лучше мне пока никто не показывал...

Да вот я буквально вчера показал.

K>>(Если серьезно, то популярность хаскеля начала расти с нуля примерно тогда же, когда и популярность Го, а "дата рождения хаскеля" вообще вопрос нетривиальный)
_>Какие дохленькие отмазки. )

Это констатация факта. Идея о том, что можно оказывается использовать хаскель для написания программ, а не статей — совсем новая. (кстати, tex-исходник статьи со вставками кода на хаскеле — это компилирующаяся программа на хаскеле, что символизирует)

_>Каким образом? Продемонстрируйте... )

Так тот пример это уже демонстрирует.

_>Ну так давайте замерим

Ну давайте. Допустим, нужно оценить производительность нескольких ходовых персистентных структур данных: списка (от хаскеля Data.List), иммутабельного массива (Data.Vector), бинарного дерева (Data.Map), finger tree (Data.Sequence), patricia tree (Data.IntMap), HAMT (Data.HashMap). Делать это лучше для x86 и x64, с дефолтными и подобранными настройками сборщика.

_> в чём проблема?

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

_>Да, их можно и нужно не использовать там, где по условию задачи данные реально мутабельные.

"данные реально мутабельные" — это на условия задач совсем не похоже.

_>Почему не нужными то?

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

_>Ну вот в C++ и D различные виды иммутабельные данных используются повсеместно.

Это если называть константные ссылки иммутабельностью (непонятно, почему плюсисты так делают, впрочем они мастера придумывать специфические значения для общеупотребительных терминов). Более реальный пример массового использования иммутабельности — это строки в C#/Java.

_>Ну да, ну да, какая жалось что те, немногие избранные, которые посвящены в истину, являются лишь пассивными наблюдателями. А человечество в итоге ведут вперёд активные невежды. Знаем такую точку зрения... )))

Да нет, наоборот. Многие знают такие парадигмы как императивное/декларативное программирование. Еще больше людей знают более детальную классификацию ООП/ФП/ЛП. А вот остальные 253 парадигмы — это как раз удел "немногих избранных", "посвященных" в разработанную в узком кругу "истину", у которых много свободного времени для ведения войн правок в википедии.
Не хочу показаться "невеждой", но предлагаю не страдать ерундой и ограничиться тремя парадигмами, а поддержку оценивать на более-менее реальных примерах, а не по евангилистским фантазиям.

Кстати, вы, похоже, поскипали просьбу продемонстрировать страшные проблемы, про которые упоминали в прошлом посте. (Впрочем, это уже не первый раз происходит, так что я не удивлен).

Здравствуйте, Klapaucius, Вы писали:

K>Ну, можно сказать, что sequence diagram под императивный стиль заточена (причем для них применения найти как раз можно — для описания взаимодействия легких потоков, например, которые в ФЯ достаточно популярный инструмент). Но остальные-то? По поводу заточенности на ООП, на той же диаграмме классов отношения это: ассоциация, композиция, агрегация, обобщение, имплементация и зависимость. Тут под ООП-специфику разве что "имплементацию" можно попробовать подтянуть, да и то соответствующие отношения и в тайпклассах хаскеля и параметрических модулях ML-ей есть.

Угу с последовательностью плохо. Но и чуть ли не самая классическая в программирование диаграммка (деятельности) тоже не особо ложится (если конечно не ограничиваться кодом внутри одной монады). Натягивание же диаграмм классов/объектов на Хаскель вообще забавно — они имеет смысл не отображения набора типов, а представления всего приложения или его части (я на функции намекаю, не говоря уже о нюансах инкапсуляции). Что остаётся то в итоге из реально используемых? Только диаграммки пакетов/компонентов — вот их действительно можно использоваться в ФП. Но это очень бедненький инструмент выходит...

K>Они там пишут, в основном, что в принципе не любители таких диаграмм. Я и сам не любитель, вот я и интересуюсь — в чем же должно быть отличие? Вы сами говорите, что не знаете, но при этом почему-то уверены, что оно должно быть.

Я говорю, что не знаю чем заменить uml для чистого ФП. А почему большая часть uml не подходит для чистого ФП я прекрасно вижу.

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

Оу) Если ассемблер и питон — это не языки общего назначения, то какое тогда вы дадите определение (очередное оригинальное видимо) для самого этого понятия? )

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

Совсем уже не видим очевидного в приступе спора? ) Если у нас один язык (причём смотрим на мейнстрим) имеет на SO в 5 раз больший результат чем другой, а на GH в 5 раз меньше того же другого, то о какой "корреляции" и "самопроверки" данных можно вообще говорить?

K>А рейтинг на гитхабе это популярность_языка*многословность_языка.

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

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

Причём тут вообще оси графика? Их рейтинг отображается на графике при наведение мышки на язык в процентах. И плюс в соответствие с данным рейтингом отсортированы языки в списке справа (от большего к меньшему). И похоже, что отображают эти проценты исключительно данные SO, хотя по их же описанию рейтинга внизу страницы, там должно быть SO и GH вместе. Ну и соответственно, т.к. Хаскель является у нас одним из самых вызывающих вопросы языков, то его рейтинг по данной системе будет иметь некое приличное значение.

K>Это показанный мной рейтинг не идеален, а tiobe — полностью непригоден. Недавно заглянул туда и обнаружил, что F# у них внезапно прыгнул с 60-какого-то места чуть ли не в десятку. Чудеса адекватности, короче говоря. Я помню, там как-то раз, несколько лет назад, популярность D подскакивала из за индексации его багтрекера.

Интенсивные прыжки для языков с рейтингом меньше 1% — это абсолютно нормально. )))

K>Впрочем, выбор рейтинга ничего не решает, значимой разницы в популярности между го и хаскелем и на tiobe нет.

На tiobe нет и это похоже на правду, а вот в том сомнительном месте Хаскель даже опережает в 3 раз Го. ))) Хотя на гитхабе кода на Го больше, чем на Хаскеле. И это при с учётом разницы в дате рождения...

K>Так тот пример это уже демонстрирует.

Тот пример ничего такого не демонстрирует — функция целиком зависит от передаваемых ей параметров и не меняет никаких глобальных/статических данных.

K>Ну давайте. Допустим, нужно оценить производительность нескольких ходовых персистентных структур данных: списка (от хаскеля Data.List), иммутабельного массива (Data.Vector), бинарного дерева (Data.Map), finger tree (Data.Sequence), patricia tree (Data.IntMap), HAMT (Data.HashMap). Делать это лучше для x86 и x64, с дефолтными и подобранными настройками сборщика.

Это общие слова. Нужна конкретная задачка, решение которой можно записать в одну страничку кода (большее лень для форумного спора).

K>На данном этапе проблема уже очевидна. Во-первых, подозреваю, что имплементаций ряда структур для D просто нет (писать тормозные нет смысла, а быстрые на D не напишешь). Во-вторых, тут потребуется слишком много труда. Конечно, существуют готовые бенчмарки для всего этого, но они ведь для хаскеля и D будут разными, т.е. понадобится какое-то согласование. К тому же, эти готовые бенчмарки в основном однопоточные, что в наше суровое время уже не особенно интересно.

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

K>"данные реально мутабельные" — это на условия задач совсем не похоже.

Похоже, похоже. Вот тот мой пример с обработкой видео в реальном времени — это прямо оно и есть.

K>Это если называть константные ссылки иммутабельностью (непонятно, почему плюсисты так делают, впрочем они мастера придумывать специфические значения для общеупотребительных терминов). Более реальный пример массового использования иммутабельности — это строки в C#/Java.

и?

K>Кстати, вы, похоже, поскипали просьбу продемонстрировать страшные проблемы, про которые упоминали в прошлом посте. (Впрочем, это уже не первый раз происходит, так что я не удивлен).

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

Здравствуйте, alex_public, Вы писали:

K>>Кстати, вы, похоже, поскипали просьбу продемонстрировать страшные проблемы, про которые упоминали в прошлом посте. (Впрочем, это уже не первый раз происходит, так что я не удивлен).

_>На этот вопрос уже были ответы в данной теме, причём не один раз и на разных примерах. Не вижу смысла повторяться.

Не было демонстрации, ты привел или специально переусложненный код, или просто код с другим синтаксисом, не таким как в С++

Здравствуйте, alex_public, Вы писали:

_>Угу с последовательностью плохо.

Да нет, я же говорю — нормально: "для описания взаимодействия легких потоков, например, которые в ФЯ достаточно популярный инструмент"

_>Но и чуть ли не самая классическая в программирование диаграммка (деятельности) тоже не особо ложится

Речь про activity diagram? Ну, она представляет control-flow, которым в декларативном программировании действительно можно не заморачиваться.

_>(если конечно не ограничиваться кодом внутри одной монады).

Что бы это значило?

_>Натягивание же диаграмм классов/объектов на Хаскель вообще забавно —

В чем "натягивание"-то заключается?

_>они имеет смысл не отображения набора типов, а представления всего приложения или его части (я на функции намекаю, не говоря уже о нюансах инкапсуляции).

Ничего не понял.

_>А почему большая часть uml не подходит для чистого ФП я прекрасно вижу.

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

_>Оу) Если ассемблер и питон — это не языки общего назначения, то какое тогда вы дадите определение (очередное оригинальное видимо) для самого этого понятия? )

"Оригинальными" определениями я не пользуюсь. Тут определение вполне общепризнанное: язык, хорошо подходящий для решения широкого круга задач. Питон — это все-таки glue language, хотя серьезные претензии на общее назначение имеются.
Тут интереснее, что вы недавно отрицали существование языков общего назначения как класса: "Нет языка удобного сразу во всех областях. Каждый (из популярных) хорош в своей специфической области.", а теперь удивляетесь, что что-то языком общего назначения не посчитали. Как-то непоследовательно.

_>Совсем уже не видим очевидного в приступе спора? ) Если у нас один язык (причём смотрим на мейнстрим) имеет на SO в 5 раз больший результат чем другой, а на GH в 5 раз меньше того же другого, то о какой "корреляции" и "самопроверки" данных можно вообще говорить?

Напоминаю, что lg 5 ~ 0.7 крайне впечатляющая разница, что тут скажешь.

_>Причём тут вообще оси графика? Их рейтинг отображается на графике при наведение мышки на язык в процентах. И плюс в соответствие с данным рейтингом отсортированы языки в списке справа (от большего к меньшему). И похоже, что отображают эти проценты исключительно данные SO, хотя по их же описанию рейтинга внизу страницы, там должно быть SO и GH вместе.

При том. Смотрите на график и мысленно рисуете линию тренда (в оригинальном анализе популярности, на базе которого рейтинг и разработан, ничего воображать не нужно было — там линия была) и двигаетесь вдоль нее. Популярные языки будут в верхней правой части графика, а непопулярные — в левой нижней. Удаление от этой линии позволяет прикинуть точность оценки популярности (предсказуемо, что для совсем непопулярных языков точной оценки нет).
Список и проценты, который они там считают, дадут примерно тот же результат, но нужно понимать, что относительное положение соседей в нем достаточно произвольно из-за точности определения популярности. На графике это четко видно — так что он подходит для оценки лучше списка.
Понятно, что относительную популярность С++ и JavaScript или Haskell и Go по этой методике не оценить, Но можно сказать, что внутри этих двух групп разница незначительна, а между ними наоборот — очень существенна.

_>Интенсивные прыжки для языков с рейтингом меньше 1% — это абсолютно нормально. )))

Ну так это проблема tiobe, которой langpop полностью лишен. Даже для языков с популярностью уровня F# там подвижность будет крайне низкой, а "внезапный" прыжок в мейнстрим группу и вовсе исключен. Все что там может прыгать — неизвестные языки из левого хвоста, причем внутри своей группы. Строки на гитхабе и вопросы на СО нужно кому-то написать, а рейтинг на tiobe, как мы знаем, может радикально изменится в одночасье после индексации багтрекера поисковиком.

_>На tiobe нет и это похоже на правду, а вот в том сомнительном месте Хаскель даже опережает в 3 раз Го. ))) Хотя на гитхабе кода на Го больше, чем на Хаскеле.

Еще раз: 3 раза на этом рейтинге — это ничто. Вот 100 раз — это да, заметная разница.

_>И это при с учётом разницы в дате рождения...

И какая же дата рождения у хаскеля? И при чем тут дата рождения, если рост популярности у хаскеля в то же самое время, что и у го начался.

_>Тот пример ничего такого не демонстрирует — функция целиком зависит от передаваемых ей параметров

Она деструктивно меняет передаваемый класс, так что одного параметра не хватает.

_>и не меняет никаких глобальных/статических данных.

Замечательно, но для контроля эффектов этого недостаточно.

_>Это общие слова. Нужна конкретная задачка, решение которой можно записать в одну страничку кода (большее лень для форумного спора).

ОК. Вот микробенчмарк, который проверяет как раз то, что мы обсуждали:
1) Тест дает заметную и при этом характерную для ФП кода нагрузку на ГЦ. Она выделяет за время работы 16 гигов в памяти (2 Гб в секунду) при этом выживаемость объектов в куче меньше половины процента.
2) Использует иммутабельную структуру данных — односвязный список — у которого рантайм "за кадром" переписывает хвосты. В коде же, никаких переписываний нет.
3) Предыдущий пункт обеспечивается эффективной реализацией ленивости.
4) Тест дает возможность продемонстрировать качество оптимизатора (по крайней мере, с выключенной оптимизацией код работает в 30 раз медленнее)

primes = 2:3:filter' isPrime [5,7..] :: [Int]
isPrime x = all' (/= 0) . map (x `rem`) . takeWhile' ((<= x) . (^2)) $ primes
main = print . length . takeWhile' (<= 2^24) $ primes

-- (*)
step p res x | p x = (x:) | otherwise = res
takeWhile' p = foldr (step p $ const []) []
-- здесь раннее завершение, хотя специально ничего для этого в коде не написано.
all' f = foldr (&&) True . map f
filter' p = foldr (step p id) []

-- результат:
--1077871

(*) Собственная реализация стандартных комбинаторов на базе других комбинаторов как раз демонстрирует качество оптимизатора при работе с типичным ФП кодом.
В игрушечных ФЯ производительность сильно зависит от использования готовых библиотечных функций, написанных в рекурсивно-лапшевом стиле либо даже с использованием хаков, функции получаемые комбинированием комбинаторов, как правило, сильно тормозят. Хороший ФЯ-компилятор как раз заточен на оптимизацию такого кода, и эти определения не только не медленнее библиотечных функций, а еще и быстрее: библиотечный takeWhile рекурсивно-лапшевой, оптимизировать его нельзя, так что с ним тест работает на ~ 20% дольше.

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

K>>"данные реально мутабельные" — это на условия задач совсем не похоже.
_>Похоже, похоже. Вот тот мой пример с обработкой видео в реальном времени — это прямо оно и есть.

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

_>и?

И то, что декларируемого вами "широкого использования иммутабельности" в C++ на деле нет.

_>На этот вопрос уже были ответы в данной теме, причём не один раз и на разных примерах. Не вижу смысла повторяться.

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