Вышел 2-й выпуск журнала «Практика функционального программирования»

> В чем профит не объясняют

Едрить. Тут половина сообщений этому посвящено.

Ещё раз:

Чистая функция хороша тем, что глядя на код или вызов функции ты железно можешь быть уверен в том, что происходит. Бо ни этой функции никто данные не запортит, ни она никому не насрёт за шиворот. Таким образом, чтобы понять поведение ф-ии достаточно поглядеть на её код, а не на все over 9000 строк кода программа, где функция или данные могут быть использованы.

Функции высших порядков удобны тем, что многие вещи могут быть с помощью функций, специализирующих поведение функций. map lambda list удобнее исползовать, чем циклы городить.

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

Сопоставление с образцом --- это просто удобно

> Пример того, как чистая функция будет работать с БД

Если речь идёт о хаскеле, то мы используем монады и говорим: "чики-пуки, я в домике". Это тривиальный случай.

мой основной механизм сейчас --- R. там монад нет. поэтому я обхожусь инженерным методом: получение данных (правда из файла, а не БД) локализовано в строго одном месте. Да, формально, отныне моя программа стала некошерной. Главное, что потенциальный источник проблем известен и ограничен, а вся остальная программа --- чистая.

>ЗЫ. Я знаю в чем тут ошибка.

Угу. Ты наверное думаешь что в

let e = Egg Raw in [cook(e); cook(e); cook(e)]

e - это _одно и тоже_ яйцо? Может и x=2 нужно передавать клонируя число - а то как же это ты одно и тоже число передал в 2 формулы - этож ужос - числа размножаются...

Добрались до практики, и сразу стало всё хорошо видно. Сравните выразительность:

class Egg(object):
    def __init__(self):
        self._states = ['raw', 'broken', 'fried', None]

    @property
    def state(self):
        return self._states[0]

    @state.setter
    def state(self, value):
        if value and value == self._states[1]:
            self._states.pop(0)
        else:
            raise AttributeError ("wrong state")

    def break_eggs(self): self.state = 'broken'

data EggState = Raw | Broken | Fryed deriving (Show)
data Eggs = Eggs EggState Int deriving (Show)

break (Eggs Raw x) = Eggs Broken x
break e@(Eggs Broken x) = e -- yahh, already broken
break _ = error "you mean 'again'?"
fry (Eggs Broken x) p@(Pan Hot Oiled) = (Eggs Fryed x, p)
fry _ (Pan Hot Oiled) = error "what are you gonna do with these eggs?"
fry _ _ = error "on _that_ pan?"

И по питоньему коду не видно, что жарить надо на горячей сковородке.

Ну и замечение по реализации: а если будут ещё и варёные яйца?

>Потому что мутабельность - это свойство объектов RW

Я беру в руки кусок колбасы - что это?

>Ну или если ты не считаешь, что объекты RW мутабельны - тоже скажи.

Я беру в руки скорлупу от яйца - что это за объект?

Объекты RW такие какими на данный момент времени удобно рассматривать их - человек на лету делает теоретическую модель. Я приготовил рагу - что это? Это картофель и морковка в стейте бойлед? Или рагу? Я кладу его на тарелку - что это? OMГ - рагу размножается - часть в кастрюле часть в тарелке.

Обосную почему ты хочешь видеть в яйце состояние? Почему в яйце а не в наборе органики?

+ иного. И его туда двигают просто повсеместно сейчас.

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

А как же общение с внешним миром, который может насрать за шиворот твоей функции?

> Функции высших порядков удобны тем, что многие вещи могут быть с помощью функций, специализирующих поведение функций. map lambda list удобнее исползовать, чем циклы городить.

Я не спрашиваю в чем профит HOF, замыканий, лямбд и т.д. Я спрашиваю в чем профит иммутабельности и чистоты. То есть того, что присуще конкретно ФП, а не программированию вообще.

> Сопоставление с образцом --- это просто удобно

И это тоже не ФП-специфичная вещь.

> мой основной механизм сейчас --- R. там монад нет. поэтому я обхожусь инженерным методом: получение данных (правда из файла, а не БД) локализовано в строго одном месте. Да, формально, отныне моя программа стала некошерной. Главное, что потенциальный источник проблем известен и ограничен, а вся остальная программа --- чистая.

То есть ты уже не можешь выразить программу, которая делает что-то _полезное_ в терминах __чистых__ функций?

Что мне мешает императивно все потенциально опасные участки локализовать, как это сделал ты? Моя программа сразу же станет чистой и непорочной Ъ-ФП?

>Но в программе они остаются доступны ровно так же - подозреваю источник багов.

Почему ты не подозреваешь источник багов в
x=2
y = f(x)?

ОМГ x=2 осталось!

> Мы говорим не о "функциональных" и "императивных" языках - это в конце концов обобщения по наличию некоторых свойств которые принято относить к той или иной сфере - а о подходах. Окамл принято считать функциональны = но не что не мешает мне там налабать императивную программу. С принято считать императивным - хотя ничто не мешает там налабать функциональную. Это ничего не дает - не надо сводить все к python vs haskell.

Золотые слова.

>Каких - о том, что нельзя произвольно менять код функции и она бы при этом оставалась рабочей?

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

>За то, что поднакопил денег, сходил в оружейный магазин, купил пистолет и выстрелил в голову?

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

>ведь тебя ничего не удержит от самоубийства? :)

Конечно - это ж признак самоубийства - вызывать легальный метод библиотеки с реальными параметрами, а то что при этом библиотечный оъект ломается - это ж вина программиста который этим пользуется, да.
Может и оверфловы в функциях glibc не надо править? Все ж очевидно - надо просто правильно пользоваться этими функциями.

>Кстати, что там с unfry, или "так нельзя" менять функции? :)

Написал ты свою функцию вне библиотеки. Покажи мне как что-то сломалось.

>Разницу между объектом в смысле оо программирования и числом в математике улавливаешь?

Я пока так и не уловил что даем мне яйцо в "стиле ОО". Как на счет ответить на этот вопрос?

>Кстати, какое состояние у числа 42, кстати, что вообще такое состояние числа? :)

Его значение. Мало? Могу дофига придумать - история его изменени и всяка ятакая фигня. Сначала у меня было X денег. Потом стало Y. Я купил на это товары A,B,C по такой-то стоимости и подал ничему. Что - сложно представить как это все инкамсулируется в 1 объект?

В чем разница? Раскрой тему что я выиграю от представления яйца объектом.

>Входные данные одинаковые -- поисковый запрос.

и база данных.

> >Входные данные одинаковые -- поисковый запрос.

> и база данных.

Это внешний мир. Соединения с ней может не быть, например.

>Таким образом, чтобы понять поведение ф-ии достаточно поглядеть на её код,

однажды в ru.programming.languages был тред уже не помню о чем конкретно - но примечательным фактом является в каких терминах он шел. В шел он в терминах вида:

"Есть функции Int->Bool->Int и [Int] -> (Int -> Bool) -> [Int]...."

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


>Да, формально, отныне моя программа стала некошерной. Главное, что потенциальный источник проблем известен и ограничен, а вся остальная программа --- чистая.

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

kkw

ugoday

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

А как же общение с внешним миром, который может насрать за шиворот твоей функции?

getCalibrationData <- function(zwickFile,calibrationFile,W,a0,spmethod){# строит зависимость силы от раскрытия трещины по известным данным раскрытие трещины от времени и времени от перемещения траверсы         
  # Читаем файл с сырыми цвиковскими данными                                                                                                                                                                      
  zwick <- getZwickData(zwickFile)
  # читаем файл с градуировкой                                                                                                                                                                                    
  clbr <- read.table(calibrationFile, head=TRUE)
  clbr$xmm <- toM(clbr$xkl*2) # переходим от клеточек к мм хода траверсы                                                                                                                                          
  # вычетаем начальное значение показаний датчика раскрытия трещины и домножаем на безразмерный масштабирующий коэффициент                                                                                        
  clbr$cymm <- 0.008 * (clbr$ymm - clbr$ymm[1])
  Kv <-  1 + (0.25*W)/(a0 + 0.1*(W-a0))  # Kv --- коэфициент пересчёта с точки подключения датчика на линию действия силы                                                                                         
  #добавляем вычисленное значения раскрытия трещины                                                                                                                                                               
  zwick$opening <- splinefun(clbr$xmm, clbr$cymm, method=spmethod)(zwick$strain)/Kv
  data.frame(x=zwick$opening,y=zwick$force)
}

calcArea <- function(x,y){# Считает площадь под кривой сила-путь.                                                                                                                                                 
  calcAreaN <- function(x,y,n,a)
    if(n == 1) a  else calcAreaN(x,y,n - 1, a + (x[n] - x[n-1])*mean(c(y[n],y[n-1])))
  # обходим матрицу с конца, начальное значение площади = 0                                                                                                                                                       
  calcAreaN(x,y,length(x),0)
}

curve <- getCalibrationData("RawZwickData","calibration",g$W,g$a0,"monoH.FC") # набор данных трещина-сила

A <- calcArea(curve$x,curve$y) #работа разрушения

Тут мы видим две функции

• getCalibrationData --- общается с внешним миром
• calcArea --- чистая

так вот формально они обе нечистые, так как поведение calcArea завиит от файлов лежащих в страшном внешнем мире. И лажа в файлах мнгновенно делает расчёты некорректными. Файлы представляют собой результат эксперимента, всего их три: один генерирует машина, остальные создаются руками. В «ручных» файлах я иногда лажаю.

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

kkw

Я спрашиваю в чем профит иммутабельности и чистоты

По-моему, это тут уже раз десять написали. Пишу одиннацдатый: если объект обладает состоянием, и может его менять произвольным образом, то этот объект может ВНЕЗАПНО! оказаться не в том состоянии, о котором думает читающий код программист. И программа начинает вести себя не так, как он ожидает. *) Это усложняет жизнь.

kkw

И это тоже не ФП-специфичная вещь.

Только в фп это как правило лучше всего реализованно.

kkw

То есть ты уже не можешь выразить программу, которая делает что-то _полезное_ в терминах __чистых__ функций?

Я могу сделать свои программы лучше, думая в функциональном стиле. Разве этого мало?

kkw

Что мне мешает императивно все потенциально опасные участки локализовать, как это сделал ты?

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

kkw

Моя программа сразу же станет чистой и непорочной Ъ-ФП?

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

____________________________________________________________________________

А бывает, что некорректное поведение программы возникает из-за редкого сочетания состояния мутабельных объектов. которое хрен воспроизведёшь, а потому фиг догадаешься отчего прога лажает.

>А как же общение с внешним миром, который может насрать за шиворот твоей функции?

То есть если потенциально тебе надо иметь дело с навозом, что всем очевидно неприятно - надо не иметь ничего против и разнести этот навоз просто по всему дому? Или в чем твой аргумент?

>Я спрашиваю в чем профит иммутабельности и чистоты.

Это _удобное_ представление, код содержит _меньше_ багов, даже потенциально, такой код _легче_ отладить, _легче_ тестировать, _легче_ разрабатывать.

>Что мне мешает императивно все потенциально опасные участки локализовать, как это сделал ты?

Ты понимаешь парадокс своего вопроса? Ты защищаешь императивность но тут же говоришь о том что эти участки опасны и их надо локализовать? То есть ты утверждаешь что императивщина - опасна! Как-то противоречивенько в смысле защиты императивщины. Ты наоборот должен доказывать что ничего опасного там нет, что мутабельность состояния это хорошо и правильно, и что все лезут в общую память это просто класс - широкие возможности и все такое прочее. А ты как-то уж очень пытаешься засунуть сам подальше то что сам же и "защищаешь"?

>Это внешний мир.

Мир я передавать не умею. Я умею передавать дескриптор.

>Соединения с ней может не быть, например.

Значит функция вернет Эпик файл. Монада Maybe. Результат типа Option, любая другая модель вычисления которое может окончится ошибкой. Где проблема?

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

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

Поправлюсь. Не перестает быть чистой - а перестает быть детерминированной. И дальше по тексту.

> Вопрос весьма корректен -какую выгоду ты рассчитываешь получить из состояния лампочки? Что стоит за решением сделать ее объектом с состоянием, а не ADT?

Я задал вопрос. Мне нужен был ответ, а не ворох вопросов. Можешь не трудиться отвечать - анонимный брат уже ответил.

> Ты понимаешь парадокс своего вопроса? Ты защищаешь императивность но тут же говоришь о том что эти участки опасны и их надо локализовать? То есть ты утверждаешь что императивщина - опасна! Как-то противоречивенько в смысле защиты императивщины.

Самое любопытное, что это именно инженерная практика выработала такое негативное отношение к императивным приемам, а не теоретические рассуждения о корректности. Распространение ООП ведь не случайно произошло, а в результате осознанного желания хотя бы локализовать побочные эффекты. Иначе совсем печально. Где то пошли еще дальше к контрактному программированию. Но это усложнение, в то время как ФП дает реальное упрощение. То, что сейчас много внимания уделяется ФП я бы не назвал хайпом. Просто людям действительно очень нужны корректные программы и простые методы их написания, а принятые в индустрии инструменты плохо для этого подходят.

> Код на Хаскелле читается, как рассказ.

Бугага. Кто там говорил об обучении? %)

P.S. подозреваю, что на Ocaml то же самое действительно читалось бы, как рассказа ;)

> Ты защищаешь императивность но тут же говоришь о том что эти участки опасны и их надо локализовать? То есть ты утверждаешь что императивщина - опасна!

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

Во-вторых, я не защищаю императивность. Как вообще можно защищать парадигму? Я просто проясняю для себя как вы обходите те или иные вопросы, которые кажутся мне не совсем вписывающимися в _моё_ представление о ФП. Я далеко не гуру-ФП, поэтому имею право на неверные мысли о нём.

> Ты наоборот должен доказывать что ничего опасного там нет

Я никому ничего не должен.

> мутабельность состояния это хорошо и правильно, и что все лезут в общую память это просто класс - широкие возможности и все такое прочее.

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

> Я задал вопрос.

Это был плохой, негодный вопрос. Нельзя правильно ответить на неправильный вопрос, не поднявшись при этом над ситуацией.

Ну если ты хочешь разбирать:

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

Зачем их локализовывать и почему они опасны?

>Я хочу понять в чем профит для народного хозяйства. Со стороны пока всё выглядит как сферический спор природе вещей в вакууме.

Двадцать раз упоминали. Что легче протестировать функцию которая на определенный набор параметров возвращает определенный набор результатов, или которая на состояние чего-то где-то меняет что-то где-то? Тот же вопрос о наборе функций - что легче протестировать - отображения из X в Y, или набор функций которые меняют что-то в общей памяти в зависимости от состояния этой общей памяти?

Ответ по моему очевиден.

> на уровне IO нет никакой типизации, и сама os построена вокруг стейта. Но вся суть в том что _абсолютно все_ понимают что это _страшно_

Еще раз бугага %) _Все_ понимают, что это неизбежно. А "страшно" - это просто маркетинг ФП ;)

> Это был плохой, негодный вопрос. Нельзя правильно ответить на неправильный вопрос, не поднявшись при этом над ситуацией.

Можешь просто не опускаться до ответа.

>Еще раз бугага %) _Все_ понимают, что это неизбежно

Неизбежность - это страшно. Бугага.

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

Помнишь интерфейс старого отладчика по асму - шаги, окно состояния регистров, дамп памяти? Почему в командной строке нет такого интерфейса?

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

> Помнишь интерфейс старого отладчика по асму - шаги, окно состояния регистров, дамп памяти? Почему в командной строке нет такого интерфейса?

Опять метафоры, да что ж такое...

> А вские злобные гики поизобретали консольные утилиты с абстракциями аргументов и результатов - это ж функциональная жуть.

Если это и вопрос, то чисто риторический, да? %)

> Можешь просто не опускаться до ответа.

Могу, но бросить тебя наедине с твоим заблуждениями будет не по товарищески.

> Опять метафоры, да что ж такое...

Хитрый план, призванный развить в тебе любовь к абстракциям. А к ФП ты сам тогда придёшь.

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

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

> А к ФП ты сам тогда придёшь.

Давно уже. Вопросы - от отсуствия практики (просто не на чем практиковаться).

>Опять метафоры, да что ж такое...

Почему метафоры? "Я чисто конкретно..."

>Если это и вопрос, то чисто риторический, да? %)

Ну вообще-то я рассчитывал что ты упомянешь интерфейс типа mc, который собственно и инкарнирует мою неметафорическую метафору и реализован посредством стейта - панель, выбрали файлы, выбрали императив - копи, сказали doit. проверили результаты на панели:)

Тогда бы я в качестве конрпримера сказал: и тут же изобрели функциональные оптимизации оного в виде функций от аргументов: командная строка и инструкции вида cd .., поиск по ctrl+s, выбор по маске.

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

После чего я бы ударился в примеры, когда оператор чего-нить сидя за императивным интерфейсом занимался работой вида "сижу жду диалога, диалог отображается я кликаю мышей на кнопку", а оператор функционального интерфейса написал бы набор правил вида "on A do B, on C do D" и ушел пить пиво таким образом автоматизировав свою работу. Этим примером я ненавязчиво вытяну из глубин старых разборок пример который обсасывал еще vsl, о том что всякие там техники и прочие обычные микробиологи, должны бы таскать с собой портативные компьютеры с помощью которых на прологоподобном языке они оптимизируют свою работу - то есь аргумент в защиту того что все должны уметь программировать с детства - при чем именно на прологопдобном языке - так как это многим может помочь, и каким собственно образом должны создавать интерфесы. Это еще породит минимум 3 страницы обсуждения в условиях остутствия эпического флейма или хрен знает сколько в условиях его присутствия.

Напоследок я проведу параллель с соседним тредом где мы ругаемся по поводу ридеров с кнопками и ридеров на нетрониксе с джойстиком, высказавшись на тему примера императивного интерфеса вида "вижу и реагирую" с курсором и его движением, и интерфейса вида "знаю и делаю" с кнопками (где юзер сам вводит аргументы над которыми производит функции) а не просто видит курсор и знает куда его перемещать.

Кто-то заметит что оба эти интерфейса частично сводимы один к другому что разовьет еще одну ветку треда на тему скорости и удобства vs минимализм кнопок.

Где то - так:) Это я обдумал пока заряжал рыбу в духовку в надежде получить рыбу с ананасами как функцию от рыбы и ананасов:)

> но лучше бы ты выражал ее в понятных ответах.

Отвечаю (надеюсь понятно): на функциональных языках надо писать в функциональном стиле. Пытаться на хаскелле написать программу на паскале не следует. Тогда и вопросов таких не будет.

> Ну вообще-то я рассчитывал что ты упомянешь интерфейс типа mc

Блин, ну сплошное же бугага. А я рассчитывал сказать, что объединение программ через потоки данных - самое простое решение для методологии "software tools", с дополнительным бонусом в виде упрощения ядра. И что "злобные гики" в гробу видели функциональщину, если судить по Си и шеллу.

> Напоследок я проведу параллель с соседним тредом где мы ругаемся по поводу ридеров с кнопками и ридеров на нетрониксе с джойстиком

> Это я обдумал пока заряжал рыбу в духовку в надежде получить рыбу с ананасами как функцию от рыбы и ананасов:)

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

А вот на бейсике в хаскелле очень даже можно ;)

>И что "злобные гики" в гробу видели функциональщину, если судить по Си и шеллу.

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

Например в своих злобных жабских коллекциях я столкнулся с проблемой в том что одинаковые алгоритмы для разных типов коллекций в качестве результатов должны возвращать те же самые типы - и как следствие должны внутри инстанциировать объекты того же класса - то есть если фильруем LinkedList - в результате должен быть отфильрованный LinkedList, и соответствено для ArrayList, что привело меня к пониманию необходимого инстанс метода фреймворка колекций который будет билдить пустой экземпляр себя, А гдето через 2 недели Одерский выпустил спецификацию новых колллекци для скалы 2.8 где реализовывался тот же самый подход базируясь на той же самой проблеме:)

>Походу, кроме ананасов там были еще какие-то продукты растительного происхождения.

Это вчера.

> императивный интерфейс - это подход вида "вижу и реагирую", а функциональный интерфес - это подход вида "знаю и делаю".

Инстинкты vs разум? Что то в этом есть :)

А я рассчитывал сказать, что объединение программ через потоки данных - самое простое решение для методологии «software tools», с дополнительным бонусом в виде упрощения ядра. И что «злобные гики» в гробу видели функциональщину, если судить по Си и шеллу.

Не совсем так. Концепция утилит и фильтров весьма в духе функциональщины.

Incidentally, a UNIX filter is expected to sequentially consume its input and produce a single output stream. Therefore, from the point of view of the shell and filters, the input and the output streams are 'linear', singularly referenced objects. No wonder i/o involving linear streams is monadic.

Doug McIlroy, the inventor of pipes, is said to point out that both pipes and lazy lists behave exactly like coroutines.

http://okmij.org/ftp/Computation/monadic-shell.html

> Концепция утилит и фильтров весьма в духе функциональщины.

Ага. Но лично я думаю, что это получилось случайно.

>Ага. Но лично я думаю, что это получилось случайно.

...либо основано на одинаковых предпосылках:)

[code] Prelude> let 3 - 4 = 5 Prelude> 3 - 4 5 [/code]

Ааа, вот мы и отстрелили себе ногу :)

>> Ага. Но лично я думаю, что это получилось случайно.

> ...либо основано на одинаковых предпосылках:)

Ага, и эта предпосылка - банальная водопроводная труба.

>Ага, и эта предпосылка - банальная водопроводная труба.

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

Не. Увидеть, поговорить с вами развиртуализированным. mkurt(dog)ua.fm

> Я нигде и не утверждаю, что мутабельность это хорошо. Я не утверждаю, что это плохо. Я хочу понять в чем профит для народного хозяйства.

Даже для императивного языка типа жабы:

1. Намного проще анализировать корректность работы программ.

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

2. Намного проще читать код.

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

3. Thread-safety без дедлоков и потерь производительности.

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

Это всё именно практика, т.е. то, что мне помогает на работе каждый день.

>Даже для императивного языка типа жабы:

Жабский енум - зачаточная фаза такого adt.

Что всем в шестером приходить? :) написал.

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

Для тех, кому интересен сабж:

Выходит новая книга "Практика работы на языке Haskell". http://users.livejournal.com/_darkus_/474283.html

Я в сомнениях, так ли она нужна. С одной строны приятно иметь нужную инфу под рукой на родном языке, а с другой --- это всё есть в сети и технический английский не такой уж сложный.