-
чувак заменил питон на хацкель для обучения старшеклассников — sawafaso.blogspot.com.ar из интересных выводов — Many children have not a procedural mind, but they can abstract a lot, so we can take a very good aproximation exploiting this. — прямо противоположно широко распространённому мнению, что большинство мыслит императивноRecommended by (2): @ndtimofeev, @ymn
Replies (144)
-
-
@zamotivator, разберись для начала с тем, что я написал, потом поговорим
-
@qrilka, У меня поднимается почти непреодолимое желание отправить тебя в пешее эротическое путешествие, но я смог удержаться
Объясни мне, пожалуйста, что именно я из написанного тобой не понял?
"прямо противоположно широко распространённому мнению, что большинство мыслит императивно" — то, что люди не в теме функциональной парадигмы называют словом "императивно" — это энергичное вычисление, а вовсе не наличие побочных эффектов
Можно сказать иначе — люди часто рассматривают работу программы как последовательность действий. Это закладывается ещё в школе во многих предметах, как естественно-научных, так и гуманитарных. -
@zamotivator,
рассматривают работу программы как последовательность действий
Тащемта, это и называется "императивно" -
@alar, Нет, нет, и ещё раз нет.
Есть энергичное выполнение, есть ленивое выполнение. Последовательное выполнение — энергичное. on-demand — ленивое
Императивность или функциональность отдельной функции вытекает не из порядка вычислений, а из наличия или отсутствия изменяемого состояния -
@zamotivator, на деле разница между последовательным и on-demand выполнением не совсем биективно отражается на энергичное и ленивое, но это в разы ближе друг другу, чем императивность или функциональная чистота.
Другими словами, императивность и функциональность ВООБЩЕ не зависит от порядка вычислений -
@zamotivator, *чем императивность или функциональная чистота [по отношению к порядку вычислений]
-
@zamotivator, ну а теперь привяжи свои вбросы про функциональню чистоту к фразе "procedural mind" из цитаты
-
@qrilka, да я по ссылке даже не ходил. Я на твоём посте базируюсь, а в нём передёрнуто
-
@zamotivator, твою мать, Олег, это фраза из моего поста, в котором есть цитата, ну читать научись уже, а?
-
@qrilka, я в курсе. Только передёрнуто не в цитате, передёрнуто в твоих словах — как по отношению к самой цитате, так и по отношению к рунету
-
@zamotivator, мда, en.wikipedia.org — прочитай хотябы отсюда пару предложений, если ты не согласен с общепринятыми терминами, то заводи себе свой глобус, я не вижу, что тут обсуждать.
-
@alar, Не думаю, что стоит спорить с Забиватором о том, что "люди не в теме функциональной парадигмы" понимают под какими-то словами. Ему, очевидно, виднее.
-
@klapaucius, не спорь с Забиватором, теребя монады у себя в квартале
-
@zamotivator,
Это закладывается ещё в школе во многих предметах, как
естественно-научных, так и гуманитарных.
Это не так. Начнём с того, что в школе почти нет такой области где рассматривают не то что программу, но вообще последовательность действий. Наиболее близким к означенной области является решение арифметических задач, которые школьные математики учат решать как раз таки не строго. -
@ndtimofeev, Покажите мне алгоритмы решения задач отличные от последовательности действий
-
@zamotivator, алгоритм задаёт не последовательность, а порядок действий
-
@dr-Chaos, и в чем ты видишь семантическую разницу между последовательностью действий и порядком действий в данном конкретном вопросе?
-
@dr-Chaos, хорошо, замечательно. Но решают задачи именно что последовательно применяя шаги.
Произвольного порядка выполнения операций нет нигде. -
@dr-Chaos, потому что ключевые затыки с haskell связаны не с императивностью или функциональностью, с порядком вычислений.
-
@dr-Chaos, с точки зрения человека — произвольным, детерминированность ты напрямую не увидишь.
Выполнение программ на языке Haskell — это редукция лямбда-выражения в нормальную форму
Но никто не смыслит о программах как о лямбда-выражениях, о них мыслят в терминах данных и выполняемых с ними операциях (т.е. последовательностях шагов) -
@zamotivator, это лишь вопрос методики преподавания. Как учат, так и мыслят.
-
@zamotivator, У меня есть сомнения в возможности применять ленивый и не чистый язык. Тут в хаскеле то бывает жопа с ленивым вводом/выводом, а если к этому добавить повсеместную мутабельность…
-
@zamotivator, мне в процессе прочтения SICP-а стало сразу понятно про порядки вычислений.
-
@dr-Chaos, ты всерьёз считаешь удобным представляешь программу в виде списка комбинаторов или лямбда термов?
А числа — в виде нумералов Чёрча? -
@dr-Chaos, и что, ты заранее сможешь сказать про порядок редукции?
-
@zamotivator, Какой хитрый. Когда человек решает задачку по математики и он не программист, а вычислитель. :^) И он редуцирует выученную программу и таки не строгим образом. Чтобы вычислять меньше было.
-
@ndtimofeev, я нигде не писал против чистоты. Я писал против ленивости
-
@ndtimofeev, вы хотите сказать, что задачи по математике отличаются от задачек по программированию?
Я в каком-то смысле готов согласиться — в вопросах про архитектуру, дизайн, вёрстку, но никак не в вопросах о general purpose programming languages -
@zamotivator, Если вы против ленивости, то что вы предлагаете взамен?
-
@klapaucius, энергичность по умолчанию, опциональные call-by-name
-
@dr-Chaos, Сразу представил себе серию мультиков где вместо олимпийского мишки бежит Зефиров с факелом, а вокруг летает @zamotivator и строит козни. Кастинг на остальные роли (там вроде бы был Змей Горыныч и Кащей Бессмертный) остаётся открытым.
-
@zamotivator, Так вы тогда и против чистоты. Вы понимаете какие у seq проблемы с читстотой?
-
@klapaucius, я не против чистоты. Чистота никак не мешает энергичности.
-
@zamotivator, Вы против, просто об этом не знали. Такое бывает. Но теперь знаете и можете себя позиционировать корректнее — тогда и вопросов к вам не будет.
-
@klapaucius, я выше всё сказал. Вы путаете порядок вычислений (энергичный, ленивый) со способом построения алгоритмов (чисто функциональный, императивный).
-
@zamotivator, Нет не путаю. Вы замучаетесь писать чисто функционально без ленивости по умолчанию. Закончится это или отказом от чистоты или аннотацией большинства тривиальных ПМ как ленивых. Потому, что ленивые аннотации, в отличие от строгих, распространить автоматически невозможно.
-
@klapaucius,
Вы замучаетесь писать чисто функционально без ленивости по умолчанию.
Это ещё почему? Я чисто функционально на С++ пишу и не ослеп -
@zamotivator, может потому, что там это 1% фунций и нет необходимости в ПМ и автоматическом распространении ленивости?
-
@dr-Chaos,
и нет необходимости в ПМ
В чём?
и автоматическом распространении ленивости?
А зачем она мне нужна? -
@zamotivator, Вы бы попробовали что-то писать на чистых ФЯ, а то у вас о чисто-функциональном, похоже, очень нетрадиционное представление.
-
@klapaucius, писал на Ocaml и Scala. Без mutable и var. Не, не засчитывается?
-
@zamotivator, Во-первых, mutable и var не единственные способы нарушать чистоту в этих языках. Во-вторых, писать на окамле и скале в чисто функциональном стиле невозможно, никто этого и не делает. Т.е. как я и говорил, представление о таком стиле у вас сильно нетрадиционное.
-
@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, Нормально понимаю. Это и есть функциональное программирование. Разумеется, разные ФЯ имеют разную степень поддержки ФП. И в строгих ФЯ эта поддержка хуже, чем в ленивых. Почему — я написал.
-
@zamotivator,
ФП ничего не говорит про комбинаторы
Да ну? А что оно говорит тогда? Потому что это не какая-то деталь реализации как в соседних примерах — это сама суть ФП и есть. И если выкинуть из ФП комбинирование комбинаторов — там вообще ничего не останется. -
@klapaucius,
Да ну? А что оно говорит тогда?
О свойствах функций.
Потому что это не какая-то деталь реализации как в соседних примерах — это сама суть ФП и есть.
Дааа? И числа вы тоже в виде нумералов Чёрча представляете? -
@zamotivator, В этой ветке мы обсуждаем ваше утверждение о том, что ваш код на окамле и скале якобы чисто функциональный. ПРо порядок вычисления мы говорим в другой ветке.
-
@zamotivator, приведу тебе пример простого комбинатора 2х функций (.) . Это совсем не vtable или аллокаторы. Если слово комбинатор тебе непонятно, можно просто использовать ФВП.
-
@zamotivator, Обычно нет. И что? Числа и в ООП обычно не являются нормальными объектами. Что из этого вашего утверждения следует? Ну да, если из ФП выкинуть комбинаторы — останутся машинные числа, которые останутся и если из ООП объекты выкинуть.
-
@max630, Ну, итераторы — это тот еще костыль, хотя и повсеместно используемый для того, чтоб худо-бедно некоторые функции состыковывать. Ниша для них есть, но именно их костыльность и убогость в данном случае только подтверждает мою правоту. так что вместо тройного "нет" должно быть тройное "да!".
-
@klapaucius, это конкретное возражение было про то что числа не объекты
-
@max630, А, понял, это по поводу объектов. Не понял, из-за того, что древовидное представление "сплющивается" на таких уровнях.
Ну, я же сказал "обычно". А не "всегда". -
@max630, Да я сам понял уже. Кстати, объект — это не просто "что-то у чего вызываем метод через точку". У объекта должно быть идентити. А у чисел его нет. Потому, что 3 == 3, а будь эти тройки объектами — они бы были не равны. поэтому числа нормальными объектами обычно и не являются.
-
@klapaucius, А почему когда 3 является объектом, 3 != 3?
Что-то я вообще связи не улавливаю. -
@tzirechnoy, Если эти тройки объекты, то тут конструируется два объекта, с чего бы им быть равными? У них разное идентити — они по разным адресам располагаются, например. А в структурном сравнении нет ничего объектного. Аналогично и с состоянием — тройки иммутабельны, сделать одну из них четверкой, а другую десяткой, например, мы не можем. Ну а без идентити и состояния — что вообще остается от объекта?
-
@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 в хаскеле — это же не объект, но он мутабельный. А идентити — это как раз свойство мутабельного состояния, означает если меняешь одно — будет меняться и другое. А если не мутабельности, то какой смысл вообще говорить идентично оно или нет?
-
@klapaucius, А по-моему, это как раз Вы не понимаете что такое идэнтити.
-
@max630, IORef ведет себя как раз как иммутабельный — как обычная стейт-монада, то что там есть что-то мутабельное за кадром — деталь реализации, без unsafe лазеек эту мутабельность пронаблюдать нельзя. А вот рефы в ML-ях да, практически объекты. Собственно, после изобретения рефов и "префиксинга" ООП и появился.
Идентити — не обязательно связана с мутабельностью. Она, конечно, означает, что мутабельный объект остается самим собой, даже если поменять все значения в его полях, но она так же означает, что два разных объекта с одинаковыми значениями в полях не являются идентичными, а каждый опять таки остается самим собой. Это и иммутабельных объектов касается. -
@klapaucius, эта "само-собость" ненаблюдаема. И не абсолютна, даже сраный C++ может копировать или переиспользовать константное значение на своё усмотрение при оптимизации. А то что можно увидеть с точки зрения поведения — именно синхронность изменений.
-
@max630, Не согласен, в ООП она как раз как правило наблюдаема. Исключения, разумеется, бывают ("объекты" с value-семантикой). Но в нормальном ООП она должна быть наблюдаема в большинстве случаев.