В своей статье Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией (на то оно и функционально ). И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N), в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

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

К>В своей статье Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией (на то оно и функционально ). И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N), в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность


Читая эту статью я так и не понял, за счёт чего ФЯ устраняют оверхед. Ну и что, что "я могу быть спокоен, что никакие поля не изменяются"? В ООП я то же могу быть спокоен: ведь приватная часть от меня скрыта, она мала и скорее всего там всё изменяется согласованно, и если код класса написан правильно и система правильно декомпозирована на классы, то все последсвия применения методов должны быть очевидны ( не бейте ногами за это выражение, но ведь он то же ничего не доказывает). Потом, функции можно объединить в группы и получим... ФЯ ООП .

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

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


FDS> Читая эту статью я так и не понял, за счёт чего ФЯ устраняют оверхед. Ну и что, что "я могу быть спокоен, что никакие поля не изменяются"? В ООП я то же могу быть спокоен: ведь приватная часть от меня скрыта, она мала и скорее всего там всё изменяется согласованно, и если код класса написан правильно и система правильно декомпозирована на классы, то все последсвия применения методов должны быть очевидны ( не бейте ногами за это выражение, но ведь он то же ничего не доказывает). Потом, функции можно объединить в группы и получим... ФЯ ООП .

В том и дело что никто ничему не должен в обычных ООЯ, императивных...
Ключевой момент проскакивал недавно в твоём обсуждении Немерле с Владом, где он тебе показывал, что mutable это не есть гуд с точки зрения масштабируемости, зависимостей и т.д.
В ФП если ты знаешь функцию и параметры, то результат функции (если она не имеет побочных действий) будет одним и тем же и в 1-й и в 1000-й вызов её. Методы же в ООП оперируют над объектами, которые содержат их состояния, поэтому для одного и того же результата тебе необходимо чтобы состояния ВСЕХ объектов, участвующих в методе было точно таким же.
Или вот пример (не ругай за его глупость, но первое, что в голову пришло):

class Counter{
 private int i = 0;
 public void Inc() { i++; }
 public int Get() { return i;}
}

class A{
  private Counter myCounter = new Counter();
  private void SomeSuperFunc();
  public GetMySuperInt() { 
    // тут совершается что-то после чего надо счётчик увеличить
    SomeSuperFunc();
    myCounter.Inc(); 
    return myCounterGet(); 
  }
}

Причём тут вообще метод без параметров, только внутреннее состояние. Что тут несогласовано? И сравни что произойдёт при первом вызове и при следующем метода A::GetMySuperInt() одного и того же объекта.
Это пример чуть надуманый, но ООП поощеряет вот такие конструкции, когда состояние прячется внутрь и появляются зависимости по состоянию.
При функциональном подходе композиция была бы проделана иначе (счётчик был бы вынесен из класса, но зачем, если он чётко связан с объектом класса A, скажут апологеты ООП?), можно и на ООП языке сделать такую декомпозицию, но тогда все ООП особенности будут уже не в тему.

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

Кто тебе это сказал?
И в блоге есть примеры, кто захочет, тот запросто найдёт.

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

К>И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N),

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

К> в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

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

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

FR>Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния.

Вопрос только в том, что этот интерфейс будет зависеть от типа объекта (чтоб учитывать полиморфные вызовы и т.п.), а в том же Руби вообще может быть переопределён для конкретного объекта, что ещё более "ухитряет" ситуацию...
А про публичный интерфейс — хоть он запубличный будет, но в любом случае у тебя всё поведение объекта определяется его состоянием, которое как раз на приватных полях основано (в общем случае, хотя не обязательно )

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

FR>Здравствуйте, Курилка, Вы писали:

К>>И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N),

FR>Надо учесть что в ФП параметром может быть и зубодробильная рекурсивная структура, а также очень часто и другая функция, при том тянущая за собой замыкание, так что думаю объем не меньше, но часто этот объем более компактно и красиво упакован.

Дак объекты в ООП сами по себе рекурсивны, т.к. содержат ссылки на др. объекты, т.е. даже без зубодробильности рекурсия получается как нефиг делать, тогда как в ФП эта рекурсивность не есть необходимость, а используется при необходимости оной в самой задаче.
А про замыкание — дак это тот же объект, только вид сбоку (ср. функторы с приватными членами как "замкнутыми" переменными)

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

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

FR>>Связность зависит только от публичного интерфейса (и даже от только используемого в данной функции интерфейса), а не от состояния.

К>Вопрос только в том, что этот интерфейс будет зависеть от типа объекта (чтоб учитывать полиморфные вызовы и т.п.), а в том же Руби вообще может быть переопределён для конкретного объекта, что ещё более "ухитряет" ситуацию...

На связность это не влияет.

К>А про публичный интерфейс — хоть он запубличный будет, но в любом случае у тебя всё поведение объекта определяется его состоянием, которое как раз на приватных полях основано (в общем случае, хотя не обязательно )

Поведение да, но связность

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

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

FR>>Здравствуйте, Курилка, Вы писали:

К>>>И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N),

FR>>Надо учесть что в ФП параметром может быть и зубодробильная рекурсивная структура, а также очень часто и другая функция, при том тянущая за собой замыкание, так что думаю объем не меньше, но часто этот объем более компактно и красиво упакован.

К>Дак объекты в ООП сами по себе рекурсивны, т.к. содержат ссылки на др. объекты, т.е. даже без зубодробильности рекурсия получается как нефиг делать, тогда как в ФП эта рекурсивность не есть необходимость, а используется при необходимости оной в самой задаче.

Все равно получается сопоставимая сложность на одних и тех же задачах.

К>А про замыкание — дак это тот же объект, только вид сбоку (ср. функторы с приватными членами как "замкнутыми" переменными)

Угу и так как замыкания очень часто используется, это показывает что автор не совсем прав в своем противопоставлении

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

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


FDS>> Читая эту статью я так и не понял, за счёт чего ФЯ устраняют оверхед. Ну и что, что "я могу быть спокоен, что никакие поля не изменяются"? В ООП я то же могу быть спокоен: ведь приватная часть от меня скрыта, она мала и скорее всего там всё изменяется согласованно, и если код класса написан правильно и система правильно декомпозирована на классы, то все последсвия применения методов должны быть очевидны ( не бейте ногами за это выражение, но ведь он то же ничего не доказывает). Потом, функции можно объединить в группы и получим... ФЯ ООП .

К>В том и дело что никто ничему не должен в обычных ООЯ, императивных...
К>Ключевой момент проскакивал недавно в твоём обсуждении Немерле с Владом, где он тебе показывал, что mutable это не есть гуд с точки зрения масштабируемости, зависимостей и т.д.
К>В ФП если ты знаешь функцию и параметры, то результат функции (если она не имеет побочных действий) будет одним и тем же и в 1-й и в 1000-й вызов её. Методы же в ООП оперируют над объектами, которые содержат их состояния, поэтому для одного и того же результата тебе необходимо чтобы состояния ВСЕХ объектов, участвующих в методе было точно таким же.

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

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

FR>Здравствуйте, Курилка, Вы писали:

К>>И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N),

FR>Надо учесть что в ФП параметром может быть и зубодробильная рекурсивная структура, а также очень часто и другая функция, при том тянущая за собой замыкание, так что думаю объем не меньше, но часто этот объем более компактно и красиво упакован.

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

К>> в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

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

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

К>>А про замыкание — дак это тот же объект, только вид сбоку (ср. функторы с приватными членами как "замкнутыми" переменными)

FR>Угу и так как замыкания очень часто используется, это показывает что автор не совсем прав в своем противопоставлении

Замыкания — это не объект. Объект характеризуется наличием mutable state (object = Abstract Data Type + state), в замыкании state и не пахнет, как впрочем и ADT. Нет в них состояния. Так что автор если и не прав, то совсем не по этому.

FDS> Читая эту статью я так и не понял, за счёт чего ФЯ устраняют оверхед. Ну и что, что "я могу быть спокоен, что никакие поля не изменяются"? В ООП я то же могу быть спокоен: ведь приватная часть от меня скрыта, она мала и скорее всего там всё изменяется согласованно, и если код класса написан правильно и система правильно декомпозирована на классы, то все последсвия применения методов должны быть очевидны ( не бейте ногами за это выражение, но ведь он то же ничего не доказывает). Потом, функции можно объединить в группы и получим... ФЯ ООП .

"скорее всего всё изменяется согласованно," "если код класса написан правильно," "система правильно декомпозирована."

Три условия должны выполняться одновременно.

Для ФЯ это никуда не девается, но получить получается легче.

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

К>В своей статье Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией (на то оно и функционально ). И в комментариях приводится довольно простая арифметика: тогда как в ФП исходными данными мы имеем лишь парметры функции (скажем N), в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

Статью пока не читал, но с твоих слов выглядит что статья очередной бред.

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

Кстати, вот ОКамл — это ФЯ или ООЯ?

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

К>Ключевой момент проскакивал недавно в твоём обсуждении Немерле с Владом, где он тебе показывал, что mutable это не есть гуд с точки зрения масштабируемости, зависимостей и т.д.
К>В ФП если ты знаешь функцию и параметры, то результат функции (если она не имеет побочных действий) будет одним и тем же и в 1-й и в 1000-й вызов её. Методы же в ООП оперируют над объектами, которые содержат их состояния, поэтому для одного и того же результата тебе необходимо чтобы состояния ВСЕХ объектов, участвующих в методе было точно таким же.

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

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

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

В общем, я за банальность — за разумный выбор наиболее подходящих средств и за предрасположенность к immutable. То есть если immutable хорошо ложится на задачу, то выбираем его. Если есть противопоказания, то взвешиваем все за и против и принимаем решение.

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

Цитируй по меньше, пожалуйста.

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

G>Замыкания — это не объект. Объект характеризуется наличием mutable state (object = Abstract Data Type + state), в замыкании state и не пахнет, как впрочем и ADT. Нет в них состояния. Так что автор если и не прав, то совсем не по этому.

class Point
{
    public Point(int x, int y)
    {
        X = x;
        Y= y;
    }
    
    public Point Offset(int xOffset, int yOffset)
    {
        Point(x + xOffset, y + xOffset)
    }
    
    public readonly int X;
    public readonly int Y;
}

...

Point pt = new Point(1, 3);
Point pt2 = pt.Offset(1, 0);

Внимание, вопрос! Point не объект?

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

FR>>Угу и так как замыкания очень часто используется, это показывает что автор не совсем прав в своем противопоставлении

G>Замыкания — это не объект. Объект характеризуется наличием mutable state (object = Abstract Data Type + state), в замыкании state и не пахнет, как впрочем и ADT. Нет в них состояния. Так что автор если и не прав, то совсем не по этому.

В чистой функциональщине да сосотояния нет, но в том же лиспе (и императивщине с замыканиями) очень похоже на объект.
Да и в ЧФ замыкание также как и объект может служить черным ящиком поведение которого зависит от начальных данных.

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


FR>>Надо учесть что в ФП параметром может быть и зубодробильная рекурсивная структура, а также очень часто и другая функция, при том тянущая за собой замыкание, так что думаю объем не меньше, но часто этот объем более компактно и красиво упакован.

G>Это запросто. Только контекст замыкания не может изменяться, так что нам пофиг, есть замыкание в параметрах, или его нет. Это совершенно все равно. Другое дело, что параметром может припереть функция высшего порядка, которая возвращает функцию высшего порядка, которая... потом будет передана параметром в другую функцию высшего порядка. И так несколько раз.

Изменятся не может но тянуть вызовов и ссылок может не меньше чем объект.

К>>> в ООП каждый параметр может быть объектом, который хранит какие-то переменные состояния + переменные состояния самого объекта (который тоже является неявным параметром метода) получаем в итоге X0+X1+..+Xn, где Xi — переменные состояния i-го объекта (0-й это объект метод которого вызывается), да и это ещё далеко не всё, для объектов надо ещё добавить информацию об их типах (для учёта полиморфизма и т.п.). Получаем в итоге заметно большую связность

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

Это не связность, а граф вызовов

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

VD>Статью пока не читал, но с твоих слов выглядит что статья очередной бред.

Пастернака не читал, но осуждаю :-)

VD>Такое ощущение что в функциональной программе не может быть объектов.

Это ощущение, наверное, из-за сабжа. Он действительно несколько агрессивен. На самом деле в статье говорится о том, о чём сказал Курилка:

Ярив кроме того, что показывает то, как он пришёл в итоге к Эрлангу, рассказывает о том, насколько ООП добавляет больший оверхэд именно благодаря своим ООП-особенностям, тогда как в функциональном программировании контектс ограничивается функцией

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

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

FR>>>Угу и так как замыкания очень часто используется, это показывает что автор не совсем прав в своем противопоставлении

G>>Замыкания — это не объект. Объект характеризуется наличием mutable state (object = Abstract Data Type + state), в замыкании state и не пахнет, как впрочем и ADT. Нет в них состояния. Так что автор если и не прав, то совсем не по этому.

FR>В чистой функциональщине да сосотояния нет, но в том же лиспе (и императивщине с замыканиями) очень похоже на объект.
FR>Да и в ЧФ замыкание также как и объект может служить черным ящиком поведение которого зависит от начальных данных.

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

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