Мнение: объектно-ориентированное программирование — катастрофа на триллион долла - Философия программирования

Здравствуйте. Прочитал статью, обсуждение, википедию, еще статьи. И ничего не понял. Объясните.
Никогда не программировал на подобных языках и мне решительно непонятно, как с таким подходом разработать что-то реальное, например, какой-то CAD или игрушку.
Я правильно понимаю, что применяя такой подход, каждое следующее состояние программы будет функцией от предыдущего, причем, это следующее состояние будет создаваться с нуля?
То есть, например, нечто такое:

while (true)
  game.update();

будет реализовываться через рекурсию (псевдокод)

Game update(Game game)
{
  return update(build_next_frame(game));
}

Что-то такое? Или я совсем не туда копаю?

Здравствуйте, Went, Вы писали:

W>Здравствуйте. Прочитал статью, обсуждение, википедию, еще статьи. И ничего не понял. Объясните.
W>Никогда не программировал на подобных языках и мне решительно непонятно, как с таким подходом разработать что-то реальное, например, какой-то CAD или игрушку.
W>Я правильно понимаю, что применяя такой подход, каждое следующее состояние программы будет функцией от предыдущего, причем, это следующее состояние будет создаваться с нуля?

Не обязательно с нуля. Обычно используются специальные структуры данных, см https://en.wikipedia.org/wiki/Persistent_data_structure
Пример объединения списков — создаем якобы список, который имеет интерфейс списка, но который содержит ссылки на исходные списки.

Есть книга Криса Окасаки по таким структурам данным. Самое главное, что нужно извлечь из этой книги —
1 для многих операций крайне трудно добиться внятной асимптотики, сравнимой с обычными мутабельными структурами
2 для многих операций по словами Окасаки он так и не смог найти годной реализации

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, artelk, Вы писали:

A>>ЗЫ Есть подозрение, что основная проблема ООП в том, что нет никакого ООП. И вообще, ООП возник как результат мышления по аналогии и апеллирует к чисто ассоциативному (не понятийному) мышлению.

I>ООП родился из ментальной модели мышления человека.
ООП родился как аналогия со ментальной моделью биологических организмов, состоящих из клеток. Поведение организма сложно, а клетки, из которых он состроит, якобы просты.
Клетки общаются сигналами без передачи вещества. Аналогом этому был data hiding с "посылкой сообщений" вместо передачи данных (неясно только почему параметры у методов при этом не запретили).

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

Далее пришли другие теоретики и переопредилили ООП, подсунув трех китов в качестве основной идеи. Основным преимуществом ООП обозначили якобы повышенную способность кода к повторному использованию, т.к. у нас есть наследование (под которым понималось наследование реализации), а у других нет.

Практика показала, что она отличается от теории и стало понятно, что повторная испольуемось достигается за как раз счет полиморфизма, а не наследования. Появились Coding to the interface, GoF и т.п.

Параллельно всему этому была еще куча разных идей и фантазий, что продолжается до сегодняшнего дня. Куча разных мнений о том, что такое ООП и чем оно не является. Полагаю, что число различных интерпретаций ООП сравнимо с числом программистов, утверждающих, что они эксперты в ООП. И пересечение этих интерпретаций есть пустое множество. Даже если брать только опытных разработчиков, за плечами которых не один успешно завершенный проект средней и выше сложности (на самом деле именно они дают максимальный вклад в уменьшение этого множества

).

I>Софтварные продукты постоянно растут в сложности, а потому арсенал пополняется самыми разными приемами.
Можно развернуто, с примерами?

I>А местные ОО-хейтеры до сих пор три кита ищут.
Ок, три кита уплыли. Что осталось?

Здравствуйте, artelk, Вы писали:

I>>ООП родился из ментальной модели мышления человека.
A>ООП родился как аналогия со ментальной моделью биологических организмов, состоящих из клеток. Поведение организма сложно, а клетки, из которых он состроит, якобы просты.

Это ты чуть позже опровергнешь.

A>Клетки общаются сигналами без передачи вещества. Аналогом этому был data hiding с "посылкой сообщений" вместо передачи данных (неясно только почему параметры у методов при этом не запретили).

Да потому и не запретили, потому что сообщение это передача данных.

A>Еще была фантазия о том, что нам легче понимать ООП код, так как мы якобы сами мыслим мир как совокупность объектов с поведением.

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

A>Не знаю как у других, но для меня объектами с собственным поведением мыслятся в основном только люди (ну и животные отчасти) и имено они являются самыми сложными штуками.

И это тоже сейчас опровергнешь.

A>Все остальное это пассивные предметы, состояние которых я могу менять: надавил на дверь — она открылась; нажал на педаль газа автомобиля — поехали.
A>Автомобиль как нечто имеющее собственное поведение представлялся только в начале обучения езды на нем.

Вот и опровержение.

A>Далее пришли другие теоретики и переопредилили ООП, подсунув трех китов в качестве основной идеи. Основным преимуществом ООП обозначили якобы повышенную способность кода к повторному использованию, т.к. у нас есть наследование (под которым понималось наследование реализации), а у других нет.

Проблема именно в трех китах и неправильном реюзе. Наследование плохо не потому, что реализация наследуется.
Наследование это 2 вещи
1. уточнение типа
2. расширение модуля

1 — хорошо, когда это необходимо и разницы нет, есть реализация, или нет. 2 — почти всегда плохо.

Более того, наследование итерфейсов никак не ухудшает ОО-ность. Тут ровно те же правила.
Если начнешь расширять интерфейс как модуль, появляются те же грабли, только в профиль.
Если использовать интерфейс как уточнение типа — снова всё в порядке.

A>Практика показала, что она отличается от теории и стало понятно, что повторная испольуемось достигается за как раз счет полиморфизма, а не наследования. Появились Coding to the interface, GoF и т.п.

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

Симуловскиая модель трех китов давно уже неадекватная. Но ООП не сводится к симуловской модели трех китов.

I>>Софтварные продукты постоянно растут в сложности, а потому арсенал пополняется самыми разными приемами.
A>Можно развернуто, с примерами?

Абстракция давно уже четвертый кит.
Взаимодействие — еще один.
Поведение — еще один.
Вместо "данные + методы" используем подход "сервис который занят обработкой данных", типа "экскаватор копает землю" @ Sinclair

I>>А местные ОО-хейтеры до сих пор три кита ищут.
A>Ок, три кита уплыли. Что осталось?

А тут надо вспомнить Алана Кея и его принципы. Эта ветвь ~~ислама~~ ООП никогда не переставала быть актуальной. Самое главное в ООП — это обмен сообщениями, абстрагирование, иерархическая композиция объектов, взаимодействие, моделирование поведения.

Например, нет поведения — надо еще поискать. ради чего ооп-шить.

Здравствуйте, samius, Вы писали:

I>>Есть книга Криса Окасаки по таким структурам данным. Самое главное, что нужно извлечь из этой книги —
I>>1 для многих операций крайне трудно добиться внятной асимптотики, сравнимой с обычными мутабельными структурами
I>>2 для многих операций по словами Окасаки он так и не смог найти годной реализации

S>Это главные вещи для тех, кто не видит в персистентных структурах данных никаких преимуществ. Либо считает что эти преимущества пренебрежимо малы по сравнению с проседанием производительности.

Полагаю, ты не согласен. Расскажи, как соптимизировать хаскельный вариант(ну или Окамл), что бы он уступал только Си, Go, Rust http://rsdn.org/forum/philosophy/7541051.1
Если не можешь — расскажи про те самые преимущества, которые смогут перевесить нехватку перформанса у хаскеля(Окамла) в данной задаче.

Я наблюдаю обычно следующее — как только возникает острая нехватка перформанса, то любой разработчик уровнем ниже Криса Окасаки делает следующее:
1. заявляет, что "ваша архитектура не подходит к моему решению" — любимая поза радикальных функционалистов.
2. выбросить лишнее и переписать так, что бы работало максимально быстро.

Практика показывает, что всегда приходят к п.2 и большей частью вся функциональщина идёт нахрен. Не вся, конечно, часть оптимизаций реализуется с помощью функциональщины, наприер ленивые вычисления и тд. Но вот в числодробилках функциональщины около нуля. Там где требования к памяти очень жесткие — снова функциональщина идет нахрен. Там где требуется плотно работать с железом — аналогично, функциональщина идет нахрен.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Это главные вещи для тех, кто не видит в персистентных структурах данных никаких преимуществ. Либо считает что эти преимущества пренебрежимо малы по сравнению с проседанием производительности.

I>Полагаю, ты не согласен. Расскажи, как соптимизировать хаскельный вариант(ну или Окамл), что бы он уступал только Си, Go, Rust http://rsdn.org/forum/philosophy/7541051.1
I>Если не можешь — расскажи про те самые преимущества, которые смогут перевесить нехватку перформанса у хаскеля(Окамла) в данной задаче.

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

I>Я наблюдаю обычно следующее — как только возникает острая нехватка перформанса, то любой разработчик уровнем ниже Криса Окасаки делает следующее:
I>1. заявляет, что "ваша архитектура не подходит к моему решению" — любимая поза радикальных функционалистов.
I>2. выбросить лишнее и переписать так, что бы работало максимально быстро.

I>Практика показывает, что всегда приходят к п.2 и большей частью вся функциональщина идёт нахрен. Не вся, конечно, часть оптимизаций реализуется с помощью функциональщины, наприер ленивые вычисления и тд. Но вот в числодробилках функциональщины около нуля. Там где требования к памяти очень жесткие — снова функциональщина идет нахрен. Там где требуется плотно работать с железом — аналогично, функциональщина идет нахрен.

Мир софта не ограничен одними сетевыми драйверами и числодробилками. А острая нехватка перфоманса софта возникает гораздо реже острой нехватки перфоманса разарботки.

Здравствуйте, Ikemefula, Вы писали:

I>Не обязательно с нуля. Обычно используются специальные структуры данных, см https://en.wikipedia.org/wiki/Persistent_data_structure
I>Пример объединения списков — создаем якобы список, который имеет интерфейс списка, но который содержит ссылки на исходные списки.
То есть, говоря простым языком, каждая версия Game (или вложенные в нее объекты в отдельности) будет хранить некую старую версию и список внесенных изменений, и запрос актуального состояния будет брать базовую и "применять" последние изменения. Нечто вроде репозитория?

I>Есть книга Криса Окасаки по таким структурам данным. Самое главное, что нужно извлечь из этой книги —
I>1 для многих операций крайне трудно добиться внятной асимптотики, сравнимой с обычными мутабельными структурами
I>2 для многих операций по словами Окасаки он так и не смог найти годной реализации
Да я даже не за перфоманс переживаю. Как быть с разнообразными АПИ, с которыми плотно работает любая реальная программа? Они же по любом не "чистые", имеют "мутабельное внутреннее состояние", а, значит, все функции ФЯП, которые будут к ним обращаться, будут тоже "грязными" и вся затея со свободным порядком, параллельностью и ленивостью идет строго лесом? Или я что-то не понимаю в корне?

Здравствуйте, Sharov, Вы писали:

N>>А что ты тут назвал железяками?

S>Клавиатура, GPU.

На них до 224 не догнать

N>>Мне крайне сложно представить себе систему на x86 с 224 внешними устройствами

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

S>А робот какой-нибудь, с кучей переферии?

Вся периферия будет ходить через 2-3 контроллера внешней шины спец. типа (CAN/Modbus/Profibus/ещё какая-то из сотен их), и на контроллер будет одно прерывание (ну, может, до 4, если придумают, как адекватно разделять).

Здравствуйте, Went, Вы писали:

W>То есть, говоря простым языком, каждая версия Game (или вложенные в нее объекты в отдельности) будет хранить некую старую версию и список внесенных изменений, и запрос актуального состояния будет брать базовую и "применять" последние изменения. Нечто вроде репозитория?

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

I>>1 для многих операций крайне трудно добиться внятной асимптотики, сравнимой с обычными мутабельными структурами
I>>2 для многих операций по словами Окасаки он так и не смог найти годной реализации
W>Да я даже не за перфоманс переживаю. Как быть с разнообразными АПИ, с которыми плотно работает любая реальная программа? Они же по любом не "чистые", имеют "мутабельное внутреннее состояние", а, значит, все функции ФЯП, которые будут к ним обращаться, будут тоже "грязными" и вся затея со свободным порядком, параллельностью и ленивостью идет строго лесом? Или я что-то не понимаю в корне?

Все правильно. Все используемые АПИ должны быть переделаны. Или, как вариант, нужен слой изоляции. Проблема глубже — на таком подходе невозможно сделать публичный API, что бы клиенты могли быть любыми — хоть чистыми, хоть грязными. Нужно переприсваивание куда нибудь перепрятывать.

Пока что функционалисты такую вещь как DOM осилить не могут. Слишком трудно реализовать иммутабельный вариант. Теоретически это возможно, на практике заявления вида "а мы всё равно круче". Вот пример http://rsdn.org/forum/philosophy/7551421.1

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

Здравствуйте, netch80, Вы писали:

S>>Клавиатура, GPU.
N>На них до 224 не догнать

Клавиатуры то через usb хабы? А почему GPU не догнать, pci не хватит?

Здравствуйте, Sharov, Вы писали:

S>>>Клавиатура, GPU.
N>>На них до 224 не догнать

S>Клавиатуры то через usb хабы? А почему GPU не догнать, pci не хватит?

Ну а какая GPU карта, и зачем, осмысленно применит хотя бы 30 прерываний?

Здравствуйте, Ikemefula, Вы писали:
I>Необязательно. Список это например пара значение-хвост. Достаточно все операции, включая удаление, реализовать через создание нового списка. На этой же модели можно сделать целую кучу структур данных, например — деревья. Но вот хеш таблицу уже нельзя. Вместо этого делают адское дерево, где асимптотика похожа на хештаблицу и реализацию которого может понять только упоротый математик

Да, со списками как раз все просто. Но, вот, представим себе пулю, которая каждый кадр смещается на 1 мм, и таких кадров 1000 в секунду. Каждый кадр создавать новую пулю? Конечно, тут можно сказать, что положение пули не переменная, а иммутабельная функция от времени, но это же упрощенный случай. В реальном мире у каждого объекта десятки быстро изменяющихся свойств и влияют на эти свойства десятки других быстро изменяющихся свойств, и записать поведение, например, 1000 сталкивающихся в колбе атомов газа в виде функции уже нереально. Утопия какая-то, по-моему.

I>Разумеется, это все про абсолютную чистоту. Если комбинировать подходы, что радикальный функционалисты не приемлют, получается очень даже неплохие результаты.
Наверное, да. В рендере, например, не совсем чистый функциональный подход работает отлично.

Здравствуйте, Went, Вы писали:

W>Да, со списками как раз все просто. Но, вот, представим себе пулю, которая каждый кадр смещается на 1 мм, и таких кадров 1000 в секунду. Каждый кадр создавать новую пулю?
Если кому-то хватило ума засунуть координаты в пулю, то, конечно, в рамках функционального подхода придется клонировать пулю, что бы поменять координату. Но в рендеринге обычно ровно наоборот. Пуля/елка одна, а координат миллион.
W> Конечно, тут можно сказать, что положение пули не переменная, а иммутабельная функция от времени, но это же упрощенный случай. В реальном мире у каждого объекта десятки быстро изменяющихся свойств и влияют на эти свойства десятки других быстро изменяющихся свойств, и записать поведение, например, 1000 сталкивающихся в колбе атомов газа в виде функции уже нереально. Утопия какая-то, по-моему.
Свойства "объекта" меняются не просто так, а по законам, которые можно записывать функциями. Имея такую запись, нет нужды обновлять свойства "объекта" каждый момент времени, т.к. в любой из них его свойства можно вычислить. Повторюсь, если не запихивать координату в пулю/атом, то может оказаться что не нужно ее быстро-быстро менять.
Однако, моделирование столкновений частиц с помощью ООП (да и ФП, что говорить) — то еще садо-мазо и оверхед. Такие вещи делают на Си/Фортранах, объекты там обычно избыточны.

Здравствуйте, samius, Вы писали:
S>Если кому-то хватило ума засунуть координаты в пулю, то, конечно, в рамках функционального подхода придется клонировать пулю, что бы поменять координату. Но в рендеринге обычно ровно наоборот. Пуля/елка одна, а координат миллион.
А можно чуточку конкретнее? В функциональном подходе пуля не хранит свои координаты? А кто их хранит? И при чем тут рендеринг?

S>Свойства "объекта" меняются не просто так, а по законам, которые можно записывать функциями. Имея такую запись, нет нужды обновлять свойства "объекта" каждый момент времени, т.к. в любой из них его свойства можно вычислить.
Да, движение материальной точки в вакууме без посторонних тел отлично записывается простейшей функцией. Но, ведь, в реальном приложении все иначе. Говоря просто (опуская оптимизации) каждый кадр мы должны проверить коллизию каждой частицы с каждой. То есть каждый кадр мы запрашиваем положение каждой частицы, и в самом лобовом случае мы запрашиваем это положение (коллизию каждой частицы с каждой) квадрат количества частиц раз пополам. То есть каждый раз рассчитывать это положение явно избыточно, его проще просчитать один раз. Получается, нам нужен некоторый кэш на каждую подобную функцию? Но в императивный подход этот кэш встроен "из коробки" и никаких дополнительных функций хранить не нужно.

S>Повторюсь, если не запихивать координату в пулю/атом, то может оказаться что не нужно ее быстро-быстро менять.
А куда их запихнуть?

S>Однако, моделирование столкновений частиц с помощью ООП (да и ФП, что говорить) — то еще садо-мазо и оверхед. Такие вещи делают на Си/Фортранах, объекты там обычно избыточны.
Я сейчас не сравниваю ФП с ООП. Я сравниваю ФП с императивным программированием.

Здравствуйте, Went, Вы писали:

W>Здравствуйте, samius, Вы писали:
S>>Если кому-то хватило ума засунуть координаты в пулю, то, конечно, в рамках функционального подхода придется клонировать пулю, что бы поменять координату. Но в рендеринге обычно ровно наоборот. Пуля/елка одна, а координат миллион.
W>А можно чуточку конкретнее? В функциональном подходе пуля не хранит свои координаты? А кто их хранит? И при чем тут рендеринг?
Здесь дело не в функциональном подходе. Просто увидел упоминание рендеринга, а я с ним имел дело давным-давно. Безотносительно подхода речь лишь о здравом смысле. Если нужно нарисовать 1000000 елок или пуль, то при засовывании координаты внутрь объекта потребуется создать (и удалить потом) 1000000 объектов, которые будут отличаться лишь координатой, т.е. одним атрибутом. В ситуации, когда координату суют не в объект, то объект нужен лишь один.

W>Да, движение материальной точки в вакууме без посторонних тел отлично записывается простейшей функцией. Но, ведь, в реальном приложении все иначе. Говоря просто (опуская оптимизации) каждый кадр мы должны проверить коллизию каждой частицы с каждой. То есть каждый кадр мы запрашиваем положение каждой частицы, и в самом лобовом случае мы запрашиваем это положение (коллизию каждой частицы с каждой) квадрат количества частиц раз пополам. То есть каждый раз рассчитывать это положение явно избыточно, его проще просчитать один раз. Получается, нам нужен некоторый кэш на каждую подобную функцию? Но в императивный подход этот кэш встроен "из коробки" и никаких дополнительных функций хранить не нужно.
Если опустить оптимизации (типа предварительной проверки пересечения траекторий или сегментации сцены), то в ФП нет никакой проблемы построить коллекцию вычисленных координат для данного кадра и сделать проверку в рамках полученной коллекции координат.

S>>Повторюсь, если не запихивать координату в пулю/атом, то может оказаться что не нужно ее быстро-быстро менять.
W>А куда их запихнуть?
Это зависит от задачи прежде всего. Для расчета тех же коллизий можно же не вписывать координату в объект, а наоборот, к вычисленной координате добавить ссылку на объект, либо находить объект по индексу координаты в массиве ссылок. Так процесс проверки координат на коллизии даст меньше промахов кэша при проверке всех со всеми (с большим кол-вом объектов), чем если в кэше будут большие объекты с маленькой координатой, которую надо проверить.

S>>Однако, моделирование столкновений частиц с помощью ООП (да и ФП, что говорить) — то еще садо-мазо и оверхед. Такие вещи делают на Си/Фортранах, объекты там обычно избыточны.
W>Я сейчас не сравниваю ФП с ООП. Я сравниваю ФП с императивным программированием.
Рендеринг, как и моделирование физпроцессов — это категория числодробилок, т.е. чем больше размерность задачи и чем быстрее она выполнена — тем круче. На этом поле императивное программирование побеждает безоговорочно, т.к. позволяет деструктивные изменения, следовательно позволяет выбирать лучшую асимпотику для алгоритмов, дружелюбнее к железу. ФП по производительности результата в таких задачах сможет конкурировать лишь с топорными и неоптимизированными императивными решениями.

Здравствуйте, Went, Вы писали:

W>Да, со списками как раз все просто. Но, вот, представим себе пулю, которая каждый кадр смещается на 1 мм, и таких кадров 1000 в секунду. Каждый кадр создавать новую пулю?
это зависит от того как организовать хранение этих данных. например может быть структура с полями: меняющиеся части (координата, вектор скорости), ссылка на пулю (статичное описание пули — зd модель и всё такое). клонирование такой структуры быстрая операция.
Кстати сам рендеринг — это функция, на входе описание мира/кадра, на выходе — картинка кадр.

Здравствуйте, MadHuman, Вы писали:

MH>это зависит от того как организовать хранение этих данных. например может быть структура с полями: меняющиеся части (координата, вектор скорости), ссылка на пулю (статичное описание пули — зd модель и всё такое). клонирование такой структуры быстрая операция.
Конечно, никто не предлагает клонировать статические данные, это очевидно. Но, в любом случае клонирование даже изменчивой части на порядок затратней простого изменения одного поля. Более того, мало скопировать сам объект (в нашем случае — изменчивую пулю), нужно еще как-то переправить все ссылки на нее. А это тоже огромные затраты. А если "изменчивая пуля" хранит в себе еще какие-то коллекции, члены которых могут меняться, наступает вообще алес капут. Мне трудно представить, сколько ядер должно быть у машины и как четко должно быть реализовано их параллельное взаимодействие с памятью (пускай, даже только на чтение), чтобы функциональный подход себя оправдал в подобных задачах.

MH>Кстати сам рендеринг — это функция, на входе описание мира/кадра, на выходе — картинка кадр.
Да, об этом я писал выше. Рендеринг ложится на функциональное описание довольно неплохо. Собственно, он везде на нем и реализован. Как известно, зависимые выборки — это одна из главных причин падения производительности шейдеров.

Здравствуйте, samius.
Спасибо за пояснения

Основное направление я понял, а дальнейшее углубление без практики, думаю, смысла иметь не будет

Здравствуйте, Went, Вы писали:

W>Конечно, никто не предлагает клонировать статические данные, это очевидно. Но, в любом случае клонирование даже изменчивой части на порядок затратней простого изменения одного поля. Более того, мало скопировать сам объект (в нашем случае — изменчивую пулю), нужно еще как-то переправить все ссылки на нее. А это тоже огромные затраты.

Переправить все ссылки — это деструктивное изменение. Нельзя.

W>А если "изменчивая пуля" хранит в себе еще какие-то коллекции, члены которых могут меняться, наступает вообще алес капут. Мне трудно представить, сколько ядер должно быть у машины и как четко должно быть реализовано их параллельное взаимодействие с памятью (пускай, даже только на чтение), чтобы функциональный подход себя оправдал в подобных задачах.

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

(Если выбирать автомобиль только лишь по цене и расходу, внезапно выяснится что Ока — один из лучших вариантов)

	От:	Went
	Дата:	26.09.19 07:11
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	26.09.19 10:23
Оценка:	4 (1)

	От:	artelk
	Дата:	26.09.19 11:11
	Оценка:	-1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	26.09.19 11:35
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	26.09.19 12:13
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	27.09.19 14:08
Оценка:	5 (1)

	От:	MadHuman
	Дата:	28.09.19 11:09
	Оценка: