Re: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.03.24 02:56
Оценка: 4 (1) +7 :)
Здравствуйте, Разраб, Вы писали:
Р>Появляется неявный контекст, "за лесом не видно деревьев".

Принципиальное отличие в наличии изменяемого состояния, для которого необходима идентифицируемость (identity).
Всё остальное — непринципиально. Если его нет, то объект — это просто набор функций, которые объединены (или не объединены) общим замыканием. Интерфейс становится кортежем функций, а класс — синоним конструктора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.03.24 07:08
Оценка: 4 (1) +2 :)
Здравствуйте, viellsky, Вы писали:


S>>ООП это прежде всего состояние

V>Собственно, и всё

S>>и сокращения кода за счет наследования и переопределении методов.

V>Ни при наследовании ни при переопределении код (функций/методов) не сокращается. Сокращается только код, относящийся к состоянию. Т.е. всё отличие как ни крути сводится к появлению состояния и индивидуальных языковых плюшек для упрощения работы с ним.

Вот помню я программировал на Фортране, Паскале (не Турбо). Там никакого ООП не было. Только процедурное программирование. Но было состояние. Глобальные переменные и переменные функции и параметры.
Которые в огромном количестве передавались из метода в метод.
Что бы не таскать переменные через параметры, решили передавать через ссылку на структуру.
А затем, зачем нам передавать явно, давай прикрутим методы к структуре, а self будем передавать неявно через регистр, прикрутили наследование и VMT, информацию о типе, ну и так далее Получился ООП
и солнце б утром не вставало, когда бы не было меня
Отредактировано 07.03.2024 20:54 Serginio1 . Предыдущая версия . Еще …
Отредактировано 06.03.2024 15:25 Serginio1 . Предыдущая версия .
Отредактировано 06.03.2024 13:49 Serginio1 . Предыдущая версия .
Отредактировано 06.03.2024 10:42 Serginio1 . Предыдущая версия .
Re: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.03.24 14:23
Оценка: 4 (1) -2
Здравствуйте, Разраб, Вы писали:

ООП это прежде всего состояние и сокращения кода за счет наследования и переопределении методов.
Плюс поддержка интерфейсов, замена множественного наследия.
и солнце б утром не вставало, когда бы не было меня
Re: Базовое отличие ООП от ФП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.03.24 07:00
Оценка: +1 -1 :)
Здравствуйте, Разраб, Вы писали:

Р>Выше ООП и ФП подход к решению одной задачи.

В твоем примере нет ООП.
Одного наличия слова class и вызова через точку недостаточно чтобы код стал ООП.
Re[8]: Базовое отличие ООП от ФП
От: novitk США  
Дата: 05.03.24 19:12
Оценка: 12 (1) +1
Здравствуйте, Serginio1, Вы писали:

S> Я бы с удовольствием использовал F# для того же Рослина ну и просто мозг развлечь.

S>А так лениво делать в разных проектах.
Не понимаю use case. Для "того же Рослина" надо работать в MS, а для "просто мозг развлечь" берешь F# interactive и никакие проекты не нужны.
Re[9]: Базовое отличие ООП от ФП
От: · Великобритания  
Дата: 03.04.24 10:59
Оценка: +2
Здравствуйте, sergii.p, Вы писали:

s> S>А как из этого изготовить хоть что-то полезное?

s> так объект можно сконструировать:
s>
s> const auto m = MyObject().setField1(1).setField2(2).setField3(3);
s>

Какой-то игрушечный пример. Сразу видно плохая продуманность фич. По отдельности вроде всё круто, но вместе никак не стыкуется. Обычно хочется чтобы была возможность структурировать код. Например, вынести setField1 и setField2 в отдельный метод, а setField3 проставлять только по какому-то условию. А ещё есть field4 который контейнер в который что-то может несколько раз добавляться.
И тут без полноценного типа Builder не получится.
avalon/3.0.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 10:27
Оценка: :))
Здравствуйте, Serginio1, Вы писали:

P>>И, поскольку, return m.with... не пролезет, то это вполне себе годное ограничение.

S> А не проще через конструктор . Ведь readOnly тоже должны быть инициализированы! И конструктор без параметров должен быть запрещен!

При чем здесь проще? Речь о том, для чего можно использовать заявленную фичу.

Если выбирали такой дизайн по какой причине, то очевидно что readonly и запрет такого конструктора сюда не входит.
Re: Базовое отличие ООП от ФП
От: diez_p  
Дата: 06.03.24 11:47
Оценка: 8 (1)
Здравствуйте, Разраб, Вы писали:

Р>

Р>/// Simplicity
Р>module FP =
Р>    let add_v1 = fun a b -> a + b
Р>    let add_v2 = (+)
Р>    let add_v3 a b = a + b


Р>FP.add_v1 1 1 |> printfn "%d"

Р>/// Complexity
Р>module OOP =
Р>    type Add(a) =
Р>        class
Р>            member it.Value = a
Р>            member it.Plus(b) = Add((b :> Add).Value + a)
Р>        end

Р>OOP.Add(1).Plus(OOP.Add(1)).Value |> printfn "%d"

Р>


Р>Выше ООП и ФП подход к решению одной задачи.

Р>В чем принципиальное отличие?
Р>На мой взгляд ФП ориентировано на обработку данных,
Р>в то время как ООП старается абстрагировать проблему в некоторую модель,
Р>что делать код намного сложнее в понимании.
Р>Появляется неявный контекст, "за лесом не видно деревьев".

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

То же ядро линукса можно было бы переписать на ООП и сделать код в целом понятнее и кратче, но это повлечет за собой сайд эффекты, которые будут несовместимы с требованиями.
Re[2]: Базовое отличие ООП от ФП
От: Разраб  
Дата: 06.03.24 15:37
Оценка: 8 (1)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Разраб, Вы писали:

Р>>Появляется неявный контекст, "за лесом не видно деревьев".

S>Принципиальное отличие в наличии изменяемого состояния, для которого необходима идентифицируемость (identity).

S>Всё остальное — непринципиально. Если его нет, то объект — это просто набор функций, которые объединены (или не объединены) общим замыканием. Интерфейс становится кортежем функций, а класс — синоним конструктора.
Дело в том, что ООП делает состояние и управление им неявным, взять хотя бы классический WPF, он полагается на магические пропертя и рефлексию.
Но сейчас уже набирает силу ФРП, и оно делает многие вещи более простым способом(еще можно глянуть solidjs)
open Avalonia
open Avalonia.Controls
open Avalonia.Markup.Xaml
open FSharp.Control.Reactive
open Avalonia.Threading

type AppState =
    { Count: int
      EnableTimer: bool }

    static member Zero = { Count = 0; EnableTimer = true }

type MainWindow() as this =
    inherit Window()
    do this.InitializeComponent()

    member private this.InitializeComponent() =
#if DEBUG
        this.AttachDevTools()
#endif
        AvaloniaXamlLoader.Load(this)

        let count = Subject.behavior (AppState.Zero)

        let tb = this.FindControl<TextBlock>("info")
        let btn = this.FindControl<Button>("inc")
        let inc = fun (x: AppState) -> { x with Count = x.Count + 1 }

        btn.Click.Add(fun _ ->
            if count.Value.EnableTimer then
                count.OnNext(
                    { count.Value with
                        Count = count.Value.Count + 1
                        EnableTimer = false }
                )
            else
                count.OnNext(inc count.Value))

        count.Subscribe(fun x -> Dispatcher.UIThread.Invoke(fun _ -> tb.Text <- $"Count: {x.Count}"))
        |> ignore

        task {
            while count.Value.EnableTimer do
                do! Async.Sleep 1000
                count.OnNext(inc count.Value)
        }
        |> ignore
☭ ✊ В мире нет ничего, кроме движущейся материи.
Отредактировано 06.03.2024 15:42 Разраб . Предыдущая версия .
Re[2]: Базовое отличие ООП от ФП
От: viellsky  
Дата: 05.03.24 19:19
Оценка: 4 (1)
Здравствуйте, Serginio1, Вы писали:

S>ООП это прежде всего состояние

Собственно, и всё

S>и сокращения кода за счет наследования и переопределении методов.

Ни при наследовании ни при переопределении код (функций/методов) не сокращается. Сокращается только код, относящийся к состоянию. Т.е. всё отличие как ни крути сводится к появлению состояния и индивидуальных языковых плюшек для упрощения работы с ним.
Re[3]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.03.24 16:23
Оценка: 3 (1)
Здравствуйте, novitk, Вы писали:

S>>ООП ... и сокращения кода за счет наследования и переопределении методов.

S>>Плюс поддержка интерфейсов, замена множественного наследия.

N>В ООП языках представлена очень ограниченная версия — signle param dispatch.

N>В FP языках (Haskell/Scala — type classes, LispCLOS/Julia — multiple params dispatch) без ограничений.

Не знаю, чё це таке, но C# точно ООП язык с примесями ФП. И народ, не переходит на тот же F# раз у него нет ограничений.
Все таки изменяемое состояние в большинстве случаев более выгодно. А переопределение методов и инкапсуляция просто уменьшает количество дополнительного кода.
Хотя без отладчика иногда сложно разобраться в высокоуровневой иерархии.

ФП хорош в рекурсиях, итерациях, где можно лаконично описать процесс
и солнце б утром не вставало, когда бы не было меня
Отредактировано 05.03.2024 16:27 Serginio1 . Предыдущая версия . Еще …
Отредактировано 05.03.2024 16:26 Serginio1 . Предыдущая версия .
Re[4]: Базовое отличие ООП от ФП
От: novitk США  
Дата: 05.03.24 17:06
Оценка: 1 (1)
Здравствуйте, Serginio1, Вы писали:

S>Не знаю, чё це таке, но C# точно ООП язык с примесями ФП. И народ, не переходит на тот же F# раз у него нет ограничений.

В F# ограничения как раз есть. Там полиморфизм такой же как в C# и ОCaml.
Не переходят на него потому же почему и на Скалу — голову придется утруждать, а производительность в разы не поднимется.
Re[5]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.03.24 18:37
Оценка: 1 (1)
Здравствуйте, novitk, Вы писали:

S>>Не знаю, чё це таке, но C# точно ООП язык с примесями ФП. И народ, не переходит на тот же F# раз у него нет ограничений.

N>В F# ограничения как раз есть. Там полиморфизм такой же как в C# и ОCaml.
N>Не переходят на него потому же почему и на Скалу — голову придется утруждать, а производительность в разы не поднимется.
Утруждать то необходимо! Новые нейронные связи образуются. Помню как на Linq плевались.
Жалко, что в одном проекте нельзя 2 языка использовать.
и солнце б утром не вставало, когда бы не было меня
Re[2]: Базовое отличие ООП от ФП
От: novitk США  
Дата: 05.03.24 15:09
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>ООП ... и сокращения кода за счет наследования и переопределении методов.

S>Плюс поддержка интерфейсов, замена множественного наследия.

В ООП языках представлена очень ограниченная версия — signle param dispatch.
В FP языках (Haskell/Scala — type classes, LispCLOS/Julia — multiple params dispatch) без ограничений.
Отредактировано 05.03.2024 15:16 novitk . Предыдущая версия . Еще …
Отредактировано 05.03.2024 15:15 novitk . Предыдущая версия .
Отредактировано 05.03.2024 15:15 novitk . Предыдущая версия .
Re[7]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.03.24 18:49
Оценка: +1
Здравствуйте, novitk, Вы писали:

S>> Жалко, что в одном проекте нельзя 2 языка использовать.

N>зачем? для скорости через unsafe?
Ну для многих вещей хорошо подходит ФП. Я бы с удовольствием использовал F# для того же Рослина ну и просто мозг развлечь.
А так лениво делать в разных проектах.
и солнце б утром не вставало, когда бы не было меня
Re[10]: Базовое отличие ООП от ФП
От: novitk США  
Дата: 06.03.24 16:18
Оценка: +1
Здравствуйте, Разраб, Вы писали:

Именно. Я честно был недавно удивлен на интервью. Контора на дотнете, но для скриптов используют CPython, IronPython типа не развивается.
Я говорю "а что не F#?", ответ какой-то мутный, но я так понял "не осилили".
Re[5]: Базовое отличие ООП от ФП
От: vsb Казахстан  
Дата: 04.04.24 02:52
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

vsb>>Это уже пошла имитация ООП. С одной функцией ещё не так заметно, а если добавить несколько функций (к одному набору данных), то уже видно будет.

S>Да, я показывал.
S>Но "имитировать" классическое ООП, где "реакция" на "сообщение" зависит от предыстории, на честном неизменяемом ФП затруднительно.

Неизменяемость на мой взгляд не является неотъемлемым признаком ФП. Это отдельная концепция. Которая, кстати, в некотором виде стала весьма популярна и в таком языке, как Java, где стали очень часто применять неизменяемые объекты.

ООП на неизменяемом ФП на мой взгляд это что-то вроде Erlang. Где каждый объект это функция, рекурсивно вызывающая сама себя с изменёнными параметрами (имитация цикла событий с мутабельным состоянием) и на каждой итерации принимающая объект и как-то его обрабатывающая (обработка вызова метода).
Re[11]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 10:17
Оценка: -1
Здравствуйте, Pauel, Вы писали:

P>>>Потому и полезно

S>>Не вижу связи. Код-то на этом как писать?

P>Как я понимаю, это позволяет сделать нечто навроде initializer в C#

P>
P>return new User()
P>   .withName('Коля')
P>   .withEmail('коля+2024@гемайл.ком')
P>   .withImage('data:image/png;base64,...')
P>


P>И, поскольку, return m.with... не пролезет, то это вполне себе годное ограничение.

А не проще через конструктор . Ведь readOnly тоже должны быть инициализированы! И конструктор без параметров должен быть запрещен!

Record structs в C#: эффективные и безопасные типы данных
и солнце б утром не вставало, когда бы не было меня
Re[6]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 10:22
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Неизменяемость на мой взгляд не является неотъемлемым признаком ФП. Это отдельная концепция. Которая, кстати, в некотором виде стала весьма популярна и в таком языке, как Java, где стали очень часто применять неизменяемые объекты.


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

Тут есть одна сложность — доказать те или иные свойства пайпалайна в общем случае не представляется возможным. Зато в частном случае, если у вас есть десяток-другой отлаженых комбинаторов, можете использовать такое сколько влезет.
Re[13]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.04.24 11:37
Оценка: +1
Здравствуйте, sergii.p, Вы писали:
SP>например, нам не надо задавать email и картинку. А в конструкторе мы обязаны перечислить все параметры. Их там может быть 20 штук. И мы должны каждый явно указать. Неудобно.
Никто не мешает нам иметь пяток конструкторов для типовых комбинаций начальных параметров. Никто не мешает нам использовать null object pattern для задания параметров, которые не нужны.
Ну и, самое главное — никто не мешает нам делать нормальную реализацию иммутабельных объектов, когда все set-методы возвращают копию объекта.
Это позволяет делать не только многостадийную инициализацию в одну строку, но и описывать произвольные функциональные зависимости.
Например, нетрудно строить всякие конвейеры в стиле
from d in _dates select d.AddDays(17).AddYears(-1);
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 14:24
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

P>>Именно это и есть в моем примере

S>Нет это конструкторы. Ты явно не использовал XAML

Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно

Сам по себе XAML не летает — это просто фронтенд для описания структуры.
А далее готовая структура подаётся в бакенд, который её интерпретирует.

Декларативные свойства обеспечивают не xaml, а тот самый бакенд.
Собственно, вместо XAML вы можете использовать что угодно, абы структура на выходе была такая же.
Вы можете и сейчас это сделать разными путями
1. создавать структуру на основе более внятного ДСЛ, нежели xaml, транслируюя в xaml
2. императивно
3. на основе инциализаторов, которые кривые, что вы и продемонстрировали

То есть, буде в наличии внятные инциализаторы, нет необходимости городить огород из XAML

S>>> Ну а в приведённом тобой коде это экономия на new.


P>>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте


S>bkb

S>
S>Form form = new() {
S>   header: new(content: aaa)
S>   main= new() { 
S>    list new(){
S>      ItemA = new(id= 'a', content= yyy ),
S>      ItemB = new(id= 'a', content= zzz ),
S>   }
S>   },
S>   footer= OkCancelFooter {onOk = onOkHandler, onCancel= onCancelHandler, onDispose= onDisposeHandler}
S>}
S>


Итого — по вашему коду не сильно видна разница между объектами и списками, + шум new()

Кроме того, у вас вероятно ошибка
Вот здесь создаем список у которого два элемента, один с типом ItemA, второй ItemB
[
      ItemA {id: 'a', content: yyy },
      ItemB {id: 'a', content: zzz },
]
Отредактировано 04.04.2024 14:28 Pauel . Предыдущая версия .
Re[22]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.04.24 14:41
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

P>>Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml

S>XAML это в том числе и визуальный редактор. Ты сразу видишь результат, интеллисенс итд.

Такой редактор можно прикрутить к чему угодно — такое понаписывали чуть ли не на все случаи жизни, наверное на всех языках есть
Инициализаторы это json подобный язык — проще просто некуда
У xaml сверх этого нет ни единого преимуществе

Apple вон вовсе выдал SwiftUI — шикарная вещь. Может не самая идеальная, но уж точно лучше xaml

P>>Если во чтото более низкоуровневое — тут слабо верится.

S> Ну вот в то, что ты пишешь вручную без редактора.

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

S>Суть она должна быть удобна для дизайнеров. Но прошло столько лет, а XAML никуда не делся.


Дизайнеры с кодом не работают. Им не до этого — задача дизайнера не xaml выдать, а нарисовать картинки на все случаи жизни, размеры экрана итд.
XAML никуда не делся потому, что его чисто технически нечем заменить
1. в языке нет ничего внятного, что может послужить заменой
2. в рантайме хилые средства, приходится мастырить грабли типа attached property, конвертеры, триггеры итд.

> Для десктопа нужны другие инструменты.


Очень смешно — софта на веб-технологиях появляется всё больше. pva стали нормой. electron прижился. сапр и те потиху идут в веб.
Чисто десктопный софт теперь это узенькая ниша инструментов которые идут вместе с системой.
Базовое отличие ООП от ФП
От: Разраб  
Дата: 05.03.24 02:02
Оценка:

/// Simplicity
module FP =
    let add_v1 = fun a b -> a + b
    let add_v2 = (+)
    let add_v3 a b = a + b


FP.add_v1 1 1 |> printfn "%d"

/// Complexity
module OOP =
    type Add(a) =
        class
            member it.Value = a
            member it.Plus(b) = Add((b :> Add).Value + a)
        end

OOP.Add(1).Plus(OOP.Add(1)).Value |> printfn "%d"


Выше ООП и ФП подход к решению одной задачи.
В чем принципиальное отличие?
На мой взгляд ФП ориентировано на обработку данных,
в то время как ООП старается абстрагировать проблему в некоторую модель,
что делать код намного сложнее в понимании.
Появляется неявный контекст, "за лесом не видно деревьев".
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[6]: Базовое отличие ООП от ФП
От: novitk США  
Дата: 05.03.24 18:45
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Жалко, что в одном проекте нельзя 2 языка использовать.

зачем? для скорости через unsafe?
Re[9]: Базовое отличие ООП от ФП
От: Разраб  
Дата: 06.03.24 15:31
Оценка:
Здравствуйте, novitk, Вы писали:

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


S>> Я бы с удовольствием использовал F# для того же Рослина ну и просто мозг развлечь.

S>>А так лениво делать в разных проектах.
N>Не понимаю use case. Для "того же Рослина" надо работать в MS, а для "просто мозг развлечь" берешь F# interactive и никакие проекты не нужны.
вообще, я недавно отдуплил тему окончательно. главная сила F# скриптов,
не только в самостоятельном использований(но это тоже, особенно
сейчас с ускорением старта дотнетовой тулзы),
но прежде всего при разработке fsproj в vs code + Ionide
Каждый включенный в проект файл модуль (fs)
Отдельно от fsproj создаем fsx
через #r "nuget: Fsharp.Data" добавляем необходимые зависимости.
через #I "Utils.fs" грузим модули проекта,
добавляем отладочный код и отправляем все это в fsi
таким образом разработка идет намного веселей, вместо прыганья по класса,
отлаживаются идеальные программные единицы — функции.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[2]: Базовое отличие ООП от ФП
От: novitk США  
Дата: 06.03.24 16:24
Оценка:
Здравствуйте, diez_p, Вы писали:

_>хотел бы я посмотреть на ФП проект, хотя бы в 200к строк, и не в стиле маяковского, когда каждый чих на новой строке, а с нормальным заполнением.

https://github.com/ghc/ghc
https://github.com/JuliaLang/julia/tree/master/stdlib
https://github.com/scala/scala3
Отредактировано 06.03.2024 16:25 novitk . Предыдущая версия .
Re[3]: Базовое отличие ООП от ФП
От: diez_p  
Дата: 07.03.24 14:38
Оценка:
Здравствуйте, novitk, Вы писали:

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


_>>хотел бы я посмотреть на ФП проект, хотя бы в 200к строк, и не в стиле маяковского, когда каждый чих на новой строке, а с нормальным заполнением.

N>https://github.com/ghc/ghc
N>https://github.com/JuliaLang/julia/tree/master/stdlib
N>https://github.com/scala/scala3

Мельком глянул, и Base.method это похоже на extension методы в шарпах и котлине и сложность становится сопоставимой, весь вопрос в квалификации разраба и условиях в которых это создавалось.
Re[4]: Базовое отличие ООП от ФП
От: novitk США  
Дата: 07.03.24 16:32
Оценка:
Здравствуйте, diez_p, Вы писали:

_>Мельком глянул, и Base.method это похоже на extension методы в шарпах и котлине и сложность становится сопоставимой, весь вопрос в квалификации разраба и условиях в которых это создавалось.


Не совсем. Это разные способы решения https://en.wikipedia.org/wiki/Expression_problem, но конкретно multiple dispatch в Julia (и Lisp/CLOS) сильно шире.
Вот видео про собственно multiple dispatch, расширяет мозги независимо от используемого языка:
https://www.youtube.com/watch?v=kc9HwsxE1OY
Отредактировано 07.03.2024 16:39 novitk . Предыдущая версия . Еще …
Отредактировано 07.03.2024 16:33 novitk . Предыдущая версия .
Re[2]: Базовое отличие ООП от ФП
От: IT Россия linq2db.com
Дата: 07.03.24 19:10
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>ООП это прежде всего состояние


А в структурном программировании разве нет состояния? При чём тут ООП?
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.03.24 20:43
Оценка:
Здравствуйте, IT, Вы писали:

S>>ООП это прежде всего состояние


IT>А в структурном программировании разве нет состояния? При чём тут ООП?


Мне больше нравится понятие Процедурное программирование

О чем я кстати писал http://rsdn.org/forum/philosophy/8706558.1
Автор: Serginio1
Дата: 06.03 10:08
и солнце б утром не вставало, когда бы не было меня
Re[4]: Базовое отличие ООП от ФП
От: IT Россия linq2db.com
Дата: 08.03.24 00:36
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>ООП это прежде всего состояние


IT>>А в процедурном программировании разве нет состояния? При чём тут ООП?
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.03.24 09:52
Оценка:
Здравствуйте, IT, Вы писали:


S>>>>ООП это прежде всего состояние


IT>>>А в процедурном программировании разве нет состояния? При чём тут ООП?


Вопрос звучит так
"Базовое отличие ООП от ФП"
а не
"Базовое отличие Процедурного программировании от ООП"
А различие ПП от ООП я написал здесь
http://rsdn.org/forum/philosophy/8706558.1
Автор: Serginio1
Дата: 06.03 10:08
и солнце б утром не вставало, когда бы не было меня
Re[6]: Базовое отличие ООП от ФП
От: IT Россия linq2db.com
Дата: 08.03.24 18:53
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Вопрос звучит так

S>"Базовое отличие ООП от ФП"
S>а не
S>"Базовое отличие Процедурного программировании от ООП"
S>А различие ПП от ООП я написал здесь
S>http://rsdn.org/forum/philosophy/8706558.1
Автор: Serginio1
Дата: 06.03 10:08


Логично.

- Ваша главная слабость?
— Правильно интерпретирую семантику вопроса, но игнорирую его суть.
— Не могли бы вы привести пример?
— Мог бы⁠⁠.

Если нам не помогут, то мы тоже никого не пощадим.
Отредактировано 08.03.2024 18:54 IT . Предыдущая версия .
Re[7]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.03.24 19:22
Оценка:
Здравствуйте, IT, Вы писали:

S>>Вопрос звучит так

S>>"Базовое отличие ООП от ФП"
S>>а не
S>>"Базовое отличие Процедурного программировании от ООП"
S>>А различие ПП от ООП я написал здесь
S>>http://rsdn.org/forum/philosophy/8706558.1
Автор: Serginio1
Дата: 06.03 10:08


IT>Логично.


IT>

IT>- Ваша главная слабость?
IT>- Правильно интерпретирую семантику вопроса, но игнорирую его суть.
IT>- Не могли бы вы привести пример?
IT>- Мог бы⁠⁠.

То есть IT не читатель. Или уже 8 марта празднуешь?
Все таки прочти http://rsdn.org/forum/philosophy/8706558.1
Автор: Serginio1
Дата: 06.03 10:08
там описано все то, на что ты наезжаешь.
S это Я!

S>>ООП это прежде всего состояние

V>Собственно, и всё

S>>и сокращения кода за счет наследования и переопределении методов.

V>Ни при наследовании ни при переопределении код (функций/методов) не сокращается. Сокращается только код, относящийся к состоянию. Т.е. всё отличие как ни крути сводится к появлению состояния и индивидуальных языковых плюшек для упрощения работы с ним.

Вот помню я программировал на Фортране, Паскале (не Турбо). Там никакого ООП не было. Только процедурное программирование. Но было состояние. Глобальные переменные и переменные функции и параметры.
Которые в огромном количестве передавались из метода в метод.
Что бы не таскать переменные через параметры, решили передавать через ссылку на структуру.
А затем, зачем нам передавать явно, давай прикрутим методы к структуре, а self будем передавать неявно через регистр, прикрутили наследование и VMT, информацию о типе, ну и так далее Получился ООП

и солнце б утром не вставало, когда бы не было меня
Отредактировано 08.03.2024 19:27 Serginio1 . Предыдущая версия . Еще …
Отредактировано 08.03.2024 19:24 Serginio1 . Предыдущая версия .
Re[2]: Базовое отличие ООП от ФП
От: sergii.p  
Дата: 15.03.24 10:48
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Принципиальное отличие в наличии изменяемого состояния, для которого необходима идентифицируемость (identity).


это если мы говорим о сравнении ФП с императивным подходом.
А если сравнивать ООП с ФП, то иммутабельность видимо не является принципиальным отличием. Ведь без изменения состояния можно работать и в ООП парадигме.
Принципиальным отличием, как мне кажется, является то как мы вносим зависимости.

В ООП через интерфейсы:

struct Out { virtual void write(const Data&) const = 0; };

struct Console { virtual void write(const Data&) const { ... }; };

struct File { virtual void write(const Data&) const { ... }; };

void foo(const Data& d, Out& out) {
    out.write(d);
}

void main(){
    const auto console = Console{};
    const auto file = File{};
    const Data d{42};
    foo(d, console);
    foo(d, file);
}


В ФП — через функции:

void write_to_console(const Data& ) { ... }
void write_to_file(const Data& ) { ... }

void foo(const Data& d, auto write) {
    write(d);
}

void main() {
    const auto log = [file = "log.txt"](const Data& d) { write_to_file(file, d); };
    const Data d{42};
    foo(d, log);
    foo(d, write_to_console);
}


Мне даже кажется, что если бы функциональщина появились в языках изначально, ООП так бы и не был внедрён. Он более громоздок, вносит больше вспомогательных абстракций.
Re[3]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.03.24 14:50
Оценка:
Здравствуйте, sergii.p, Вы писали:

SP>А если сравнивать ООП с ФП, то иммутабельность видимо не является принципиальным отличием.

Является.
SP>Ведь без изменения состояния можно работать и в ООП парадигме.
Можно, но тогда от ООП почти ничего не остаётся.
SP>Принципиальным отличием, как мне кажется, является то как мы вносим зависимости.

SP>В ООП через интерфейсы:


SP>
SP>struct Out { virtual void write(const Data&) const = 0; };

SP>struct Console { virtual void write(const Data&) const { ... }; };

SP>struct File { virtual void write(const Data&) const { ... }; };

SP>void foo(const Data& d, Out& out) {
SP>    out.write(d);
SP>}

SP>void main(){
SP>    const auto console = Console{};
SP>    const auto file = File{};
SP>    const Data d{42};
SP>    foo(d, console);
SP>    foo(d, file);
SP>}
SP>

Здесь нет никаких интерфейсов; языки с номинативной типизацией (например, C или C++) просто не скомпилируют этот код. Для того, чтобы в foo можно было передавать Console и File, нам нужно унаследовать их от Out.


SP>В ФП — через функции:


Не обязательно. Вот вы в том, что вы назвали "ООП", просто завернули функции write внутрь структур.
В ФП вы можете сделать примерно то же самое — заверните функцию внутрь структуры:
struct Out { write: (Data) -> void}

То, что в ФП это кажется оверкиллом — ну, так это оттого, что вы выбрали вырожденный интерфейс.
Возьмите в качестве интерфейса что-нибудь поинтереснее — например, пару из NeutralElement и Combine:
public interface IGroup<T>
{
  public T NeutralElement {get;}
  public T Combine(T a, T b)
} 

public class IntAddition: IGroup<int>
{
   public int NeutralElement { get => 0; }
   public int Combine(int a, int b) => a + b;
}

public static class H
{
   public static T Reduce<T>(this IEnumerable<T> input, IGroup<T> group)
   {
      var r = group.NeutralElement;
      foreach(var i in input)
        r = group.Combine(r, i);
      return r;
   }
}

public static class Program
{
   public static void Main()
   {
      var t = new[] {4, 8, 15, 16, 23, 42};
      var sum = t.Reduce(new IntAddition()); 
   }
}


Вот вам ООП подход.
В ФП вместо ООП тут будет не функция, а структура, с точно такой же топологией.
   public static T Reduce(this IEnumerable<T> input, (Func<T> neutralElement, Func<T, T, T> combine))
   {
      var r = group.neutralElement();
      foreach(var i in input)
        r = group.combine(r, i);
      return r;
   }
public static class Program
{
   public static void Main()
   {
      var t = new[] {4, 8, 15, 16, 23, 42};
      var intAddition = (()=>0, (int x, int y)=>x+y);
      var sum = t.Reduce(intAddition); 
   }
}

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

public interface IAccumulator<T>
{
  public T Current{get;}
  public void Accumulate(T value);
} 

public class AddAccumulator: IAccumulator<int>
{
   private _value = 0;
   public int Current{ get => _value; }
   public void Accumulate(int value) => _value += value;
}

public static class H
{
   public static T Reduce<T>(this IEnumerable<T> input, IAccumulator<T> accumulator)
   {
      foreach(var i in input)
        accumulator.Accumulate(i);
      return accumulator.Current;
   }
}

public static class Program
{
   public static void Main()
   {
      var t = new[] {4, 8, 15, 16, 23, 42};
      var sum = t.Reduce(new AddAccumulator()); 
   }
}

Вот для такого кода написать прямой аналог на ФП уже не получится, потому что в каноническом ФП мы не можем менять состояние существующих объектов.
Строгое ФП потребует от нас поменять сигнатуры методов и слегка переколбасить код.
Что-то вроде
public struct record Accumulator<T>(T value, Func<T, Accumulator<T>> accumulate);

public static class H
{
   public static T Reduce<T>(this IEnumerable<T> input, Accumulator accumulator)
   {
      foreach(var i in input)
        accumulator = accumulator.Accumulate(i);
      return accumulator.Current;
   }
   public static Accumulator<T> CreateAccumulator<T>(T value, Func<T, T, T> combine)
     => new Accumulator(value, (T x) => CreateAccumulator(combine(value, x), combine);
}


public static class Program
{
   public static void Main()
   {
      var t = new[] {4, 8, 15, 16, 23, 42};
      var addAccumulator = H.CreateAccumulator(0, (x, y)=> x+y);
      var sum = t.Reduce(addAccumulator); 
   }
}

Вот как раз тут видно, почему ООП без изменяемого состояния — "не ООП".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Базовое отличие ООП от ФП
От: sergii.p  
Дата: 15.03.24 19:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Возьмите в качестве интерфейса что-нибудь поинтереснее — например, пару из NeutralElement и Combine:

S>
S>public interface IGroup<T>
S>{
S>  public T NeutralElement {get;}
S>  public T Combine(T a, T b)
S>} 

S>public class IntAddition: IGroup<int>
S>{
S>   public int NeutralElement { get => 0; }
S>   public int Combine(int a, int b) => a + b;
S>}

S>public static class H
S>{
S>   public static T Reduce<T>(this IEnumerable<T> input, IGroup<T> group)
S>   {
S>      var r = group.NeutralElement;
S>      foreach(var i in input)
S>        r = group.Combine(r, i);
S>      return r;
S>   }
S>}

S>public static class Program
S>{
S>   public static void Main()
S>   {
S>      var t = new[] {4, 8, 15, 16, 23, 42};
S>      var sum = t.Reduce(new IntAddition()); 
S>   }
S>}
S>


S>Вот вам ООП подход.


Замечу, что здесь нет изменяемого состояния.

S>Вот как раз тут видно, почему ООП без изменяемого состояния — "не ООП".


Мне видно противоречие. Ваш вывод для меня неубедителен.
На первый взгляд в ООП инкапсуляция явно противоречит иммутабельности. Но на самом деле это чисто технический момент. Следующий код с изменяемым состоянием

class MyObject {
    int _v;
    public: void setField(int v) { _v = v; }
};


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

class MyObject {
    int _v;
    public: MyObject setField(int v)&& { this->_v = v; return *this; }
}


да, такой код не очень идиоматичен. Но чисто технически он иммутабельность убирает. В языках типа С# и Java конечно такое тяжело (нет move семантики), но начиная с С++ и Rust так извращаться уже можно. В данном случае ограничения языков не должны вводить в заблуждение относительно ограниченности ООП. В ООП стиле можно писать даже иммутабельно
Re[5]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.03.24 10:19
Оценка:
Здравствуйте, sergii.p, Вы писали:

S>>Вот вам ООП подход.


SP>Замечу, что здесь нет изменяемого состояния.

Совершенно верно. Я об этом и говорю — без изменяемого состояния ООП от ФП практически неотличимо. "Интерфейсы" без мутабельности прекрасно реализуются на ФП.

S>>Вот как раз тут видно, почему ООП без изменяемого состояния — "не ООП".

SP>Мне видно противоречие.
Где именно?
SP>На первый взгляд в ООП инкапсуляция явно противоречит иммутабельности. Но на самом деле это чисто технический момент. Следующий код с изменяемым состоянием

SP>
SP>class MyObject {
SP>    int _v;
SP>    public: void setField(int v) { _v = v; }
SP>};
SP>


SP>легко преобразуется в иммутабельный


SP>
SP>class MyObject {
SP>    int _v;
SP>    public: MyObject setField(int v)&& { this->_v = v; return *this; }
SP>}
SP>

Простите, это на каком языке?
SP>да, такой код не очень идиоматичен. Но чисто технически он иммутабельность убирает.
Если я правильно понимаю, вы просто переписали мой пример кода с "иммутабельной мутабельностью" на другой язык. При этом, как мне кажется, вы допустили ошибку — вы же this меняете, нет тут никакой иммутабельности.
Для проверки попробуйте добавить const к определению int _v.

SP>В языках типа С# и Java конечно такое тяжело (нет move семантики),

Не очень понятно, при чём тут move семантика.
SP>но начиная с С++ и Rust так извращаться уже можно. В данном случае ограничения языков не должны вводить в заблуждение относительно ограниченности ООП. В ООП стиле можно писать даже иммутабельно
Такое "ООП" плохо не тем, что оно иммутабельное, а тем, что это — не ООП.
Собственно, как и следовало ожидать, оно с той же громоздкостью выражается на ФП. Потому что — см. предыдущий пункт: в отстутствие изменяемого состояния, "объект" — это просто пачка функций, объединённых общим замыканием.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Базовое отличие ООП от ФП
От: _NN_ www.nemerleweb.com
Дата: 31.03.24 06:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

SP>>легко преобразуется в иммутабельный


SP>>
SP>>class MyObject {
SP>>    int _v;
SP>>    public: MyObject setField(int v)&& { this->_v = v; return *this; }
SP>>}
SP>>

S>Простите, это на каком языке?

C++.
&& означает, что функция может применяться исключительно к временному объекту.

#include <string>
#include <cstdio>

using namespace std;

class MyObject {
    int _v;
    public: MyObject setField(int v)&& { this->_v = v; return *this; }
};

int main() {
    auto m = MyObject().setField(1); // ok

    auto m2 = MyObject();
    m2.setField(1); //  error: 'this' argument to member function 'setField' is an lvalue, but function has rvalue ref-qualifier
}
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[6]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.03.24 09:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

SP>>Замечу, что здесь нет изменяемого состояния.

S>Совершенно верно. Я об этом и говорю — без изменяемого состояния ООП от ФП практически неотличимо. "Интерфейсы" без мутабельности прекрасно реализуются на ФП.

Вы почему то рассматриваете ООП исключительно как ОО + императивное программирование, где искаропки изменяемое состояние.

ОО может подклеиваться к разным парадигмам. Основая вещь это именованное состояние, интерфейс и взаимодействие.

https://rsdn.org/forum/philosophy/7358494.1
Автор: Ikemefula
Дата: 25.01.19


Где то был пример объектно ориентированного логического языка, не могу найти, к сожалению
Re[7]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.04.24 02:23
Оценка:
Здравствуйте, _NN_, Вы писали:
_NN>&& означает, что функция может применяться исключительно к временному объекту.
Спасибо, я так и подумал.
_NN>
_NN>#include <string>
_NN>#include <cstdio>

_NN>using namespace std;

_NN>class MyObject {
_NN>    int _v;
_NN>    public: MyObject setField(int v)&& { this->_v = v; return *this; }
_NN>};

_NN>int main() {
_NN>    auto m = MyObject().setField(1); // ok

_NN>    auto m2 = MyObject();
_NN>    m2.setField(1); //  error: 'this' argument to member function 'setField' is an lvalue, but function has rvalue ref-qualifier
_NN>}
_NN>

А как из этого изготовить хоть что-то полезное?
Например, вот такое тоже не работает:

...
auto m2 = m.setField(2);

А это, собственно, и есть одна из основных конструкция ФП.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.04.24 02:31
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Вы почему то рассматриваете ООП исключительно как ОО + императивное программирование, где искаропки изменяемое состояние.

Отож.

P>ОО может подклеиваться к разным парадигмам. Основая вещь это именованное состояние, интерфейс и взаимодействие.

P>https://rsdn.org/forum/philosophy/7358494.1
Автор: Ikemefula
Дата: 25.01.19

Это верно, но как ни крути, а "ООП без состояния" всё же будет бледной тенью "настоящего ООП".
В приведённой статье этой конструкции соответствует "declarative object", или stateless bundle. Ну, так это собственно и есть неизменяемый tuple, который есть примерно во всех ФП-языках.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Базовое отличие ООП от ФП
От: vsb Казахстан  
Дата: 01.04.24 02:33
Оценка:
ООП это когда данные и функции объединяются в одну сущность.

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

Подходы друг с другом никак не пересекаются и одно другому никак не мешает.
Re[8]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.04.24 18:23
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А как из этого изготовить хоть что-то полезное?


Выглядит как расширение конструктора через fluent interface

S>Например, вот такое тоже не работает:


Потому и полезно
Re[9]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.04.24 09:09
Оценка:
Здравствуйте, Pauel, Вы писали:
P>Потому и полезно
Не вижу связи. Код-то на этом как писать?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.04.24 10:18
Оценка:
Здравствуйте, _NN_, Вы писали:


_NN>C++.

_NN>&& означает, что функция может применяться исключительно к временному объекту.

Вот же извращенцы! И до такого надо ещё додуматься!
А почему не в конструкторе?
и солнце б утром не вставало, когда бы не было меня
Re[8]: Базовое отличие ООП от ФП
От: sergii.p  
Дата: 03.04.24 10:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А как из этого изготовить хоть что-то полезное?


так объект можно сконструировать:

const auto m = MyObject().setField1(1).setField2(2).setField3(3);


Так на основе объекта создать клон с изменённым свойством

const auto anotherObj = m.copy().setField1(10);


А что ещё надо? Ну да, immutable накладывает серьёзные ограничения на создание программ. Поэтому 90% писать на этом не могут и уходят. Но принципиальных препятствий нет. Тот ООП, который мы ненавидим любим, уже не сделаем с такими ограничениями, но то что сделаем меньшим ООП от этого не станет.
И говорить, что immutable является определяющим аттрибутом ФП, как по мне, тоже неправильно. Любая программа написанная в функциональном стиле имеет в глубине изменяемое состояние (те же регистры, вызовы библиотечных функций). Или вот мой любимый пример:

fn main() {
    let strings = vec!["tofu", "93", "18"];
    let (numbers, errors): (Vec<_>, Vec<_>) = strings
        .into_iter()
        .map(|s| s.parse::<i32>())
        .partition(Result::is_ok);
    errors.map(|e| println!("Error: {0}", e););
}


Ну чем не функциональщина? Однако же изменяемое состояние тут есть (println или другая функция логирования). То же кеширование результатов функции является вроде как аттрибутом ФП, но строится на основе изменяемого сотояния (по-другому ну никак).
В общем призываю выделять immutable программирование в отдельную парадигму.
Re[9]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.04.24 11:55
Оценка:
Здравствуйте, sergii.p, Вы писали:

SP>так объект можно сконструировать:

SP>
SP>const auto m = MyObject().setField1(1).setField2(2).setField3(3);
SP>

Простите, но это — чесание правой ногой левого уха. Если у меня заранее известны все нужные мне "поля" и их значения, то в разы удобнее пользоваться специализированным конструктором:
const auto m = MyObject(1, 2, 3);

Fluent-цепочки в основном нужны тогда, когда у меня есть многостадийное конструирование. Например, как-то так:
auto m_temp = MyObject().setField1(1).setField2(2);
const auto m = (conditional_expression) ? m_temp.setField3(17) : m_temp.setField4(42);
return m;


SP>Так на основе объекта создать клон с изменённым свойством


SP>
SP>const auto anotherObj = m.copy().setField1(10);
SP>

Офигеть как удобно! И, к тому же, error: 'const class MyObject' has no member named 'copy'
https://godbolt.org/z/ze57E31v9

SP>А что ещё надо?

Надо, чтобы а) всё работало и б) легко читалось и писалось.


SP>Ну да, immutable накладывает серьёзные ограничения на создание программ.

Не, это не immutable накладывает, а конкретно ваш подход — ужасен.
Даже оставаясь в рамках C++ и подобных ему императивных ОО-языков, иммутабельность можно реализовать значительно менее кошмарным способом.
Для примера можно посмотреть хотя бы на то, как устроены DateTime и TimeSpan в C#.

SP>Поэтому 90% писать на этом не могут и уходят. Но принципиальных препятствий нет. Тот ООП, который мы ненавидим любим, уже не сделаем с такими ограничениями, но то что сделаем меньшим ООП от этого не станет.

Конечно станет. Вы покажите мне пример кода на этом вашем "ООП", который выходит за пределы однострочного примера.
И мы с вами убедимся, что никакого ООП там нет, и что из кода все "объекты" можно безболезненно убрать, заменив их ADT.

SP>И говорить, что immutable является определяющим аттрибутом ФП, как по мне, тоже неправильно. Любая программа написанная в функциональном стиле имеет в глубине изменяемое состояние (те же регистры, вызовы библиотечных функций).

Регистры тут вообще нерелевантны. Современные языки программирования с регистрами не связаны примерно никак. А "вызовы библиотечных функций" обычно наоборот, не "в глубине", а "на поверхности". Чтобы сохранить основной граф вычислений чистым.

SP>Или вот мой любимый пример:


SP>
SP>fn main() {
SP>    let strings = vec!["tofu", "93", "18"];
SP>    let (numbers, errors): (Vec<_>, Vec<_>) = strings
SP>        .into_iter()
SP>        .map(|s| s.parse::<i32>())
SP>        .partition(Result::is_ok);
SP>    errors.map(|e| println!("Error: {0}", e););
SP>}
SP>


SP>Ну чем не функциональщина? Однако же изменяемое состояние тут есть (println или другая функция логирования).

Функциональщина не отказывается от изменяемого состояния. Она просто делает его как можно более явным. Я не знаю, что там по этому поводу думает Rust, но в строгих ФП-языках println — это "особенная" функция, которая помимо своего прямого аргумента принимает "вселенную до" и возвращает "вселенную после".
Кстати, вот в этом коде println — это метод какого объекта? Или это всё же не ООП?

SP>То же кеширование результатов функции является вроде как аттрибутом ФП, но строится на основе изменяемого сотояния (по-другому ну никак).

Нет, кеширование атрибутом ФП не является. Но вот его возможность является прямым следствием ФП.
Memoize можно применять не к любой функции. Например, к println — нельзя.
В идеале, такое ограничение должно выражаться прямо в языке — чтобы memoize(println) давало compile-time error. А не run-time error, и уж тем более не молчаливое неверное поведение.

SP>В общем призываю выделять immutable программирование в отдельную парадигму.

Нет там никакой отдельной парадигмы. Ну, разве что мы назовём отдельной парадигмой SSA-форму.
Но она настолько сурова, что на ней никто не пишет. Удобнее всё же иметь несколько больше возможностей по структурированию кода и данных, чем чистая SSA поверх скаляров.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.04.24 12:05
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>ООП это когда данные и функции объединяются в одну сущность.


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


vsb>Подходы друг с другом никак не пересекаются и одно другому никак не мешает.

Данные и функции можно объединять в одну сущность безо всякого ООП.
Вот простейший пример:

public static Func<int, int> AddX(int x) => (int y)=>y+x; 
public static int Add(int x, int y) => x+y;

public static Func<T2, R> FixX<T1, T2, R>(Func<T1, T2, R> f, T1 x) => (T2 y) => f(x, y);


public static int Main()
{
  var encapsulated = AddX(3); // объединили функцию и значение
  Console.WriteLine(encapsulated(42));
  
  var enc2 = FixX(Add, 5);  // объединили функцию и значение
  Console.WriteLine(enc2(17));
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Базовое отличие ООП от ФП
От: vsb Казахстан  
Дата: 03.04.24 15:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Данные и функции можно объединять в одну сущность безо всякого ООП.


Это уже пошла имитация ООП. С одной функцией ещё не так заметно, а если добавить несколько функций (к одному набору данных), то уже видно будет. Имитировать ФП через интерфейс с одной виртуальной функцией (как это сделано в Java) тоже можно. А на С можно имитировать и то и другое через указатели на функции. Суть в концепции, а не в конкретном механизме реализации.
Отредактировано 03.04.2024 15:39 vsb . Предыдущая версия . Еще …
Отредактировано 03.04.2024 15:39 vsb . Предыдущая версия .
Re[4]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.04.24 16:04
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Это уже пошла имитация ООП. С одной функцией ещё не так заметно, а если добавить несколько функций (к одному набору данных), то уже видно будет.

Да, я показывал.
Но "имитировать" классическое ООП, где "реакция" на "сообщение" зависит от предыстории, на честном неизменяемом ФП затруднительно.
Поэтому ООП — это не столько про "объединение функций и данных", сколько про представление решения в виде объектов, изменяющих своё состояние во времени.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.04.24 17:19
Оценка:
Здравствуйте, Sinclair, Вы писали:
Ну ООП это не только состояние. Но самое главное это наследование полей, свойств методов и их переопределение.
VMT! Интерфейсы! Видимость свойств и методов.
Ref тоже могут быть read only readonly ref

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

Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++
и солнце б утром не вставало, когда бы не было меня
Re[10]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 10:10
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

P>>Потому и полезно
S>Не вижу связи. Код-то на этом как писать?

Как я понимаю, это позволяет сделать нечто навроде initializer в C#
return new User()
   .withName('Коля')
   .withEmail('коля+2024@гемайл.ком')
   .withImage('data:image/png;base64,...')


И, поскольку, return m.with... не пролезет, то это вполне себе годное ограничение.

Это ж C++, тут на всё есть особый пример
Отредактировано 04.04.2024 10:13 Pauel . Предыдущая версия .
Re[12]: Базовое отличие ООП от ФП
От: sergii.p  
Дата: 04.04.24 10:31
Оценка:
Здравствуйте, Serginio1, Вы писали:

P>>
P>>return new User()
P>>   .withName('Коля')
P>>   .withEmail('коля+2024@гемайл.ком')
P>>   .withImage('data:image/png;base64,...')
P>>


S> А не проще через конструктор . Ведь readOnly тоже должны быть инициализированы! И конструктор без параметров должен быть запрещен!


например, нам не надо задавать email и картинку. А в конструкторе мы обязаны перечислить все параметры. Их там может быть 20 штук. И мы должны каждый явно указать. Неудобно.
Re[13]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 10:38
Оценка:
Здравствуйте, Pauel, Вы писали:

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


P>>>И, поскольку, return m.with... не пролезет, то это вполне себе годное ограничение.

S>> А не проще через конструктор . Ведь readOnly тоже должны быть инициализированы! И конструктор без параметров должен быть запрещен!

P>При чем здесь проще? Речь о том, для чего можно использовать заявленную фичу.


P>Если выбирали такой дизайн по какой причине, то очевидно что readonly и запрет такого конструктора сюда не входит.

Выбирали такой дизайн криворукие дизайнеры. В шарпе сделали правильно.
и солнце б утром не вставало, когда бы не было меня
Re[13]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 10:44
Оценка:
Здравствуйте, sergii.p, Вы писали:

P>>>
P>>>return new User()
P>>>   .withName('Коля')
P>>>   .withEmail('коля+2024@гемайл.ком')
P>>>   .withImage('data:image/png;base64,...')
P>>>


S>> А не проще через конструктор . Ведь readOnly тоже должны быть инициализированы! И конструктор без параметров должен быть запрещен!


SP>например, нам не надо задавать email и картинку. А в конструкторе мы обязаны перечислить все параметры. Их там может быть 20 штук. И мы должны каждый явно указать. Неудобно.


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

Именованные и необязательные аргументы (Руководство по программированию на C#)

public void ExampleMethod(int required, string optionalstr = "default string",
    int optionalint = 10)

[q]
Если вы знаете имя третьего параметра, можете использовать для выполнения задачи именованный аргумент.


anExample.ExampleMethod(3, optionalint: 4);


Плюс такого подхода ты знаешь значения по умолчанию!
и солнце б утром не вставало, когда бы не было меня
Отредактировано 04.04.2024 11:03 Serginio1 . Предыдущая версия . Еще …
Отредактировано 04.04.2024 10:46 Serginio1 . Предыдущая версия .
Re[11]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.04.24 10:58
Оценка:
Здравствуйте, Pauel, Вы писали:
P>Как я понимаю, это позволяет сделать нечто навроде initializer в C#
P>
P>return new User()
P>   .withName('Коля')
P>   .withEmail('коля+2024@гемайл.ком')
P>   .withImage('data:image/png;base64,...')
P>

Это решаает какую-то проблему, которой нет.
P>Это ж C++, тут на всё есть особый пример
Ну, тогда хотелось бы релевантных примеров. Обещали показать immutable OOP, а показали какую-то убогую многостадийную инициализацию иммутабельных объектов.
Можно взять какую-то реалистичную задачу, для которой ООП подходит хорошо. Ну, там, реализацию оконного интерфейса.
Чтобы при включении checkbox1 у нас editbox1 становился enabled, а при выключении — disabled.
На ООП это работает отлично, хоть в наивной форме, хоть в продвинутых архитектурах вроде MVC/MVP/MVVM.
Как это устроено на ФП, я тоже отдалённо представляю.
А вот как это будет устроено на "иммутабельном ООП", хотелось бы посмотреть.
Ну, то есть у меня, конечно же, есть некоторые представления о том, как бы это выглядело; но они крайне далеки от конкретно этой реализации с &&.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 12:40
Оценка:
Здравствуйте, Serginio1, Вы писали:

P>>Если выбирали такой дизайн по какой причине, то очевидно что readonly и запрет такого конструктора сюда не входит.

S> Выбирали такой дизайн криворукие дизайнеры. В шарпе сделали правильно.

Что вы предлагаете, переписать с С++ на C# ради инициализаторов?

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

Form {
   header: {content: aaa} 
   main: { 
     list: [
      ItemA {id: 'a', content: yyy },
      ItemB {id: 'a', content: zzz },
    ]
   },
   footer: OkCancelFooter {onOk: onOkHandler, onCancel: onCancelHandler, onDispose: onDisposeHandler}
}


Глядишь, с таким инициализатором не пришлось бы городить огород типа XAML
Re[14]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 12:51
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Никто не мешает нам иметь пяток конструкторов для типовых комбинаций начальных параметров. Никто не мешает нам использовать null object pattern для задания параметров, которые не нужны.


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

Множественные перегрузки конструкторов или методов — это разве что в ДСЛ сгодится, а так лучше без всего этого обходиться.

S>Ну и, самое главное — никто не мешает нам делать нормальную реализацию иммутабельных объектов, когда все set-методы возвращают копию объекта.


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

Если у вас есть промежутки, где гц может включиться, то это не проблема. Но вот всякие переинициализации в синхронном коде, да еще в цикле — у вас на ровном месте будет вылазить конское поглощение памяти. Подкинули 10 филдов, внезапно, это 10 клонов всей вашей кунсткамеры.
Для плоских объектов это еще куда ни шло. А если у вас на таком месте задается структура типа DOM, то вы ошалеете с такой иммутабельностью.
Re[12]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 13:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А вот как это будет устроено на "иммутабельном ООП", хотелось бы посмотреть.

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

В иммутабельном OOP это будет примерно так же, как делают лет 10 во фронтенде — redux + react.

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

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

Повторить такой фокус для классических winforms точно не выйдет , и для xaml сильно вряд ли выйдет — эти вещи никогда не проектировались под подобное использование.
Re[15]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 13:34
Оценка:
Здравствуйте, Pauel, Вы писали:

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


P>>>Если выбирали такой дизайн по какой причине, то очевидно что readonly и запрет такого конструктора сюда не входит.

S>> Выбирали такой дизайн криворукие дизайнеры. В шарпе сделали правильно.

P>Что вы предлагаете, переписать с С++ на C# ради инициализаторов?


Нет про конструкторы

Именованные и необязательные аргументы (Руководство по программированию на C#)

P>Тамошние инициализаторы, кстати говоря, довольно убогие.

P>Я бы предпочел инициализатор навроде такого

P>
P>Form {
P>   header: {content: aaa} 
P>   main: { 
P>     list: [
P>      ItemA {id: 'a', content: yyy },
P>      ItemB {id: 'a', content: zzz },
P>    ]
P>   },
P>   footer: OkCancelFooter {onOk: onOkHandler, onCancel: onCancelHandler, onDispose: onDisposeHandler}
P>} 
P>


P>Глядишь, с таким инициализатором не пришлось бы городить огород типа XAML


XAML это про декларативность. То есть за строкой скрывается куча кода.

Ну а в приведённом тобой коде это экономия на new.
и солнце б утром не вставало, когда бы не было меня
Re[15]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.04.24 13:35
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Пять конструкторов — это значит, что скорее всего в итоге невнятная документация и в коде будет мешанина, т.к. кто нибудь передаст null не туда.

P>Множественные перегрузки конструкторов или методов — это разве что в ДСЛ сгодится, а так лучше без всего этого обходиться.
Это, скажем так, смелое утверждение.
Давайте возьмём более-менее любую популярную библиотеку и посмотрим, сколько конструкторов у привычных нам объектов.
Например, какой-нибудь FileStream. Или тот же DateTime.

S>>Ну и, самое главное — никто не мешает нам делать нормальную реализацию иммутабельных объектов, когда все set-методы возвращают копию объекта.

P>мешает — гц. Всё таки дохловат в дотнете гц. Если плодить на каждый чих временные объекты, вы очень быстро раздуваете нулевое поколение и выходите за его пределы.
Во-первых, речь шла не о дотнете, а о C++. Современные компиляторы C++ прекрасно устраняют лишние копирования в цепочках вроде m2 = m1.setField1(17).setField2(42).
Во-вторых, в дотнете иммутабельность прекрасно дружит с value-типами. Где джит тоже устраняет лишние копирования в цепочках модификаций.
P>Если у вас есть промежутки, где гц может включиться, то это не проблема. Но вот всякие переинициализации в синхронном коде, да еще в цикле — у вас на ровном месте будет вылазить конское поглощение памяти. Подкинули 10 филдов, внезапно, это 10 клонов всей вашей кунсткамеры.
P>Для плоских объектов это еще куда ни шло. А если у вас на таком месте задается структура типа DOM, то вы ошалеете с такой иммутабельностью.
В-третьих, для того и делаются перегрузки конструкторов — чтобы избегать цепочек бессмысленных копирований в среде, где нет escape analysis.
А в-четвёртых, если вы хотите посмотреть на приложение, в котором на таком месте задаётся структура типа DOM, то запустите Visual Studio.
Там весь редактор кода — это иммутабельное дерево поверх иммутабельного дерева.
И все инспекторы и codefix-провайдеры работают с этим иммутабельным деревом именно через всякие root.ReplaceNode(classDeclaration, classDeclaration.AddModifiers(items)).
Вполне себе всё это шустро работает, и GC им не мешает .
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 13:43
Оценка:
Здравствуйте, Serginio1, Вы писали:

P>>Тамошние инициализаторы, кстати говоря, довольно убогие.

P>>Я бы предпочел инициализатор навроде такого

P>>
P>>Form {
P>>   header: {content: aaa} 
P>>   main: { 
P>>     list: [
P>>      ItemA {id: 'a', content: yyy },
P>>      ItemB {id: 'a', content: zzz },
P>>    ]
P>>   },
P>>   footer: OkCancelFooter {onOk: onOkHandler, onCancel: onCancelHandler, onDispose: onDisposeHandler}
P>>} 
P>>


P>>Глядишь, с таким инициализатором не пришлось бы городить огород типа XAML


S> XAML это про декларативность. То есть за строкой скрывается куча кода.


Именно это и есть в моем примере

S> Ну а в приведённом тобой коде это экономия на new.


Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте
Re[17]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 13:59
Оценка:
Здравствуйте, Pauel, Вы писали:

S>> XAML это про декларативность. То есть за строкой скрывается куча кода.


P>Именно это и есть в моем примере

Нет это конструкторы. Ты явно не использовал XAML
S>> Ну а в приведённом тобой коде это экономия на new.

P>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте


Form form = new() {
   header: new() {content: aaa} 
   main= new() { 
    list new(){
      ItemA = new() {id= 'a', content= yyy },
      ItemB = new() {id= 'a', content= zzz },
   }
   },
   footer= OkCancelFooter {onOk= onOkHandler, onCancel= onCancelHandler, onDispose= onDisposeHandler}
}


ил если есть конструкторы (object content)
Form form = new() {
   header: new(content: aaa)
   main= new() { 
    list new(){
      ItemA = new(id: 'a', content: yyy ),
      ItemB = new(id: 'a', content: zzz ),
   }
   },
   footer= OkCancelFooter {onOk = onOkHandler, onCancel= onCancelHandler, onDispose= onDisposeHandler}
}
и солнце б утром не вставало, когда бы не было меня
Отредактировано 04.04.2024 14:13 Serginio1 . Предыдущая версия . Еще …
Отредактировано 04.04.2024 14:12 Serginio1 . Предыдущая версия .
Отредактировано 04.04.2024 14:06 Serginio1 . Предыдущая версия .
Re[16]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 14:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Давайте возьмём более-менее любую популярную библиотеку и посмотрим, сколько конструкторов у привычных нам объектов.

S>Например, какой-нибудь FileStream. Или тот же DateTime.

DateTime плохой пример. DateTimeOffset — 8 конструкторов. Я в свое время задолбался писать конформанс тесты под один из сервисов на дотнете и джаве — у них вечно были ошибки с рендерингом выхлопа с датами.
Визуально, по коду, разницы между двумя вариантами почти что нет — код ревью не работает. А покрыть тестами все нюансы со временем мягко говоря задача не маленькая.

S>А в-четвёртых, если вы хотите посмотреть на приложение, в котором на таком месте задаётся структура типа DOM, то запустите Visual Studio.

S>Там весь редактор кода — это иммутабельное дерево поверх иммутабельного дерева.
S>И все инспекторы и codefix-провайдеры работают с этим иммутабельным деревом именно через всякие root.ReplaceNode(classDeclaration, classDeclaration.AddModifiers(items)).
S>Вполне себе всё это шустро работает, и GC им не мешает .

Подозреваю, они напилили там целую кучу оптимизаций под гц, что бы не было лишних переаллокаций. В 00х у них было полно проблем с перформансом, память могла уходить гигабайтами на ровном месте. Потом вероятно привели всё в порядок.
Re[19]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 15:05
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Именно это и есть в моем примере

S>>Нет это конструкторы. Ты явно не использовал XAML

P>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно

Там есть конвертеры, тригеры итд.
Я шарпом занимаюсь с 2002 года. И сначала XAML у меня вызвал отвращение.
Да я и не особо дизайнер.

P>Сам по себе XAML не летает — это просто фронтенд для описания структуры.

P>А далее готовая структура подаётся в бакенд, который её интерпретирует.

Ну вообще то он компилируется Компиляция XAML

P>Декларативные свойства обеспечивают не xaml, а тот самый бакенд.

P>Собственно, вместо XAML вы можете использовать что угодно, абы структура на выходе была такая же.
P>Вы можете и сейчас это сделать разными путями
P>1. создавать структуру на основе более внятного ДСЛ, нежели xaml, транслируюя в xaml
P>2. императивно
P>3. на основе инциализаторов, которые кривые, что вы и продемонстрировали

P>То есть, буде в наличии внятные инциализаторы, нет необходимости городить огород из XAML

Я так же программно иногда делаю.
Но это от лени. Я не так часто его использую.

S>>>> Ну а в приведённом тобой коде это экономия на new.


P>>>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте


S>>bkb

S>>
S>>Form form = new() {
S>>   header: new(content: aaa)
S>>   main= new() { 
S>>    list new(){
S>>      ItemA = new(id= 'a', content= yyy ),
S>>      ItemB = new(id= 'a', content= zzz ),
S>>   }
S>>   },
S>>   footer= OkCancelFooter {onOk = onOkHandler, onCancel= onCancelHandler, onDispose= onDisposeHandler}
S>>}
S>>


P>Итого — по вашему коду не сильно видна разница между объектами и списками, + шум new()

Ну можно
 list = new List<object>

а new кому то шум, а кому то явное определение

P>Кроме того, у вас вероятно ошибка

P>Вот здесь создаем список у которого два элемента, один с типом ItemA, второй ItemB
P>
P>[
P>      ItemA {id: 'a', content: yyy },
P>      ItemB {id: 'a', content: zzz },
P>]
P>


ну значит будет
      new ItemA() {id= 'a', content= yyy },
      new ItemB() {id= 'a', content= zzz },


или если есть конструктор с параметрами id и content

      new ItemA(id: 'a', content: yyy),
      new ItemB(id: 'a', content: zzz ),


Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть.
Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов
и солнце б утром не вставало, когда бы не было меня
Re[20]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 15:42
Оценка:
Здравствуйте, Serginio1, Вы писали:

P>>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно

S>Там есть конвертеры, тригеры итд.

Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml

P>>Сам по себе XAML не летает — это просто фронтенд для описания структуры.

P>>А далее готовая структура подаётся в бакенд, который её интерпретирует.

S> Ну вообще то он компилируется Компиляция XAML


И что с того? Это всё равно описание структуры. Всю работу делает бакенд.
Во что именно xaml компилируется, в вызовы типа "parent.addElement(...)" ? Если так, то никаких преимуществ перед инициализаторами нет.
Если во чтото более низкоуровневое — тут слабо верится.

S> Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть.

S>Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов

Подозреваю, в микрософте была идея, что над кодом будут работать дизайнеры и программисты
А прогресс пошел по другому пути — начали плодиться разрешения от 320x200 до 8K, десятками тысяч и дизайнерам уже было не до кода — успеть бы картинок нарисовать.
Лайоут типа респонзив итд у микрософта был непредусмотрен, соответсвенно видение микрософта умерло вместе с ихними инструментами для рисования ui.

Для ui разработчиков нужно максимальное разделение концепций — отделить даные, лайоут, стили, рендеринг и поведение.

То есть вот такой стек у нас выходит
1 данные
2 семантический рендеринг
3 стили
4 лайоут, композиция
5 реакция и поведение

технически 4 и 3 делают одним и тем же инструментом, но реально это трохи разные вещи. стили это look & feel, layout это взаимодействие элементов

У микрософта 2, 3 и 4 это Винигрет, до кучи многословный

Вещи из п1-5 могут деливериться каждый по отдельности, буквально. До момента деплоя вы можете никогда не видеть вон те стили и вон тот лайоут на тех данных с таким вот поведением.

Почему так произошло — потому что спрос на фронтенд всё время растет, фронтенд становится сложнее с т.з. требований. А раз растет сложность требований, то очевидно и внутренняя структура будет меняться точно так же — будет усложняться.
Re[21]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 17:04
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно

S>>Там есть конвертеры, тригеры итд.

P>Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml

XAML это в том числе и визуальный редактор. Ты сразу видишь результат, интеллисенс итд.

P>>>Сам по себе XAML не летает — это просто фронтенд для описания структуры.

P>>>А далее готовая структура подаётся в бакенд, который её интерпретирует.

S>> Ну вообще то он компилируется Компиляция XAML


P>И что с того? Это всё равно описание структуры. Всю работу делает бакенд.

P>Во что именно xaml компилируется, в вызовы типа "parent.addElement(...)" ? Если так, то никаких преимуществ перед инициализаторами нет.
P>Если во чтото более низкоуровневое — тут слабо верится.
Ну вот в то, что ты пишешь вручную без редактора.

S>> Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть.

S>>Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов

P>Подозреваю, в микрософте была идея, что над кодом будут работать дизайнеры и программисты

P>А прогресс пошел по другому пути — начали плодиться разрешения от 320x200 до 8K, десятками тысяч и дизайнерам уже было не до кода — успеть бы картинок нарисовать.
P>Лайоут типа респонзив итд у микрософта был непредусмотрен, соответсвенно видение микрософта умерло вместе с ихними инструментами для рисования ui.

P>Для ui разработчиков нужно максимальное разделение концепций — отделить даные, лайоут, стили, рендеринг и поведение.


P>То есть вот такой стек у нас выходит

P>1 данные
P>2 семантический рендеринг
P>3 стили
P>4 лайоут, композиция
P>5 реакция и поведение

P>технически 4 и 3 делают одним и тем же инструментом, но реально это трохи разные вещи. стили это look & feel, layout это взаимодействие элементов


P>У микрософта 2, 3 и 4 это Винигрет, до кучи многословный


P>Вещи из п1-5 могут деливериться каждый по отдельности, буквально. До момента деплоя вы можете никогда не видеть вон те стили и вон тот лайоут на тех данных с таким вот поведением.


P>Почему так произошло — потому что спрос на фронтенд всё время растет, фронтенд становится сложнее с т.з. требований. А раз растет сложность требований, то очевидно и внутренняя структура будет меняться точно так же — будет усложняться.


Фронтэнд это для браузеров. Для десктопа нужны другие инструменты.

Но, что я не вижу особо альтернатив. Может XAML заменить на YAML.
Суть она должна быть удобна для дизайнеров. Но прошло столько лет, а XAML никуда не делся.
Тот же MAUI на XAML
и солнце б утром не вставало, когда бы не было меня
Re[8]: Базовое отличие ООП от ФП
От: _NN_ www.nemerleweb.com
Дата: 28.04.24 12:53
Оценка:
Здравствуйте, Serginio1, Вы писали:

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



_NN>>C++.

_NN>>&& означает, что функция может применяться исключительно к временному объекту.

S> Вот же извращенцы! И до такого надо ещё додуматься!

S>А почему не в конструкторе?

В чём собственно вопрос ?
C++ позволяет гибко указать когда функция может применяться к объекту:

https://gcc.godbolt.org/z/jTescMb8K
struct A {
    void non_const() { }

    void const_() const { }

    void ref() & { }
    
    void rvalue_ref() && { }

    void ref_const() const & { }

    void rvalue_ref_const() const && { }
};

int main()
{
    // ------
    // lvalue
    A lvalue;
    
    lvalue.non_const();
    lvalue.const_();
    lvalue.ref();
    // lvalue.rvalue_ref(); // Error
    lvalue.ref_const();
    //lvalue.rvalue_ref_const(); // Error

    // -----
    // const lvalue
    const A const_lvalue;
    
    // const_lvalue.non_const(); // Error
    const_lvalue.const_();
    // const_lvalue.ref(); // Error
    // const_lvalue.rvalue_ref(); // Error
    const_lvalue.ref_const();
    // const_lvalue.rvalue_ref_const(); // Error

    // -----
    // rvalue
    A().non_const();
    A().const_();
    // A().ref(); // Error
    A().rvalue_ref();
    A().ref_const();
    A().rvalue_ref_const(); // Error

    // -----
    A&& rvalue = A();

    rvalue.non_const();
    rvalue.const_();
    rvalue.ref();
    // rvalue.rvalue_ref(); // Error
    rvalue.ref_const();
    // rvalue.rvalue_ref_const(); // Error   

    // -----
    const A&& const_rvalue = A();

    // const_rvalue.non_const(); // Error
    const_rvalue.const_();
    // const_rvalue.ref(); // Error
    // const_rvalue.rvalue_ref(); // Error
    const_rvalue.ref_const();
    // const_rvalue.rvalue_ref_const(); // Error   
}


Ну и для упрощения однотипных функций ввели Deducing this.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[8]: Базовое отличие ООП от ФП
От: _NN_ www.nemerleweb.com
Дата: 28.04.24 12:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А как из этого изготовить хоть что-то полезное?

S>Например, вот такое тоже не работает:

S>
S>...
S>auto m2 = m.setField(2);
S>

S>А это, собственно, и есть одна из основных конструкция ФП.

Никак. В прочем об этом уже и написали.

Чтобы работало m.setField нужны перегрузки для lvalue '&', что подводит нас просто к паттерну Builder или к конструктору если нужна неизменяемость.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[3]: Базовое отличие ООП от ФП
От: Ночной Смотрящий Россия  
Дата: 29.04.24 09:25
Оценка:
Здравствуйте, novitk, Вы писали:

N>https://github.com/ghc/ghc

N>https://github.com/JuliaLang/julia/tree/master/stdlib
N>https://github.com/scala/scala3

Компиляторы — крайне фиговый пример, потому что специфика в полный рост, причем специфика такая, что нигде больше в больших объемах не встречается.
А так да, на компиляторах ФП максимально демонстрирует свои преимущества. А вот если брать мейнстримовый мейнстрим, то на тех же задачках из области CRUD (и в целом на задачах, в которых несколько моделей с преобразованиями) все становится совсем не очевидным.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Базовое отличие ООП от ФП
От: Ночной Смотрящий Россия  
Дата: 29.04.24 09:29
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>ООП это когда данные и функции объединяются в одну сущность.


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

vsb>Подходы друг с другом никак не пересекаются и одно другому никак не мешает.


Некоторое пересечение все же есть, хотя бы потому что для одной задачи обычно существует как функциональное, так и ООП решение.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.04.24 11:43
Оценка:
Здравствуйте, _NN_, Вы писали:

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


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



_NN>>>C++.

_NN>>>&& означает, что функция может применяться исключительно к временному объекту.

S>> Вот же извращенцы! И до такого надо ещё додуматься!

S>>А почему не в конструкторе?

_NN>В чём собственно вопрос ?

_NN>C++ позволяет гибко указать когда функция может применяться к объекту:

https://rsdn.org/forum/philosophy/8725074.1
Автор: Serginio1
Дата: 04.04 13:44

Именованные и необязательные аргументы (Руководство по программированию на C#)


Есть Записи (справочник по C#)
В том числе with
и солнце б утром не вставало, когда бы не было меня
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.