У Лурье, к слову, тоже были (и до сих пор есть) подобные сложности: его «высшая теория топосов» с доказательством гипотезы Баеца-Долана — работа крайне абстрактная и тяжёлая для усвоения. Однако же её усвоили. Характерен, к слову, комментарий о роли Гротендика по ссылке на MO.
Это формализация, которая (в силу изоморфизма Карри-Говарда) является верификацией. Проверка доказательства — задача куда как более простая, чем оного доказательства поиск.
Не возьмусь формализовать свою точку зрения, но сугубо эмпирически такая модель (проектирование по спирали) рано или поздно (если остался хоть один архитектор, ответственный за соответствующий кусок кода) приводит к рефакторингу формата «проще всё выкинуть и переписать с нуля».
Что касается темы обсуждения в общем, то не следует забывать, что нарушение инкапсуляции — это далеко не всегда плохо: горизонтальная инкапсуляция в архитектуре, например, зачастую приводит к over engineering'у и раздуванию кода.
Если долго высушивать ООП над медленным огнём, останется одна динамическая диспетчеризация — как можно более позднее связывание. Добавить к этому отсутствие разделяемой памяти, и лучшим ОО-языком современности станет Erlang.
А в качестве теоретической базы к ООП следовало бы давать теорию категорий.
Проектирование (независимо от того, ООП у нас или какая другая методология, расчитанная на построение иерархий типов) должно идти от интерфейсов к реализации. Если у вас в интерфейсе есть метод, просто предоставляющий некоторое значение, то это нормально и к этому случаю применимы все положительные качества геттеров; если же геттер появляется в интерфейсе вследствие реализации — интерфейса не хватило, дыру в абстракции получилось закрыть прокидыванием значения,- тогда это самое что ни на есть нарушение инкапсуляции.
Если проектирование у вас начало идти от реализации к интерфейсу — это всегда нарушение инкапсуляции. Независимо от того, какую логику и в какой момент времени вы в геттер засунете.
Ну, не рекомендовано не означает нельзя. Оба языка, в общем-то, уже отошли от принципа «не платить за то, что не используется» — так какая разница, кто отошёл дальше?
Ошибка как минимум в выводах, основанных на незнании. Примитивный mark and sweep GC — это одно, современный GC с регионами и поколениями — совсем другое. Есть и RT Java в конце концов.
Огурцы и помидоры можно складывать в свободной абелевой группе, порождённой огурцом и помидором. То, что этого сделать нельзя,- одна из самых популярных в народе вредных эвристик.
Вообще я хотел бы несколько развернуть свою мысль, раз мы уж заговорили о пределах. Предел (в категориальном смысле) — это некоторая «наиболее хорошая» конструкция в даных условиях; пример — декартово произведение двух множеств A и B является наименьшим объектом AxB таким, что из него можно построить проекции на исходные множества AxB -> A и AxB -> B (а уравнитель в категории множеств — наименьший объект, уравнивающий домены двух функций). Подобных объектов множество, но «лучший» — один (с точностью до изоморфизма).
Проблема интуитивного подхода к пределам заключается в том, что далеко не все категории являются такими же хорошими, как категория множеств. Так, у физиков есть теорема Белла, доказывающая, что произведение физических систем (описываемых Гильбертовыми пространствами) не является декартовым — соответствующий предел не существует. В категории множеств не проблема построить морфизм вида f(x) = (x, x) — однако ни в химических уравнениях, ни в Фейнмановских диаграммах нельзя удвоить (или удалить) значение.
Где-то поэтому обобщение теоретико-множественного подхода на математику (и науку в целом) является очень вредной эвристикой. И именно поэтому с понятием функции (морфизма) следует обращаться по возможности формально и аккуратно.
Если в работах Мотидзуки есть интересные мысли — их там обязательно найдут, отряхнут и объяснят простоым языком (ну, как когомологии на примере арифметики за третий класс).
mathoverflow.net
golem.ph.utexas.edu/category/
Воеводский с вами не согласен
Что касается темы обсуждения в общем, то не следует забывать, что нарушение инкапсуляции — это далеко не всегда плохо: горизонтальная инкапсуляция в архитектуре, например, зачастую приводит к over engineering'у и раздуванию кода.
А в качестве теоретической базы к ООП следовало бы давать теорию категорий.
Если проектирование у вас начало идти от реализации к интерфейсу — это всегда нарушение инкапсуляции. Независимо от того, какую логику и в какой момент времени вы в геттер засунете.
Надо выполнить оптимизацию — выполним.
И к математике Haskell, вообще говоря, имеет не большее отношение, чем C++ или D.
На сколько ещё наводящих вопросов мне надо будет ответить, чтобы добиться ответа от вас?
import Data.Char(toUpper)
main = do
inpStr <- readFile "input.txt"
writeFile "output.txt" (map toUpper inpStr)
Сомниваюсь, что наивное чтение/запись во многих языках записываются лаконичней. И это пример из учебника, без всяких клёвых штук вроде iteratees.
Проблема интуитивного подхода к пределам заключается в том, что далеко не все категории являются такими же хорошими, как категория множеств. Так, у физиков есть теорема Белла, доказывающая, что произведение физических систем (описываемых Гильбертовыми пространствами) не является декартовым — соответствующий предел не существует. В категории множеств не проблема построить морфизм вида f(x) = (x, x) — однако ни в химических уравнениях, ни в Фейнмановских диаграммах нельзя удвоить (или удалить) значение.
Где-то поэтому обобщение теоретико-множественного подхода на математику (и науку в целом) является очень вредной эвристикой. И именно поэтому с понятием функции (морфизма) следует обращаться по возможности формально и аккуратно.