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

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

Ага, ага... Правда это базовый способ для записи алгоритмов, но вам не нужен понятное дело)))

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

Я говорю о том, что даже если мы попытаемся нарисовать диаграммку классов (уже смешно звучит) для программы на Хаскеле, то максимум что мы получим, это описание используемых в этой программке типов и всё. В то время как рисование подобной диаграммы для ООП программки часто полностью задаёт всю её архитектуру. Так понятна мысль или надо продолжить разжёвывание про инкапсуляцию и т.п? )

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

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

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

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

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

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

1. А причём тут логарифм? С чего вы взяли, что сравнение должно быть в логарифмах?
2. Даже если и в логарифмах и считать что разница в 0,7 раз, то фокус в том что по одному параметру она в 0,7 больше, а по другому в 0,7 раз меньше — и какая же у нас тут "корреляция" и "самопроверка"?

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

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

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

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

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

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

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

Что за бред? Там рейтинг в процентах со значениями от 0 до 15.

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

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

_>>и не меняет никаких глобальных/статических данных.
K>Замечательно, но для контроля эффектов этого недостаточно.

Если не уметь думать, то конечно нет. )

K>ОК. Вот микробенчмарк, который проверяет как раз то, что мы обсуждали:

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

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

Я пока вообще не понял что там собственно происходит) Кстати, а это компилируемый код или надо ещё что-то добавить?

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

K>>ОК. Вот микробенчмарк, который проверяет как раз то, что мы обсуждали:
_>Ну так можно увидеть описание самой задачки, а не решение на Хаскеле? ) А то мне лень ковыряться в его плохо читаемом синтаксисе...

Задача — найти количество простых чисел, не превышающих 16777216.
Предложенный вариант строит список простых чисел, тестируя на простоту все нечетные числа, начиная с 5, причем чтобы решить, является ли очередное число простым, он использует в качестве делителей значения из самого строящегося списка. Список пополняется, пока очередное число не окажется больше 2^24, после чего возвращается его длина.

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

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

_>Ага, ага... Правда это базовый способ для записи алгоритмов, но вам не нужен понятное дело)))

Базовый способ записи алгоритмов — (псевдо)код. Не сталкивался с записыванием алгоритмов с помощью диаграмм даже самыми яростными фанатами UML. По моему, такой ерундой только школьные учителя лет 20 назад страдали.

_>Я говорю о том, что даже если мы попытаемся нарисовать диаграммку классов (уже смешно звучит) для программы на Хаскеле

Почему это звучит смешно?

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

Во-первых, непонятно, почему только типов и все. В ФЯ бывают системы модулей, например.
Во-вторых, мне непонятно противопоставление "всего-навсего типов" и "ого-го всей архитектуры".

_>Так понятна мысль или надо продолжить разжёвывание про инкапсуляцию и т.п? )

Надо продолжать, ничего не понятно. Что не так с инкапсуляцией, например?

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

Как мы знаем из книги "Физики шутят", "очевидно, что ..." означает "я этого не проверял, но ...".

_>Причём даже повторы не помогают

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

_>- просто идёт отрицание реальности.

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

_>Так что в данной дискуссии я уже давно не стараюсь убедить вас, а пишу скорее для зрителей. )))

Не понимаю, зачем это отдельно уточнять — это типично для публичной дискуссии.

K>>Тут интереснее, что вы недавно отрицали существование языков общего назначения как класса: "Нет языка удобного сразу во всех областях. Каждый (из популярных) хорош в своей специфической области.", а теперь удивляетесь, что что-то языком общего назначения не посчитали. Как-то непоследовательно.
_>Абсолютно нормальная и очевидная логика. И только у вас она почему-то вызывает противоречия.

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

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

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

_>1. А причём тут логарифм? С чего вы взяли, что сравнение должно быть в логарифмах?

Обратите внимание на шкалы графика. Видите там 1e+0, 1e+1, 1e+2 ?

_>2. Даже если и в логарифмах и считать что разница в 0,7 раз, то фокус в том что по одному параметру она в 0,7 больше, а по другому в 0,7 раз меньше — и какая же у нас тут "корреляция" и "самопроверка"?

Хорошая корреляция. В современном рейтинге ее не считают, но это же по графику видно, что хорошая. Впрочем, создается ощущение, что вы просматриваете страницу в текстовом браузере и графика не видите вовсе. Это объясняет и ваши загадочные утверждения о том, что они видимо что-то неверно посчитали, потому что у них процентный рейтинг только от СО зависит, хотя если посмотреть на график причина очевидна.
Для тех, кто заказывает интернет страницы по телетайпу, я даже могу пересказать в общих чертах: дело в том, что на оси гитхаба мы видим в правой части шкалы 1e+10, а в верхней части шкалы СО — только 1e+5. Это означает, что строки на гитхабе растут гораздо быстрее вопросов на СО. Рассмотрим простой пример: На языке Сартр написана одна строчка на гитхабе, а на языке Антракс 10000 строк. При этом про Сартр спросили на СО 1 раз, а про Антракс — 100 раз. Получается, что доля Сартра на гитхабе примерно 1e-3%, а доля Антракса на гитхабе примерно 99.99%. Зато на СО у Сартра примерно 0.99%, а у Антракса только примерно 99.01%. Посчитаем среднее: для Сартра это ~ 0.5%, а для Антракса ~ 99.5%. Легко видеть, что рейтинг по такому агрегату будет существенно сильнее похож на более медленно растущий СО-рейтинг, чем на быстрый гитхаб-рейтинг. По хорошему говоря, агрегировать такие рейтинги нужно с соответствующим поправочным к-том, хотя посчитано все правильно (но зря). К счастью, есть график и процентный агрегированный рейтинг не нужен.

_>Вот в том то и дело, что даже приблизительно не такие же.

Между этими графиками много лет прошло.

_>У тех товарищей на первом месте стоит вообще C# (самому то было не смешно давать ссылку с таким результатом?) в то время как здесь он явно далёк от "правого верхнего угла".

В обновленном графике по той же технике http://redmonk.com/sogrady/2014/01/22/language-rankings-1-14/ C# продвинулся в сторону линии тренда.
Про СО-эффект агрегата уже написано.

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

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

_>Там рейтинг в процентах со значениями от 0 до 15.

Не смотрите на рейтинг, смотрите на график.

_>И? Кстати, если надо, то это очевидным образом запрещается тоже (immutable параметр и всё).

Ну так компилятор позволяет проаннотировать функцию pure не аннотируя входные данные как immutable. Т.е. то, что он проверяет к чистоте никакого отношения не имеет. Это некоторое свойство, придуманное авторами D непонятно что значащее.

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

Например?

K>>Замечательно, но для контроля эффектов этого недостаточно.
_>Если не уметь думать, то конечно нет. )

А если уметь думать — тем более.

_>Ну так можно увидеть описание самой задачки, а не решение на Хаскеле? ) А то мне лень ковыряться в его плохо читаемом синтаксисе...

Задача заключается в проверке "поддержки иммутабельности" в языке, посредством создания как можно большего числа промежуточных значений в виде иммутабельных структур данных таким образом, чтоб часть из них можно было выкинуть за ненадобностью, а часть нет. Т.е. есть работа как для компилятора (устраняющего ненужные промежуточные значения), так и рантайма, которому есть что быстро размещать в памяти и, к примеру, переписывать по месту.
Решается эта задача, вычислением простых чисел тупым методом.
primes — иммутабельный односвязный список простых чисел (помещающихся в Int32 для простоты реализации в D), упорядоченный по возрастанию, которые получаются из списка нечетных чисел начиная с 5, отфильтрованных функцией isPrime и присоединенных к этому списку в начале чисел 2 и 3
isPrime — функция, проверяющая, является ли число простым проверкой его делимости на простые числа из списка primes, квадраты которых меньше либо равны проверяемому числу.
main — основная функция, которая отбирает из списка простых чисел те, что меньше 2 в 24-ой степени, считает их количество и выводит его в консоль.
дальше следуют реализации аналогов стандартных функций для работы со списками, реализованных через другие функции для работы со списками.
От вас я ожидаю решения той же задачи на D максимально приближенным способом, чтоб оценивать одно и то же, и/или какие-то поправки для моего кода, которые позволили бы приблизится к чему-то среднему между нашими вариантами, если мой нельзя воспроизвести на D.

_>Я пока вообще не понял что там собственно происходит)

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

_>Кстати, а это компилируемый код или надо ещё что-то добавить?

Да, компилируемый, проверялся на GHC 7.4.2 и 7.6.3 (x86)

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

DM>Полагаю, идиоматическое решение на D вообще не будет использовать списки (хватит и одного массива)

Охотно верю. Но при чем тут декларируемая моим оппонентом "хорошая поддержка иммутабельности"?

DM>и не будет иметь гигабайты аллокаций, но вряд ли Клапауций сочтет его интересным.

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

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

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

EP>>Это никакой не Tree Sort, это именно пародия на quick sort.
K>Не понятно, какой смысл вы вкладываете в слова "пародия на quick sort", но это совершенно точно tree sort.

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

K>Называть это quicksort, конечно, неправильно.

Об этом и речь, даже Erik Meijer сделал соответствующую оговорку в своих видео-лекциях.

K>То, что это tree sort в глаза сразу не бросается потому, что он дефористирован вручную. Т.е. функция построения дерева (несбалансированного)

Ок, я думал Tree Sort предполагает только сбалансированные деревья. А так получается что нет ни inplace, ни нормального worst case performance (как для out-of-place)

EP>>Quick Sort делит массив на две части (вырезая середину), и продолжает рекурсивно в каждой из частей. Начиная с определённой глубины текущий Range полностью поместится в L3, ещё глубже — L2, потом в L1 и так далее.

K>Ну, не каждый divide-and-conquer алгоритм считается cache-oblivious. Почитайте про какой-нибудь funnel-sort там разница хорошо понятна.

Cache-oblivious — означает эффективное использование иерархии памяти, без привязки к конкретным характеристикам железа, т.е. противоположность cache-aware.
Funnel-sort это optimal cache-oblivious out-of-place алгоритм, основанный на merge sort. В то время, как quicksort — in-place. Подозреваю что как и у merge sort, при переходе к in-place, сложность funnel-sort возрастёт до O(N ln^2 N), если такой переход вообще возможен.

K>Да и как divide-and-conquer quick sort — не фонтан. Потому, что качество деления у него от данных зависит (во отличие от той же сортировки слияниями).

Оно хоть и зависит от данных, но в подавляющем большинстве случаев даёт прекрасный результат. Например, если получится каждый уровень разбивать как 1 к 10, то всё-равно получаем сложность O(N ln N).
Да и вообще, quicksort до сих пор считается одним из самых многосторонне-быстрых алгоритмов сортировки, поэтому непонятно про какую тормознутость идёт речь.

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

I>>>Нужно осмысление. Как это в твою идею вписать — не ясно.
EP>>Осмысление чего и зачем?
I>вычисления последовательности Фибоначчи.

А как ты её осмысляешь?

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

Для повторного применения, никакое осмысление не нужно.

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

Потому что выше именно комбинаторы назвали идиоматичным ФП.

I>И почему надо сравнивать с простым итерационным методом, а не брать модный MVC-фремворк с серверным бакэндом ?

Потому что просто, эффективно и идиоматично.

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

А ты о чём вообще споришь? О том что "идиоматичный ФП":

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

проще понять, а потом применить?

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

I>>>>Нужно осмысление. Как это в твою идею вписать — не ясно.
EP>>>Осмысление чего и зачем?
I>>вычисления последовательности Фибоначчи.

EP>А как ты её осмысляешь?

По всякому, разные представления, свойства и тд.

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

EP>Для повторного применения, никакое осмысление не нужно.

Без осмысления ты не сможешь понять, что вон то нечто, это последовательность, и не просто последовательность, а её можно свести к фибоначчи или, например, заменить на фибоначчи.

Вот смотри, простой пример — есть 10 яблок, по 10 рублей, всего это стоит 10*10, 11 яблок по 10 рублей — 11*10, 12 яблок по 10 рублей — 12*10.
Осмысление требуется уже для того, что бы
1 абстрагироваться от количества яблок и выдать формулу x*10
2 применить конкретное значение к формуле и получить нужный результат, то есть, 3 яблока по 10р, это вместо x в формуле x*10 подставить 3

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

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

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

EP>Потому что выше именно комбинаторы назвали идиоматичным ФП.

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

I>>И почему надо сравнивать с простым итерационным методом, а не брать модный MVC-фремворк с серверным бакэндом ?

EP>Потому что просто, эффективно и идиоматично.

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

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

EP>А ты о чём вообще споришь?

Не я, а ты. Например ты, внезапно, решил что думать не надо.

О том что "идиоматичный ФП":
EP>

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

проще понять, а потом применить?

Это конкретный вариант. Он сложен не потому, что хаскель и фп, а потому что идиоматический код сложен просто потому что он идиоматический.

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

I>>>Затем, что бы знание можно было применить повторно, тем самым ребенком которому ты собираешься чего то объяснять.
EP>>Для повторного применения, никакое осмысление не нужно.
I>Без осмысления ты не сможешь понять, что вон то нечто, это последовательность, и не просто последовательность, а её можно свести к фибоначчи или, например, заменить на фибоначчи. [...]
I>Фибоначчи это последовательность с кучей свойств, скажем, есть последовательность, которая может быть и не похожа на фибоначчи, но может быть сведена к ней. И здесь точно так же будет и абстрагирование и применение.

Речь шла про вычислитель в голове:

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

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

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

Это почему ещё идиоматический код обязательно является сложным для понимания?

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

EP>>>>>>Да и вообще, как только у нас есть while или аналог — то "можно делать плохие вещи".
S>>>>>И далеко не всякий аналог while даёт нам возможность "делать плохие вещи".
EP>>>>Если нет возможности сделать вечный цикл — то это не аналог while.
S>>>А для чего вам вечный цикл?
EP>>Для полноты по Тьюрингу.
S>А для чего вам полнота по Тьюрингу?

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

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

EP>>Опять 25. Почему они не работающие? Они работают даже для ресурсов в отличии от.
I>Не работают. Это обеспечивается _руками_. Что будет, я объявлю свой враппер, где не буду переопределять никакие операторы, а деструкторе тупо грохну ресурс через метод навроде ::Close() ?

И не уберёшь конструктор копирования? — тогда нарушишь семантику определённую стандартом. Создал кривой враппер — ССЗБ.

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

EP>Речь шла про вычислитель в голове:
EP>

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

EP>Такой вычислитель, как мы выяснили, естественен для человека.

Нет, он НЕ естественен для человека. Что бы использовать такой вычислитель, нужно иметь хорошее абстрактное мышление. Люди учатся этому десятками лет, а многие никогда не смогут осилить этот подход.

EP>Умение же абстрагироваться от задачи, её осмысление до такой степени, при которой получается применять те же знания совершенно в другой плоскости — это ортогонально наличию вычислителя. Компьютеры, например, так не умеют, но вычислителем от этого быть не перестают

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

I>>Это конкретный вариант. Он сложен не потому, что хаскель и фп, а потому что идиоматический код сложен просто потому что он идиоматический.

EP>Это почему ещё идиоматический код обязательно является сложным для понимания?

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

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

EP>>>Опять 25. Почему они не работающие? Они работают даже для ресурсов в отличии от.
I>>Не работают. Это обеспечивается _руками_. Что будет, я объявлю свой враппер, где не буду переопределять никакие операторы, а деструкторе тупо грохну ресурс через метод навроде ::Close() ?

EP>И не уберёшь конструктор копирования? — тогда нарушишь семантику определённую стандартом. Создал кривой враппер — ССЗБ.

То есть, ты согласен, что гарантии нужно обеспечивать руками, но почему то стесняешься это признать и приплетаешь сюда понятия навроде ССЗБ.

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

EP>>>>Опять 25. Почему они не работающие? Они работают даже для ресурсов в отличии от.
I>>>Не работают. Это обеспечивается _руками_. Что будет, я объявлю свой враппер, где не буду переопределять никакие операторы, а деструкторе тупо грохну ресурс через метод навроде ::Close() ?
EP>>И не уберёшь конструктор копирования? — тогда нарушишь семантику определённую стандартом. Создал кривой враппер — ССЗБ.
I>То есть, ты согласен, что гарантии нужно обеспечивать руками, но почему то стесняешься это признать и приплетаешь сюда понятия навроде ССЗБ.

1. Конкретно в этом месте — грабли языка, конструктор копирования и оператор присваивания просто не должны генерироваться автоматом при наличии ручного деструктора — также как и конструктор перемещения (если же нужен автоматический, то есть =default).
2. В общем случае, работа с памятью в C++ требует больше усилий и знаний, чем в управляемых языках, но тем не менее в большинстве случаев достаточно автоматизирована.
3. Абсолютно тот же самый механизм, что и для работы с памятью, применим и ко всем остальным ресурсам. Добавление одного ресурса в широко используемый объект, не влечёт за собой транзитивный каскад правок всех тех мест, которые напрямую или косвенно зависят от этого объекта, в отличии от управляемых языков. Или, например, можно создать замыкание с ресурсом внутри, в отличии от.

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

EP>>Речь шла про вычислитель в голове:
EP>>

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

EP>>Такой вычислитель, как мы выяснили, естественен для человека.
I>Нет, он НЕ естественен для человека. Что бы использовать такой вычислитель, нужно иметь хорошее абстрактное мышление. Люди учатся этому десятками лет, а многие никогда не смогут осилить этот подход.

Я привёл уже десятки примеров

Автор: Evgeny.Panasyuk
Дата: 08.02.14

, которые ты проигнорировал.

EP>>Умение же абстрагироваться от задачи, её осмысление до такой степени, при которой получается применять те же знания совершенно в другой плоскости — это ортогонально наличию вычислителя. Компьютеры, например, так не умеют, но вычислителем от этого быть не перестают
I>Компьютер пока что ничего не умеет в той области, про которую мы говорим. Если ты явно не опишешь проблему и метод решения, компьютер ни за что не догадается, что там можно применить последовательность фибоначчи. Как раз потому, что нет у него никакого осмысления — все связи между понятиями захардкожены и компьютер не умеет образовывать новые по ходу работы.

То есть получается:
* Дети и компьютеры не могут осмыслить последовательность Фибоначчи.
* Дети и компьютеры могут вычислить её итерационным методом.
Так?

I>>>Это конкретный вариант. Он сложен не потому, что хаскель и фп, а потому что идиоматический код сложен просто потому что он идиоматический.
EP>>Это почему ещё идиоматический код обязательно является сложным для понимания?
I>Потому что для понимания, изучения нужно сделать больше умственных затрат. Сначала изучаешь базовые вещи, а у же потом раскладываешь идиомы на базовые, а далее строишь идиомы из базовых. Просто из воздуха нахватать идиом не получится.

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

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

EP>Я привёл уже десятки примеров

Автор: Evgeny.Panasyuk
Дата: 08.02.14

, которые ты проигнорировал.

Наоборот, я показал что у всех примеров есть один и тот же дефект

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

EP>То есть получается:
EP>* Дети и компьютеры не могут осмыслить последовательность Фибоначчи.
EP>* Дети и компьютеры могут вычислить её итерационным методом.
EP>Так?

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

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

Я не в курсе как ты сложность понимаешь. Вот до того, как люди узнают про производные и интегралы им надо много трудозатрат что бы решить задачу. Пока производные и интегралы не знают, методы решения на них основаные, будут сложными.
Более того, пока они руками не построят N графиков, не решат K Задач на площади и тд, сами производные и интегралы будут сложны.
А вот как освоили, внезапно, все это становится простым и дело исключительно в трудозатратах на запись решения.

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

EP>3. Абсолютно тот же самый механизм, что и для работы с памятью, применим и ко всем остальным ресурсам. Добавление одного ресурса в широко используемый объект, не влечёт за собой транзитивный каскад правок всех тех мест, которые напрямую или косвенно зависят от этого объекта, в отличии от управляемых языков. Или, например, можно создать замыкание с ресурсом внутри, в отличии от.

Время жизни ресурса должно совпадать со временем жизни объекта. Если это не так, придется расставлять нужные вызовы -> транзитивный каскад правок или же часто приходится пользоваться нужными врапперами и смартпоинтерами -> транзитивный каскад правок.
В менеджед, если объект уже ресурс, то не надо никаких транзитивных правок. Далее, если объект не ресурс, нужно правильно расставить вызовы Dispose -> транзитивный каскад правок.

Вобщем, ситуация примерно одинаковая.

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

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

Практически основной use-case. Посмотри хотя бы на типичную реализацию Dispose.

I>Если это не так, придется расставлять нужные вызовы -> транзитивный каскад правок или же часто приходится пользоваться нужными врапперами и смартпоинтерами -> транзитивный каскад правок.
I>В менеджед, если объект уже ресурс, то не надо никаких транзитивных правок.

Согласен.

I>Далее, если объект не ресурс, нужно правильно расставить вызовы Dispose -> транзитивный каскад правок.

Да, Dispose + using'и.

I>Вобщем, ситуация примерно одинаковая.

Нет.
1. Основной use case — scoped lifetime: в C++ нет каскада правок, в C# — есть.
2. Редкий use case — ресурс нужно освободить до начала смерти объекта, в соответствии с некоторой хитрой логикой, которая не просто задаётся в одном блоке кода (без каскадных правок), а ещё требует правок всех зависимых объектов: нужны правки и в C++ и в C#.

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

EP>Видимо для реализации любой вычислимой функции.
EP>Но согласен, не для каждой задачи нужна полнота — тем не менее, аналог while есть практически в каждом современном языке, а соответственно "можно делать плохие вещи".
Повторюсь: далеко не всякий аналог while даёт нам возможность "делать плохие вещи".

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

I>>Время жизни ресурса должно совпадать со временем жизни объекта.

EP>Практически основной use-case. Посмотри хотя бы на типичную реализацию Dispose.

Что я должен там увидеть ?

I>>Вобщем, ситуация примерно одинаковая.

EP>Нет.
EP>1. Основной use case — scoped lifetime: в C++ нет каскада правок, в C# — есть.

Не так — в C# каскадные правки нужны только тогда, когда добавляется интерфейс. В С++ если объект становится ресурсом, далеко не факт, что использовать его можно точно так же , как и раньше.

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

I>>>Время жизни ресурса должно совпадать со временем жизни объекта.
EP>>Практически основной use-case. Посмотри хотя бы на типичную реализацию Dispose.
I>Что я должен там увидеть ?

Совпадение времени жизни ресурса с временем жизни объекта.

I>>>Вобщем, ситуация примерно одинаковая.
EP>>Нет.
EP>>1. Основной use case — scoped lifetime: в C++ нет каскада правок, в C# — есть.
I>Не так — в C# каскадные правки нужны только тогда, когда добавляется интерфейс.

И что это меняет?

I>В С++ если объект становится ресурсом, далеко не факт, что использовать его можно точно так же , как и раньше.

Это не факт только в особо маргинальных случаях, часто и так являющимися undefined behavior.