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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но пассаран!

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

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

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

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

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

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

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

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

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

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

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

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

и нет необходимости в ПМ В чём?

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

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

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

аннотации ленивости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

value?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

аминь!

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

Псевдокод.

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

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

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

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

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

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

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

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

тролли +5 ?

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

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