языки с самым лаконичным синтаксисом

[Utkin]

Смысл от этого не изменится.

Этот пример был не о Делфи, а о Хаскеле. Рад что Вы заметили.

Вы явно меняете объект Form1, вместо того чтобы создать новый с измененным заголовком и вернуть его.

Это и есть пересоздание объекта вместо явной модификации. Там же монада, так что тут все чисто . И потом я не создавал Form1 и не знаю как он там работает. Но если хотите, я могу впихнуть еще одну обертку и также назвать это монадой. А потом сказать что все хорошо

Функции в Хаскеле не могут менять внешний мир

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

Функции в Хаскеле не могут менять внешний мир, но это могут делать функции лежащие за его пределами, функции OS например.

О-о-о, так и я на ассемблере не пишу функцию записи в файл, я также вызываю обертку над API оси. Значит делфи также чист? Я ведь практически никак не работаю с внешней средой - все есть обертки, типа VCL . C# так он вообще все на библиотеках делает. Так можно вообще наумничать - я вообще никак ничего не меняю - это все среда исполнения делает, я здесь не причем. И переменные фактически не создаются (я же вот ассемблером не записываю данные), там все через монады. Да, да именно через монады. А почему, да потому что там есть проверка на диапазон значений, проверка типов и много чего еще. Так что сама программа чистая - это среда исполнения, а она внешний мир по отношению к программе . Так что плен Ваших иллюзий весьма зыбок.

[Kostia]

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

Где ее писать приходится? o_O
Уже все написано!

Вам было бы удобно, если у Вас на работе считалось бы, что 2*2= 5, а 5+3=7, но 4+4=10?

Вы явно не в теме. Для получения интуитивного опыта рекомендую попробовать написать пару программ на Haskell или Erlang.
При отсутствии зависимости по данным
[f(x1), f(x2), f(x3)] - элементы списка можно вычислить в любом порядке или параллельно.
При ленивости
length [1, x*x, 1/0, ln 0, product [1..]] - вернет 5, не вычисляя того что внутри списка, зачем, если требуется только узнать размер?
Алгоритмы обычно записываются в виде однозначной последовательности действий, но это является излишним, т.к. последовательно легко достигается за счет зависимости по данным, и независимые по данным части алгоритма можно вычислять в любом порядке или параллельно. Например при вычислении корней квадратного уравнения не имеет значения какой корень посчитать первым, т.к. для вычисления одного не требуется знания другого.

А когда для ее оправдания создают целую теорию - это диагноз.

По мне так пускай будет существовать строгая математическая теория, чем отсутствие таковой. Советую немного ознакомиться с теорией вычислительных процессов. И ответить на следующие вопросы:
1. Что такое стандартная схема программы и как сравнивать между собой эти схемы
2. Чем конечные автоматы лучше машины Тьюринга
3. Чем сети Петри лучше конечных автоматов.
4. Почему ООП нельзя считать равноправным расширением структурного программированиям
...

И потом я не создавал Form1 и не знаю как он там работает.

Тогда из какой Ж*** вылез Form1 да еще и с полем caption? Я вашего примера не понимаю на корню.

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

При чем тут пенсионерки? Вы еще квантовую физику сюда прилепите. Я например могу утверждать, что это было предрешено судьбой, в виду детерминированности всех процессов во вселенной и никто не виноват, но наказать надо =)

О-о-о, так и я на ассемблере не пишу функцию записи в файл, я также вызываю обертку над API оси.

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

[Kostia]

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

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

[Utkin]

Тогда из какой Ж*** вылез Form1 да еще и с полем caption?

Потому что пример был немного о другом . Читайте там внимательно.

При чем тут пенсионерки?

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

Вы всё также называете что-то монадой и не понимаете что это такое, тогда только практика и личный опыт.

Это суть обертка. А еще отмазка, с целью сказать, что если операцию ввода-вывода обернуть в монаду, то операция станет чистой.

кал = Вы(еда)

Сначала не понял и хотел даже оскорбиться . Это все проклятое императивное мышление и делфи . Привык к кал := Вы(еда)

[Kostia]

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

Чистая значит при одних и тех же аргументах вернет одно и тоже значение, а также без побочных эффектов.
c1 = getChar(); // тут программа попросит вас ввести символ
c2 = getChar(); // тут уже нет

c1 = getChar(1); // тут программа попросит вас ввести символ
c2 = getChar(2); // тут тоже
c3 = getChar(1); // тут нет =)

Собственно для решения этой проблемы можно придумать что-то типа переменной Мир.
[c1, Мир2] = getChar(Мир1);
[c2, Мир3] = getChar(Мир2);
[c3, Мир4] = getChar(Мир3);
[c4, Мир5] = getChar(Мир3); //тут спрашивать не будет, с3 == с4
С какого угла на это не смотреть, получим что мир меняется, сам или под действие функции, значения не имеет, оно нам только говорит о том, что мир после ввода/вывода уже не такой как "вчера", а значит ф. getChar может возвращать любые значения, ведь вызывается она всегда с разными аргументами. Автоматизировать этот процесс можно самыми разными способами, но в Хаскеле для этого решили использовать монады. Единственный грязный момент тут это инициализация IO, тут нужно принять как данность что Мир, при каждом запуске программы разный, поэтому getChar может возвращать разные значения даже если стартануть программу в одних и тех же условиях. Поэтому даже функции ввода/вывода можно считать чистыми, т.к. они вызываются всегда с разными аргументами ) и меняю Мир(создают новый из старого =)).
То самое значение мира берется от main. Отсюда и очевидно разделение, если взять Мир неоткуда, то и использовать IO функции нельзя, это можно назвать естественным разделением чистого кода от грязного. Одна IO функция может вызвать другую IO функцию или чистую функцию, но читая не может вызвать IO функцию, т.к. в ней нет Мира )
Некоторые языки позволяют помечать чистые функции ключевым слово pure, тогда на нее накладываются все присущие таким функциям ограничения и проверяются в момент компиляции. Но в отношении к Хаскелю, там все функции являются такими.

Потому что пример был немного о другом . Читайте там внимательно.

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

Сначала не понял и хотел даже оскорбиться . Это все проклятое императивное мышление и делфи . Привык к кал := Вы(еда)

Уж извините, проблема обозначений )

[MihalNik]

Из Викибука:

Каждое действие ввода-вывода возвращает какое-то значение. Для того, чтобы различать эти значения от базовых, типы этих значений как бы обёрнуты типом IO (необходимо помнить, что монада является контейнерным типом).

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

Получается так, что в Haskell заново изобретено императивное программирование… Монада IO встраивает в Haskell маленький императивный подъязык, при помощи которого можно осуществлять операции ввода-вывода. И написание программ на этом подъязыке выглядит обычно с точки зрения императивных языков. Но есть существенное различие: в Haskell нет специального синтаксиса для ввода в программный код императивных функций, всё осуществляется на уровне функциональной парадигмы. В то же время опытные программисты могут минимизировать императивный код, используя монаду IO только на верхних уровнях своих программ, так как в Haskell императивный и функциональный миры чётко разделены между собой. В отличие от Haskell, в императивных языках, в которых есть функциональные подъязыки, нет чёткого разделения между обозначенными мирами.

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

Как было бы тру в контексте названия данной темы:
Абсолютно идентичный синтаксис и типы данных, никаких монад и return, компиль точно определяет какие функции - грязные и за грязную игру кроет программиста грязным матом.
А вообще хватило бы и оттенка цвета шрифта в ИДЕ. Но я осознаю, что от такой системы кодирования не минует батхёрт

[Kostia]

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

Нет не нужно, для этого есть система автоматического вывода типов.

main :: IO () --можно опустить
main = do
        args <- getArgs
        mapM_ putStrLn args
        return () --тоже можно опустить, если последняя функция возвращает IO ()

Получим:

main = do
        args <- getArgs
        mapM_ putStrLn args

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

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

Можно определить оператор для задания дробей, хотя он уже определен(Data.Ratio):
1 + 5 % 222 = 227 % 222
1%3 + 5%14 = 29 % 42

Автоматический вывод функций, например если определить дерево:
data BinTree a = Empty | Node a (BinTree a) (BinTree a) deriving (Show)
Задать его:
tree = Node 0 (Node 1 Empty Empty) (Node 2 Empty Empty)
и вывести, то получим:
Node 0 (Node 1 Empty Empty) (Node 2 Empty Empty)
Не красиво, то можно и свою show определить ), так выводить можно многие функции.
Например если к определению добавить требование Eq, будет выведена функция сравнения деревьев:

data BinTree a = Empty | Node a (BinTree a) (BinTree a) deriving (Show, Eq)

tree1 = Node 0 (Node 1 Empty Empty) (Node 2 Empty Empty)
tree2 = Node 0 (Node 1 Empty Empty) (Node 3 Empty Empty)

tree1 == tree2 -> False
tree2 == tree2 -> True

В комплекте ко всему идет хороший менеджер пакетов cabal, который и загрузит расширение, и компильнет его под вашу систему, и установит )

Много интересного написано в "Жемчужины проектирования алгоритмов. Функциональный подход."

[MihalNik]

Сообщение от Kostia

Нет не нужно, для этого есть система автоматического вывода типов.

То есть монады просто лишняя каша

Применение монад в функциональных языках — это по существу возвращение к императивности. Ведь операции связывания (>>=) и (>>) предполагают последовательное выполнение связанных выражений с передачей или без результатов вычисления. То есть монады — это императивное ядро внутри функциональных языков. С одной стороны, это идёт в разрез с теорией функционального програмирования, где отрицается понятие императивности, но, с другой стороны, некоторые задачи решаются только при помощи императивных принципов. И опять же, Haskell предоставляет удивительную возможность по генерации списков, но это только благодаря тому, что сам тип «список» выполнен в виде монады.

Нет, серьёзно, нельзя просто вставить "грязный" императивный код, надо обязательно из него приготавливать "кашу"?
Вот почему-то в Python'е необязательно

[Kostia]

Еще добавлю про автовывод Read

data BinTree a = Empty | Node a (BinTree a) (BinTree a) deriving (Show, Eq, Read)

tree = read "Node 0 (Node 1 Empty Empty) (Node 2 Empty Empty)"::BinTree(Int)

Работает! ^__^
Из строки получили дерево. Сериализация чтоб её )

При этом очень интересно получается, в ::BinTree(Int) Int можно было бы не указывать, если дальше работа с деревом производилась бы как с BinTree(Int).

Простой пример:

read "5.3" + 0.75
6.05

но

read "5.3"
Ошибка

read "5.3"::Float
5.3

То есть монады просто лишняя каша

Перефразирую: "То есть интерфейсы просто лишняя каша".

Вот почему-то в Python'е необязательно

А питон и нефункциональный язык

[the_deer_one]

Как в функциональных языках хранятся значения без изменяемых переменных? Например виндовый calc.exe где мы сначала вводим 2, калькулятор запоминает, затем +, калькулятор и это запоминает, потом 3, калькулятор всё это запоминает. А мы потом можем всё это дело сосчитать.

P.S. похоже на программисткое порно.