@qrilka, большинство мыслит императивно, потому что первым языком дают сишку

@qrilka, до тех пор пока нет статистики и опытов на живых людях и то и другое — просто болтология

@alar, в том мнении, что я привёл "большинство" == "большинство человеков" (т.е. включая тех кому никаких языков не давали)

@qrilka, ну вот, опять передёрнуто.
1) Функциональная парадима прекрасно годится для абстрагирования. Проблемы у Хаскелля с порядком вычислений, а не с чистыми функцияцми
2) Большинство разработчиков мыслит не императивно , а энергично.

@alar, да и кому это дают первым сишку? я таких не знаю, например

@zamotivator, Олег, не пиши хуйни не по теме, пожалуйста

@qrilka, я начинал с васика, но первым серьёзным языком была таки сишка

@qrilka, это не по теме?... У тебя ложная посылка и неверный вывод в /0

@qrilka, у меня поцкаль был

@zamotivator, разберись для начала с тем, что я написал, потом поговорим

@qrilka, У меня поднимается почти непреодолимое желание отправить тебя в пешее эротическое путешествие, но я смог удержаться
Объясни мне, пожалуйста, что именно я из написанного тобой не понял?
"прямо противоположно широко распространённому мнению, что большинство мыслит императивно" — то, что люди не в теме функциональной парадигмы называют словом "императивно" — это энергичное вычисление, а вовсе не наличие побочных эффектов
Можно сказать иначе — люди часто рассматривают работу программы как последовательность действий. Это закладывается ещё в школе во многих предметах, как естественно-научных, так и гуманитарных.

@qrilka, то, что большинство мыслит императивно и что ООП — естественное преставление вещей, придумали тупые дураки.

@zamotivator,
рассматривают работу программы как последовательность действийТащемта, это и называется "императивно"

@alar, Нет, нет, и ещё раз нет.
Есть энергичное выполнение, есть ленивое выполнение. Последовательное выполнение — энергичное. on-demand — ленивое
Императивность или функциональность отдельной функции вытекает не из порядка вычислений, а из наличия или отсутствия изменяемого состояния

@Zert, большинство мыслит императивно не потому что моск так устроен, а потому что их так научили.

@alar, большинство тащемта вообще никак не мыслит

@zamotivator, на деле разница между последовательным и on-demand выполнением не совсем биективно отражается на энергичное и ленивое, но это в разы ближе друг другу, чем императивность или функциональная чистота.
Другими словами, императивность и функциональность ВООБЩЕ не зависит от порядка вычислений

@Zert, правильный коммент. Пока не указано "большинство кого", можно вообще пейсать любые фантазии.

@zamotivator, *чем императивность или функциональная чистота [по отношению к порядку вычислений]

@zamotivator, ну а теперь привяжи свои вбросы про функциональню чистоту к фразе "procedural mind" из цитаты

@qrilka, да я по ссылке даже не ходил. Я на твоём посте базируюсь, а в нём передёрнуто

@zamotivator, твою мать, Олег, это фраза из моего поста, в котором есть цитата, ну читать научись уже, а?

@qrilka, я в курсе. Только передёрнуто не в цитате, передёрнуто в твоих словах — как по отношению к самой цитате, так и по отношению к рунету

@zamotivator, мда, en.wikipedia.org — прочитай хотябы отсюда пару предложений, если ты не согласен с общепринятыми терминами, то заводи себе свой глобус, я не вижу, что тут обсуждать.

@qrilka, Зогбиватор при виде словосочетания «функциональное программирование» теряет волю

@Zert, видать, написание рсс-ридера на Эрланге его совсем вывело из колеи...

@qrilka, ерланг кеннот инто императивное программирование

@qrilka, "many are amazed that Haskell is a programming language." — а они думали, что это просто аски-арт?

@trapdoor, Псевдокод.

@alar, Не думаю, что стоит спорить с Забиватором о том, что "люди не в теме функциональной парадигмы" понимают под какими-то словами. Ему, очевидно, виднее.

@klapaucius, не спорь с Забиватором, теребя монады у себя в квартале

@qrilka, ЕМНИП, методики обучения детей информатике и программированию в младших классах предполагают использование некоего робота, которого ребёнок заставляет делать какую-то работу. Т.е. их учат записывать последовательность действий, вполне себе императивную.

@dr-Chaos, ну тут уже не совсем младшие, да и Gobstones (с которого начинается обучение) из статьи по идее императивный

@qrilka, Это скорее объяснение откуда может браться procedural mind.

@dr-Chaos, ну да, перечитал, понял твой пойнт

@zamotivator,
Это закладывается ещё в школе во многих предметах, как
естественно-научных, так и гуманитарных.
Это не так. Начнём с того, что в школе почти нет такой области где рассматривают не то что программу, но вообще последовательность действий. Наиболее близким к означенной области является решение арифметических задач, которые школьные математики учат решать как раз таки не строго.

@ndtimofeev, Покажите мне алгоритмы решения задач отличные от последовательности действий

@zamotivator, алгоритм задаёт не последовательность, а порядок действий

@dr-Chaos, и в чем ты видишь семантическую разницу между последовательностью действий и порядком действий в данном конкретном вопросе?

@zamotivator, ru.wikipedia.org Первый абзац.

@dr-Chaos, хорошо, замечательно. Но решают задачи именно что последовательно применяя шаги.
Произвольного порядка выполнения операций нет нигде.

@zamotivator, а почему ты произвольный порядок вспомнил?

@dr-Chaos, потому что ключевые затыки с haskell связаны не с императивностью или функциональностью, с порядком вычислений.

@zamotivator, *а с порядком вычислений

@zamotivator, и что он стал от этого произвольным?

@dr-Chaos, с точки зрения человека — произвольным, детерминированность ты напрямую не увидишь.
Выполнение программ на языке Haskell — это редукция лямбда-выражения в нормальную форму
Но никто не смыслит о программах как о лямбда-выражениях, о них мыслят в терминах данных и выполняемых с ними операциях (т.е. последовательностях шагов)

@zamotivator, это лишь вопрос методики преподавания. Как учат, так и мыслят.

@zamotivator, У меня есть сомнения в возможности применять ленивый и не чистый язык. Тут в хаскеле то бывает жопа с ленивым вводом/выводом, а если к этому добавить повсеместную мутабельность…

@zamotivator, мне в процессе прочтения SICP-а стало сразу понятно про порядки вычислений.

@dr-Chaos, ты всерьёз считаешь удобным представляешь программу в виде списка комбинаторов или лямбда термов?
А числа — в виде нумералов Чёрча?

@dr-Chaos, и что, ты заранее сможешь сказать про порядок редукции?

@zamotivator, Какой хитрый. Когда человек решает задачку по математики и он не программист, а вычислитель. :^) И он редуцирует выученную программу и таки не строгим образом. Чтобы вычислять меньше было.

@ndtimofeev, я нигде не писал против чистоты. Я писал против ленивости

@ndtimofeev, вы хотите сказать, что задачи по математике отличаются от задачек по программированию?
Я в каком-то смысле готов согласиться — в вопросах про архитектуру, дизайн, вёрстку, но никак не в вопросах о general purpose programming languages

@zamotivator, Олег против ленивости!

@dr-Chaos, но пассаран!

@zamotivator, Если вы против ленивости, то что вы предлагаете взамен?

@klapaucius, энергичность по умолчанию, опциональные call-by-name

@dr-Chaos, Сразу представил себе серию мультиков где вместо олимпийского мишки бежит Зефиров с факелом, а вокруг летает @zamotivator и строит козни. Кастинг на остальные роли (там вроде бы был Змей Горыныч и Кащей Бессмертный) остаётся открытым.

@zamotivator, Так вы тогда и против чистоты. Вы понимаете какие у seq проблемы с читстотой?

@klapaucius, я не против чистоты. Чистота никак не мешает энергичности.

@zamotivator, haskell.org тут всьо написано

@dr-Chaos, да, помню. Не вижу противоречий с моими словами.

@zamotivator, Вы против, просто об этом не знали. Такое бывает. Но теперь знаете и можете себя позиционировать корректнее — тогда и вопросов к вам не будет.

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

@zamotivator, Нет не путаю. Вы замучаетесь писать чисто функционально без ленивости по умолчанию. Закончится это или отказом от чистоты или аннотацией большинства тривиальных ПМ как ленивых. Потому, что ленивые аннотации, в отличие от строгих, распространить автоматически невозможно.

@klapaucius,
Вы замучаетесь писать чисто функционально без ленивости по умолчанию.Это ещё почему? Я чисто функционально на С++ пишу и не ослеп

@zamotivator, может потому, что там это 1% фунций и нет необходимости в ПМ и автоматическом распространении ленивости?

@dr-Chaos,
и нет необходимости в ПМ В чём?

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

@zamotivator, Вы бы попробовали что-то писать на чистых ФЯ, а то у вас о чисто-функциональном, похоже, очень нетрадиционное представление.

@klapaucius, писал на Ocaml и Scala. Без mutable и var. Не, не засчитывается?

@zamotivator, очевидно, чтобы не писать вручную

@zamotivator, Во-первых, mutable и var не единственные способы нарушать чистоту в этих языках. Во-вторых, писать на окамле и скале в чисто функциональном стиле невозможно, никто этого и не делает. Т.е. как я и говорил, представление о таком стиле у вас сильно нетрадиционное.

@dr-Chaos, я потерял нить. Что вручную писать? Зачем?

@zamotivator, аннотации ленивости

@klapaucius, а с каких это пор вы считаете себя единственно правильным носителем понимания выражения "функциональный стиль"?
Я лично пользуюсь определением "функция на одних и тех же аргументах должна выдавать один и тот же результат и в процессе своей работы не менять состояние окружающего мира и не читать его"

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

@dr-Chaos, lazy val ....., a => b... не вижу никакой в этом трагедии.
Как правило, их немного относительно основного кода

@klapaucius, вы опять путаете функциональную чистоту и ленивость выполнения.
Мне это уже надоело. Идите уже и прочитайте определения

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

@zamotivator, Если вы не понимаете о чем я говорю — это еще не значит, что я что-то путаю.

@klapaucius,
Я, наоборот, носитель понимания общепринятого. Поделитесь общепринятым, носитель

Ваше определение чистой функции, кстати, слишком строгое. Да, есть ньюансы насчёт стриминга мира через переменные

@klapaucius, я даже не знаю, стоит ли ещё пытаться получить аргументацию, или уже можно, наконец, перейти к оскорблениям

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

@klapaucius, это какая-то шизофрения. Функциональный и императивный способ реализации функции говорят ровно об одном — модифицируем ли мы какие-либо переменные или не модифицируем.
Ленивое или энергичное выполнение говорят про порядок вычисления функции и ничего не говорят о её свойствах
И кто из нас путает?

@zamotivator, А смысл? Я про seq упоминал, вы это проигнорировали, на голубом глазу утверждая, что никакого противоречия вашим взглядам в этом нет.
Но аргументы привести несложно. Функциональное программирование подразумевает написание программ в виде композиции комбинаторов. Практически полезные комбинаторы, чтоб их можно было комбинировать, должны предоставлять возможности вроде раннего завершения. Значит большинство функций, чтоб они могли соединятся с другими — вам придется покрывать аннотациями ленивости, которые потом распространять дальше, пока весь код не будет ими замусорен. Либо отказаться от комбинирования комбинаторов и писать рекурсивную лапшу всякий раз, когда вас будет волновать с какой асимптотикой и какими константными факторами это работает. Ну вот в окамле в основном рекурсивную лапшу вместо комбинаторов и пишут. а когда пишут библиотечные комбинаторы — внутри у комбинаторов императивный балаган.

@klapaucius,
Функциональное программирование подразумевает написание программ в виде композиции комбинаторов. Неверная посылка. вы понимаете функциональное программирование крайне узко. Оно у вас по определению композиция комбинаторов.
Таких языков ровно один — это Haskell.
Но Haskell не единственный функциональный язык программирования, и уж тем более не всякий функциональный язык программирования представляет программу в виде композиции комбинаторов

@zamotivator, ну это как бы суть ФП комбинировать из функций программу. Не?

@dr-Chaos, Это спекулятивный вопрос. Вот есть ООП парадигма, есть структурно-процедурная, есть функциональная.
Парадигмы говорят про способы организации исходного кода, дизайн программы, и ничего не говорят про способ реализации языка.
ООП ничего не говорит про vtable. ФП ничего не говорит про комбинаторы. Структурно-процедурное программирование — про аллокаторы

@zamotivator, Нормально понимаю. Это и есть функциональное программирование. Разумеется, разные ФЯ имеют разную степень поддержки ФП. И в строгих ФЯ эта поддержка хуже, чем в ленивых. Почему — я написал.

@klapaucius, /89

@zamotivator,
ФП ничего не говорит про комбинаторыДа ну? А что оно говорит тогда? Потому что это не какая-то деталь реализации как в соседних примерах — это сама суть ФП и есть. И если выкинуть из ФП комбинирование комбинаторов — там вообще ничего не останется.

@klapaucius,
Да ну? А что оно говорит тогда? О свойствах функций.

Потому что это не какая-то деталь реализации как в соседних примерах — это сама суть ФП и есть.Дааа? И числа вы тоже в виде нумералов Чёрча представляете?

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

@klapaucius, <здесь должно быть оскорбление>

@zamotivator, приведу тебе пример простого комбинатора 2х функций (.) . Это совсем не vtable или аллокаторы. Если слово комбинатор тебе непонятно, можно просто использовать ФВП.

@zamotivator, Обычно нет. И что? Числа и в ООП обычно не являются нормальными объектами. Что из этого вашего утверждения следует? Ну да, если из ФП выкинуть комбинаторы — останутся машинные числа, которые останутся и если из ООП объекты выкинуть.

@klapaucius, 3.times({|echo 'НЕТ!'|})

@zamotivator, Ну правильно. Что вам еще остается-то?

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

@klapaucius, это конкретное возражение было про то что числа не объекты

@max630, А, понял, это по поводу объектов. Не понял, из-за того, что древовидное представление "сплющивается" на таких уровнях.
Ну, я же сказал "обычно". А не "всегда".

@qrilka, 100 комментов набрали. Будет ли 200?

@max630, Да я сам понял уже. Кстати, объект — это не просто "что-то у чего вызываем метод через точку". У объекта должно быть идентити. А у чисел его нет. Потому, что 3 == 3, а будь эти тройки объектами — они бы были не равны. поэтому числа нормальными объектами обычно и не являются.

@alar, Так ведь большинство — оффтопик.

@klapaucius, А почему когда 3 является объектом, 3 != 3?
Что-то я вообще связи не улавливаю.

@tzirechnoy, Если эти тройки объекты, то тут конструируется два объекта, с чего бы им быть равными? У них разное идентити — они по разным адресам располагаются, например. А в структурном сравнении нет ничего объектного. Аналогично и с состоянием — тройки иммутабельны, сделать одну из них четверкой, а другую десяткой, например, мы не можем. Ну а без идентити и состояния — что вообще остается от объекта?

@klapaucius, value?

@klapaucius, А почему — два, если они равны?

@dr-Chaos, Ну да. По-моему, объекты с value-семантикой не являются нормальными объектами в смысле ООП. Это гибридная, межпарадигменная концепция.

@klapaucius, И да, с адресами — тожэ смешно. В Java вон тожэ одиин объект по куче адресов располагается..

@klapaucius, И да, тройки иммутабельны. От -сотворения мира- разработки алгебры натуральных чисел или дажэ раньшэ. Как и многие другие объекты. И что?

@tzirechnoy, А почему они равны? В чистом ооп они могут быть равны, если 3 не объект, а ссылка на некий синглетон s3.

@tzirechnoy, Нормальные объекты не должны быть иммутабельны. О чем — особом положении числе в ООП — и речь в данном случае.

@klapaucius, Опять разговоры про чистое и нечистое ООП?
Вам ещё не смешно?

@tzirechnoy, Вы отрицаете, что бывает ООП чистое, а бывает — гибридное?

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

@tzirechnoy, Ок. Допустим, для объекта не иметь состояния и идентити — так же нормально, как и иметь их. Чем тогда по-вашему объект отличается от не объекта. Как вы его вообще определяете?

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

Я, при этом, вполне допускаю, что в Симуле и АДА-80 ООП был вовсе не-ООП, но это не отменяет вышэсказанного.

@klapaucius, Так идэнтити у объектов класса int есть, если чо. 3 == 3, но 3 != 4.

@klapaucius, И да, объект от не-объекта отличается инкапсуляцыей, наследованием, и, как следствие, полиморфизмом.

@zamotivator, Речь шла не столько о твоей гражданской позиции, сколько о том, что дихотомии чистый/не чистый и строгий/ленивый не вполне ортогональны.

@tzirechnoy, Я не говорил, что это "недоООП". Это скорее пере-ООП или пост-ООП. Или вообще не-ООП. И речь не о правильности, а о проблеме демаркации. Если мы будем называть объектом все что угодно, без всяких оговорок, то содержательная часть ООП-теории (и так, прямо скажем, не богатая) просто сойдет на нет вовсе.

@klapaucius, Я не возражаю против того, чтобы в некоторых языках что-то было объектом, а что-то нет.
Например, в той жэ Java числа скорее объектом не являются (хотя тожэ, как посмотреть).

Но почему из того, что числа являются объектом (как в smalltalk или python) должно следовать 3 != 3 — я в упор понять не могу.

@ndtimofeev, Они достаточно ортогональны. Не понимаю, почему он все время возвращается к тому, что их кто-то якобы путает. Речь то не об этом, а о том, что не все сочетания практичны и удобны. И чистым, но энергичным языком будет просто неудобно пользоваться, а императивным и ленивым — еще неудобнее.

@tzirechnoy, Потому, что надо как-то отличать объект от необъекта, например значения алгебраического типа. Если у объекта есть стейт и идентити, а у значения АТД нет ни первого (оно иммутабельно) ни второго (на значениях задана структурная эквивалентность) — все понятно. А если у объекта может быть или не быть все что угодно, то что такое тогда вообще объект?

@klapaucius, Идэнтити у экземпляра АТД есть. Куда оно денется.
И я в упор не понимаю, почему объект не можэт являться АТД.

@tzirechnoy, Нет его. (Ну, если не считать адовых хаков с получением указателей и их сравнением, которые почти во всех реализациях ФЯ возможны, но относятся к приемам, когда все ставки отменяются и на нормальную семантику языка уже нельзя рассчитывать).
Если объект может являться в том числе и значением алгебраического типа, то что тогда объект. Или, зайдем с другой стороны, чем объект не является. (на самом деле, в ООП, часто утверждается что объектом как раз и является все что угодно, но пользы от такого определения, по понятным причинам нет).

@tzirechnoy, Вы, по-моему, не понимаете, что такое идентити.

@tzirechnoy, Идентити как раз позволяет определить, что вот эти две тройки — не одно и то же, потому что объекты разные. А вот эти две тройки — один и тот же объект. И вот эта тройка и эта четверка — тоже одно и то же, просто состояние объекта тройка изменили на четверку, а объект-то остался тот же самый.

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

@zamotivator, на Scala ты писать не умеешь, так что нет

@jdevelop, подробности давай!

@alar, их не будет, но можно мне поверить на слово — я видел, как он "пишет" на скале.

@klapaucius, А по-моему, это как раз Вы не понимаете что такое идэнтити.

@Zert, аминь!

@max630, IORef ведет себя как раз как иммутабельный — как обычная стейт-монада, то что там есть что-то мутабельное за кадром — деталь реализации, без unsafe лазеек эту мутабельность пронаблюдать нельзя. А вот рефы в ML-ях да, практически объекты. Собственно, после изобретения рефов и "префиксинга" ООП и появился.
Идентити — не обязательно связана с мутабельностью. Она, конечно, означает, что мутабельный объект остается самим собой, даже если поменять все значения в его полях, но она так же означает, что два разных объекта с одинаковыми значениями в полях не являются идентичными, а каждый опять таки остается самим собой. Это и иммутабельных объектов касается.

@klapaucius, эта "само-собость" ненаблюдаема. И не абсолютна, даже сраный C++ может копировать или переиспользовать константное значение на своё усмотрение при оптимизации. А то что можно увидеть с точки зрения поведения — именно синхронность изменений.

@max630, Не согласен, в ООП она как раз как правило наблюдаема. Исключения, разумеется, бывают ("объекты" с value-семантикой). Но в нормальном ООП она должна быть наблюдаема в большинстве случаев.

@klapaucius, забиватор-тред :D

@qrilka, linux.org.ru
juick.com
астрологи объявили месяц специальной олимпиады

@jtootf, тролли +5 ?

@jtootf, вроде ещё и осень даж не настала...

@qrilka, зато весна не кончилась