Здравствуйте, Sinclair, Вы писали:
S>>>Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты? V>>Как минимум глаза, получающие сообщения от рецепторов света. S>Вы уверены, что эта мысль выражена внутри сознания именно в терминах глаз, рецепторов, и сообщений?
Внутри эта мысль выражена несомненно в терминах "прикладных" сигналов, получаемых от рецепторов. Лично я на твою фразу представил себе:
1. небо
2. оно еще не потемнело, но уже скоро
3. представил потемневшее небо
S>Я говорю не про реализацию, а про абстракцию.
Ты говоришь про процесс и результат, это совсем не тоже самое, что абстракция и подробности. Да, я представил себе сразу результаты, то бишь предполагаемую серию сигналов рецепторов, соответствующие словесному описанию образа, не замувашись о том, как именно это сигналы генерируются механизмом глаз и трансформируются в моей голове. Точно так же как юзверь программы получает сразу готовую форму на экране... В твоеём примере я юзверь, мне ООП не нужен ес-но, но для механизма реализации этой формы — бы неплохо. Вот почему я тебе привел "механизм". Ты же сам когда-то писал, что ООП — это не про задачу, а про решение. АБСОЛЮТНО верно.
Здравствуйте, samius, Вы писали:
S>>Но архитекторы обычно люди более широко эрудированные, и они таки понадкусывали эти книги. И многие даже используют ФП языки, ибо инструмент в своей нише — мощный. В своей нише. По сути в этом то и точка соприкосновения. S>Ну вот а я считаю что там не точка соприкосновения, я считаю что ниши у подходов пересекаются в значительной мере. Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.
Это значит, что у ФП больше ограничений и границы проявляются очень четко.
Здравствуйте, DarkGray, Вы писали: DG>Это детали реализации.
Это устройство архитектуры. DG>Счет-то все равно объектом остается с соответствующими сообщениями:
Откуда это внезапно взялось? DG>- зарегистрировать еще одну операцию,
На всякий случай, напомню, что "регистрация операции" работает с двумя счетами. Кому из них мы посылаем сообщение? Первому попавшемуся? Кто обязан проверять соответствие операции бизнес-правилам? DG>- вывести текущее состояние по счету,
Я уже писал о том, что понятие "текущее состояние" в бухгалтерии не существует. Существует "состояние на дату". DG>- вывести историю операций и т.д.
DG>Например, когда заходишь в инет-банк, то со счетами работаешь как с объектами: выбираешь объект (счет, транзакцию) и посылаешь ему сообщение посредством нажатия соответствующей кнопки.
Очень странно. Лично я, когда захожу в инет-банк, никаких сообщений счетам я не посылаю. Сообщения я посылаю исключительно серверу, а сервер мне отвечает. DG>При этом не важно, как он реализован в js-е или на сервере: как идентификатор, как запись в базе, как еще что-то — для использования через gui инет-банка, счет удобнее воспринимать как объект. DG>Основная моя мысль, что счет одновременно является и идентификатором, и объектом (еще чаще нечетким объектом — когда набор методов и набор состояния такого объекта зависит от контекста использования)
А моя основная мысль, что счёт не ведёт себя как объект в ООП. Понятие "нечёткого объекта" для меня эквивалентно понятию "твёрдый газ".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> Есть много форм разных форм человеческого мышления. Основные — анализ, синтез, сравнение, абстракция, обобщение. Вы упомянули только одну из них.
Это не формы мышления, а высшие психические функциии.
Здравствуйте, Sinclair, Вы писали:
ВВ>>Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y". S>1. Тут нет ничего ОО-шного. Напомню, что ООП — это про посылку сообщений. То, что у нас операция сложения "внутри" реализована через отправку сообщений, вообще говоря лишняя подробность.
Не понял. А кто нам запрещает сообщения отсылать в инфиксной форме? Это все сводится к семантике конкретного языка. В Смолтоке, кстати, инфиксные сообщения были. А это, если не считать Симулы, самая заря ООП.
S>Если ещё поглубже копнуть, то окажется, что и объектов никаких нету, а происходит банальный лукап по символьной таблице, а потом косвенный вызов.
Ну да, а если еще глубже копнуть, то окажется, что там сплошной ассемблер.
S>2. Я вовсе не уверен в том, что операция __add__ реализована "объектным" образом, а не является всего лишь частью описания ADT.
Я не улавливаю разницы между "реализована объектным образом" и "является всего лишь частью описания ADT". Можно пояснить?
К слову, уверенным в чем-либо ты можешь быть лишь в рамках семантики конкретного языка, что логично. В Питоне ты вполне можешь быть в этом уверен.
S>Ну вот struct-типы в дотнете, строго говоря, объектами не являются (не будучи забоксенными).
А в Джава примитивы вообще ни в каком смысле объектами не являются, а боксинг делается ручками завертыванием int во вполне себе "объектный" Integer. Но о чем это говорит?
Примитивы нельзя представить как объекты? Ну, конечно же, можно, и другие языки это прекрасно показывают. Просто такое представление является неэффективным. Как, впрочем, и рантайм диспатч арифметических функций, вместо статического диспатча. Но эффективность — это отдельный вопрос.
S>3. Проблемы, к которым приводит такой подход, хорошо описаны у Lazy Crow Rhrr: http://rsdn.ru/forum/philosophy/4837534.1.aspx
Я этому товарищу отдельно отвечу, когда время будет.
По поводу математических операций могу прежде всего заметить, что необходимость неявных приведений, из-за которых как раз и начинаются все описанные проблемы, мне не кажется столь уж несомненной. На практике, кстати, получается, что как раз ООЯ зачастую поддерживают неявные приведения, а вот большинство ФЯ — нет. Причины, конечно, тут разные, и не обязательно релевантные данной теме, но никто же в ФЯ не умер от этого.
Ну и наконец в том же питоне "объектный подход" вполне себе сочетается с возможностью инты с флоатами складывать.
По поводу конкатенации ленивых списков я вообще не понял проблему. Если ленивые списки превратить в IEnumerable, то в рамках того же C# контактенация двух бесконечных последовательностей описывается без всяких проблем во вполне объектном ключе. Вот только эта конкатенация не будет in-place что-либо модифицировать, а просто вернет новый "список". Неужто иммутабельные структуры данных противоречат ООП?
Здравствуйте, vdimas, Вы писали:
V>Именно потому. Иерархии абстракций хорошо подходят человеческому мышлению — от общего к частному.
N+1 велосипед в этом топике про человеческое мышление.
V>Производственное удобство связано с удобством для производителя-человека. Как ни крути, но он так мыслит. Как бы некоторым не хотелось думать, что уж они-то мыслят не так. Чем мутнее образ в мозгу, тем он абстрактнее... только и всего.
А что значит "мутнее образ" ? Вот скажем дорогу на работу я представляю как три отрезка примерно одинаковой длины. Это вроде как чистой воды абстракция. И где здесь "мутность" ?
S>>Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку. V>Функциональные типы тоже до безобразия абстрактны и тоже позволяют инкапсулировать за своими сигнатурами всё, что угодно. Однако же... >а ФП — только функциональную, которая несильно отличается от процедурной.
Покажи на примере, как функциональная композиация несильно отличается от процедурной.
Здравствуйте, samius, Вы писали:
V>>Это не только я нахожу и не я это изобрел. Эта лишь одна из практик, которая дополняет современное многопоточное ООП. Ведь ООП не отменяет ни атомарности, ни транзакционности. А понятие валидности состояния в нем было изкаробки. S>Многопоточный ООП? Ты опять что-то намешал.
Ох блин... Зачем МНЕ что-то намешивать, если за нас это намешивает окружающая действительность, то бишь для нас программистов — поступающие задачи. На сегодня многопоточное ООП считай что дано сверху. А требование валидности состояния всегда было. Вот и происходит в ООП наработка новых практик, доселе неактуальных.
Помнишь я тебе говорил про быстрое устаревание любого догматического подхода что к ООП, что к ФП? По мне порядка 15 лет — таки быстро.
S>Ну и другими словами ты хочешь сказать что ООП без ФП не самодостаточен? Веский довод...
Что я хотел сказать, я уже сказал — методологии воруют полезные практики друг у друга. В этом смысле ФП точно так же не самодостаточен, т.к. тоже является комплексным набором практик. Забери любую из них и сделаешь ему хуже или вообще поломаешь.
V>>Монады в Хаскеле появились далеко не сразу, это факт. Класы типов — тоже. Иронизировать можешь до бесконечности, ес-но. S>нет, не могу. Уже надоедает.
Дык, тогда можно было бы по делу высказать/подумать, зачем в Хаскель появились монады?
V>>Глупости. Банальное понятие ссылочного типа ставит твой ФП раком, и никакая статика не помогает. См. Немерле. S>А что делает ссылочный тип в чистом ФП (это раз)?
А возражает на твою фразу:
Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.
S>Это банально справедливо для всей статики
Простых гарантий типобезопасности для работы ФП мало. Нужны еще ограничения на разновидности структур данных.
S>А если очень надо, то IO в руки, как и с MutVar в соседней ветке (два).
О чем и речь, что эти вещи появились в Хаскеле не сразу... Собственно как и все вещи, связанные с требованиями мутабельности в реальных программах. Я просто ХЗ зачем отрицать факт заимствования из императивного мира.
S>А что там с Немерле?
Дык, когда мы объявляем иммутабельную переменную ссылочного типа, как далеко, по-твоему, распространяется иммутабельность? Предполагаемые участники:
1. сама ссылочная переменная;
2. объект, на который cсылается п.1;
3. объекты, на которые ссылается п.2.
Здравствуйте, Ikemefula, Вы писали:
S>> Есть много форм разных форм человеческого мышления. Основные — анализ, синтез, сравнение, абстракция, обобщение. Вы упомянули только одну из них.
I>Это не формы мышления, а высшие психические функциии.
Анализ, синтез, сравнение и тд == Интеллектуальные функции, а не впф (мышление, речь, память).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Покажи сайд-эффект if-а Хаскеля, не балаболь.
V>В выделенном смысле уже показал.
выделенный смысл ты выдумал. Нет таких эффектов в выделенном тобой смысле.
S>>>>В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы.
S>>Ты хотел сказать состояние вычислителя? Покажи мне изменяемое состояние в ПРОГРАММЕ на хаскеле.
V>В исходнике, что ле? С ума сошел? Я могу рассуждать только о работе программы в рантайм. И я тебе уже всё показал.
Так порассуждай и о Логическом программировании в таком же ключе. Получишь что и Логическое выросло из структурного.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Т.е. у Ф программы состояние вычислителя ты обнаружил, а у Л программы нет? S>>
V>Ты точно на этот пост хотел ответить? (см выделенное)
Здравствуйте, vdimas, Вы писали:
V>>>Именно потому. Иерархии абстракций хорошо подходят человеческому мышлению — от общего к частному. S>> Есть много форм разных форм человеческого мышления. Основные — анализ, синтез, сравнение, абстракция, обобщение. Вы упомянули только одну из них.
V>А одна и есть, просто я привел базис, а ты производные:
Выделены главные интеллектуальные функции, которые (с известной долей условности) можно объединить в пять дихотомических пар по принципу соподчиненности:
. анализирование — синтезирование;
. абстрагирование — конкретизация;
. сравнение — сопоставление;
. обобщение — классификация;
. кодирование — раскодирование (декодирование).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>твоя позиция это что-то в духе "давайте будем мешать чистое ООП со всем что мешается, но мешать чистый ФП не будем". Возьми нечистый ФП и сравнивай его с нечистым ООП.
V>Дык, в том-то и дело, что нет в природе никакого "нечистого ООП". Есть просто некие вычисления и есть сохранение результатов вычислений в полях объектов или передача их как сообщений другим объектам. Способ вычислений в ООП никогда не ограничивался, в отличие от чистого ФП, где полно ограничений.
Твои представления об ООП наивны.
V>А "нечистое ФП" — это процедурный подход + функциональный тип. ))
нечистое ФП вполне может быть испачкано ООП-ой
V>Т.е. ты не понял, как "моделирование мира" относится к "воле"? Просто недавно давали определение: воля — это способность принимать решения вопреки безусловным реакциям на внешние раздражители, то бишь умение делать себе чуть хуже сейчас, чтобы получить какие-то бенефиты в будущем. Для работы этого механизма то самое будущее надо уметь моделировать в разных вариантах и сравнивать их.
V>Ключевое в связи ООП с мышлением я вижу именно в способности мышления человека моделировать окружающий мир.
Ничего что до ООП человек тоже мог моделировать окружающий мир? Или возможность моделирования открыл Др. Кэй?
V>>>Указанный выше список разве не описывает ОО-парадигму? S>>и почему-же он описывает только лишь ее?
V>Из-за поведения. В чистом ФП нет поведения, бо поведение — это побочный эффект, эта реакция, которая зависит от всей истории предыдущих воздействий. В ФП же "реакции" функций безусловные, зависят только от текущего воздействия.
С реакцией от истории в ФП все впорядке. Да и вся история как на ладони заодно.
V>С отношениями в ФП тоже большие проблемы из-за наличия лишь одного вида декомпозиции — функционального.
что не так с отношениями?
Здравствуйте, SV., Вы писали:
SV.>Так вот. Свой счет я посадил бы поверх таблицы проводок, и он бы хранил внутренний уникальный идентификатор плюс банковскую атрибутику. Получение состояния на любой момент времени, оборотов за период (а также входящее и исходящее сальдо периода) было бы реализовано в нем в виде методов. Там же — валютный пересчет на основе входящей ссылки на объект, представляющий Форекс (или, по-простому, конфиг текущей сессии). И это как раз и есть модель реального счета.
Совершенно непонятно, зачем всё это запихивать в счёт. SV.>С одной стороны она соответствует модели в голове у бухгалтера, поскольку основывается на проводках.
Не соответствует. SV.>С другой стороны, ее можно отдать, допустим, программисту гуёв, и он найдет в ней и .CalcCurrentBalance(), и что его душе угодно. Не проблема хранить пачку счетов (вектор, например), поскольку реальные инкапсулируемые данные в памяти малы. SV.>Вся эта штука называется объектная модель.
Вся эта штука называется "ошибка архитектуры".
У неё нет никаких преимуществ. То есть совсем никаких. У счетов нет полиморфизма поведения, поэтому нечего и абстрагировать. Точнее, у счёта вообще нет поведения. Вы зачем-то хотите помещать .CalcCurrentBalance() внутрь объекта Account — а зачем?
Смотрите, в чём затык: для вывода баланса на экран придётся построить новый счёт и попросить данные у него:
BalanceLabel.Text = (new Account("03")).CalcCurrentBalance().ToString();
А что такое "Current"? Наверное, есть операция CalcBalanceForDate(Date targetDate), и есть важный инвариант CalcCurrentBalance() == CalcBalanceForDate(new Date()). Этот инвариант верен для всех счетов; то есть, с точки зрения правильного дизайна надо его выносить наружу. Ок, CalcCurrentBalance мы отобрали.
Теперь, код, который я привёл, работать не будет — счёту надо откуда-то взять доступ до своих проводок. Сам он рассчитать баланс никак не сможет.
Откуда он будет брать эти проводки? Из базы? Ну, тогда надо научить его общаться с базой, а это — прямое нарушение SRP. Придётся отпилить от него какую-то функциональность — либо по расчёту баланса, либо по работе с базой.
Если оставить в нём работу с базой, тогда непонятно, почему в нём — почему нам не иметь класс DbManager с методами GetTransfers(Predicate where), кроме которого, в общем-то, ничего и не нужно?
Если оставить в нём работу с расчётом баланса, а проводки отдавать снаружи, то получается, что мы завели целый отдельный класс для примитивов типа
Decimal static CalcBalanceForDate(Date date, allTransfers)
return (from t in allTransfers where t.Date <= date select t.Amount).Sum();
Зачем всё это делать, совершенно непонятно.
Всё, что нужно, прекрасно получается безо всяких объектов Account.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
S>>Ну вот а я считаю что там не точка соприкосновения, я считаю что ниши у подходов пересекаются в значительной мере. Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.
I>Это значит, что у ФП больше ограничений и границы проявляются очень четко.
Так обозначь их
Здравствуйте, Ikemefula, Вы писали:
I>А что значит "мутнее образ" ? Вот скажем дорогу на работу я представляю как три отрезка примерно одинаковой длины. Это вроде как чистой воды абстракция. И где здесь "мутность" ?
Мутность в том, что ты не помнишь каждый кустик, встречаемый тебе по дороге.
S>>>Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку. V>>Функциональные типы тоже до безобразия абстрактны и тоже позволяют инкапсулировать за своими сигнатурами всё, что угодно. Однако же... >>а ФП — только функциональную, которая несильно отличается от процедурной.
I>Покажи на примере, как функциональная композиация несильно отличается от процедурной.
Легко. Для примера, любое замыкание — это пара: { ф-ия, замкнутый_контекст }. ФП-языки представляют эту пару в виде неделимого объекта. Заметь, исходно декомпозиция может идти по двум координатам, то бишь как по ф-ии, так и по замкнутому контексту, но реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции (напомню, что процедурный подход допускает декомпозицию на процедуры и ф-ии). Возвращаясь к декомпозиции по замкнутому контексту — этот вид декомпозиции присутствует в подробностях кода, то бишь на уровне дизайна им можно пренебречь. Аналогично как можно пренебречь процедурной декомпозицией в подробностях реализаций методов в ООП.
Здравствуйте, Sinclair, Вы писали:
SV.>>Допустим, я хочу посчитать a — длинноцелое, b — строка на входе (неизвестное число знаков), c — бинарное представление вещественного числа X(формат IEEE-666, 50 знаков). i = 100. S>Что такое i?
Точность числа, выраженная как количество цифр мантиссы (если не путаю, это называется количество верных значащих цифр).
S>Результат, в зависимости от сиюминутных потребностей, требуется использовать при форматировании строк (пугать комиссии, ага), и отдавать в бинарях для хранения в базе DB-3000. Как будет выглядеть (хотя бы примерно) код вашего проекта? S>Я не понимаю вашего вопроса.
var a = 10500L;
var b = "8.4534523450230523053258239859328534534583475834758734857348758934758349753489" +
"578349758349752763423546325463546523465236453624562354623465236546523645623546235463563" +
"286583653786537568327856378256237238598978182371283e150";
var c = (byte[]) GetIeee666(d);
var aT = ...;
var bT = ...;
var cT = ...;
var Xs = resolveSqEq<T>(aT, bT, cT);
var s = string.Format("Наша группа за отчетный период успешно сосчитала " +
"вакуумный коэффициент коня (это оказался первый корень конно-квадратного уравнения) " +
"с небывалой точностью (100 знаков). Он равен: {0)", ... xS[0] ...);
var bin = ... Xs[1] ...;
db3000.SaveIeee666((byte[]) bin);
До- и переписывайте как угодно, но форматирование строк, хранение в бинарном формате IEEE-666 и заданную точность оставьте, это условия задачи, которые к ООП отношения не имеют.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
I>>Здравствуйте, samius, Вы писали:
S>>>Ну вот а я считаю что там не точка соприкосновения, я считаю что ниши у подходов пересекаются в значительной мере. Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.
I>>Это значит, что у ФП больше ограничений и границы проявляются очень четко. S>Так обозначь их
Легко, фп — вычислительные задачи "унутре" метода которые, кроме того, не требуют изменяемого состояния и всяких числодробилок. Использование ФП на уровене АПИ пока что возможно только в закрытой нише, вроде Эрланга.
Здравствуйте, vdimas, Вы писали:
I>>А что значит "мутнее образ" ? Вот скажем дорогу на работу я представляю как три отрезка примерно одинаковой длины. Это вроде как чистой воды абстракция. И где здесь "мутность" ?
V>Мутность в том, что ты не помнишь каждый кустик, встречаемый тебе по дороге.
То есть, мутный у тебя стало синонимом абстрактный ? Вообще говоря мутный это нечто, мешающее построить абстракцию.
S>>>>Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку. V>>>Функциональные типы тоже до безобразия абстрактны и тоже позволяют инкапсулировать за своими сигнатурами всё, что угодно. Однако же... >>>а ФП — только функциональную, которая несильно отличается от процедурной.
I>>Покажи на примере, как функциональная композиация несильно отличается от процедурной.
V>Легко. Для примера, любое замыкание — это пара: { ф-ия, замкнутый_контекст }. ФП-языки представляют эту пару в виде неделимого объекта. Заметь, исходно декомпозиция может идти по двум координатам, то бишь как по ф-ии, так и по замкнутому контексту, но реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции (напомню, что процедурный подход допускает декомпозицию на процедуры и ф-ии).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Это не только я нахожу и не я это изобрел. Эта лишь одна из практик, которая дополняет современное многопоточное ООП. Ведь ООП не отменяет ни атомарности, ни транзакционности. А понятие валидности состояния в нем было изкаробки. S>>Многопоточный ООП? Ты опять что-то намешал.
V>Ох блин... Зачем МНЕ что-то намешивать, если за нас это намешивает окружающая действительность, то бишь для нас программистов — поступающие задачи. На сегодня многопоточное ООП считай что дано сверху. А требование валидности состояния всегда было. Вот и происходит в ООП наработка новых практик, доселе неактуальных.
Тут понимаешь ли, если в программе на ООП присутствует многопоточность, то многопоточность сама по себе, а ООП само по себе. А многопоточное ООП — это что-то новое.
V>Помнишь я тебе говорил про быстрое устаревание любого догматического подхода что к ООП, что к ФП? По мне порядка 15 лет — таки быстро.
Потоки родились не 15 лет назад. И ООП тоже постарше. Почему до сих пор нет парадигмы МООП или хотя бы статей или книг по нему?
S>>Ну и другими словами ты хочешь сказать что ООП без ФП не самодостаточен? Веский довод...
V>Что я хотел сказать, я уже сказал — методологии воруют полезные практики друг у друга. В этом смысле ФП точно так же не самодостаточен, т.к. тоже является комплексным набором практик. Забери любую из них и сделаешь ему хуже или вообще поломаешь.
так что же конкретно ФП своровал у ООП? Предлагаешь забрать, но не называешь что именно.
V>>>Монады в Хаскеле появились далеко не сразу, это факт. Класы типов — тоже. Иронизировать можешь до бесконечности, ес-но. S>>нет, не могу. Уже надоедает.
V>Дык, тогда можно было бы по делу высказать/подумать, зачем в Хаскель появились монады?
Для удобства.
V>>>Глупости. Банальное понятие ссылочного типа ставит твой ФП раком, и никакая статика не помогает. См. Немерле. S>>А что делает ссылочный тип в чистом ФП (это раз)?
V>А возражает на твою фразу: V>
V>Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.
S>>Это банально справедливо для всей статики
ссылочный тип не имеет отношение к этой фразе. Компилятор помогает и без него.
V>Простых гарантий типобезопасности для работы ФП мало. Нужны еще ограничения на разновидности структур данных.
Ты же сам сказал о том что гоняемся за гарантиями. Не нужны гарантии, которые дают ФП структуры данных — велкам в ООП.
S>>А если очень надо, то IO в руки, как и с MutVar в соседней ветке (два).
V>О чем и речь, что эти вещи появились в Хаскеле не сразу... Собственно как и все вещи, связанные с требованиями мутабельности в реальных программах. Я просто ХЗ зачем отрицать факт заимствования из императивного мира.
Так что было заимствовано?
S>>А что там с Немерле?
V>Дык, когда мы объявляем иммутабельную переменную ссылочного типа, как далеко, по-твоему, распространяется иммутабельность? Предполагаемые участники: V>1. сама ссылочная переменная; V>2. объект, на который cсылается п.1; V>3. объекты, на которые ссылается п.2.
Так это проблема не ФП в целом. Это проблема ФП на рантайме, заточенного под императив.
Есть много форм разных форм человеческого мышления. Основные — анализ, синтез, сравнение, абстракция, обобщение. Вы упомянули только одну из них. 
