/// 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"
Выше ООП и ФП подход к решению одной задачи.
В чем принципиальное отличие?
На мой взгляд ФП ориентировано на обработку данных,
в то время как ООП старается абстрагировать проблему в некоторую модель,
что делать код намного сложнее в понимании.
Появляется неявный контекст, "за лесом не видно деревьев".
Здравствуйте, Разраб, Вы писали: Р>Появляется неявный контекст, "за лесом не видно деревьев".
Принципиальное отличие в наличии изменяемого состояния, для которого необходима идентифицируемость (identity).
Всё остальное — непринципиально. Если его нет, то объект — это просто набор функций, которые объединены (или не объединены) общим замыканием. Интерфейс становится кортежем функций, а класс — синоним конструктора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Разраб, Вы писали:
Р>Выше ООП и ФП подход к решению одной задачи.
В твоем примере нет ООП.
Одного наличия слова class и вызова через точку недостаточно чтобы код стал ООП.
ООП это прежде всего состояние и сокращения кода за счет наследования и переопределении методов.
Плюс поддержка интерфейсов, замена множественного наследия.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>ООП ... и сокращения кода за счет наследования и переопределении методов. S>Плюс поддержка интерфейсов, замена множественного наследия.
В ООП языках представлена очень ограниченная версия — signle param dispatch.
В FP языках (Haskell/Scala — type classes, LispCLOS/Julia — multiple params dispatch) без ограничений.
Здравствуйте, novitk, Вы писали:
S>>ООП ... и сокращения кода за счет наследования и переопределении методов. S>>Плюс поддержка интерфейсов, замена множественного наследия.
N>В ООП языках представлена очень ограниченная версия — signle param dispatch. N>В FP языках (Haskell/Scala — type classes, LispCLOS/Julia — multiple params dispatch) без ограничений.
Не знаю, чё це таке, но C# точно ООП язык с примесями ФП. И народ, не переходит на тот же F# раз у него нет ограничений.
Все таки изменяемое состояние в большинстве случаев более выгодно. А переопределение методов и инкапсуляция просто уменьшает количество дополнительного кода.
Хотя без отладчика иногда сложно разобраться в высокоуровневой иерархии.
ФП хорош в рекурсиях, итерациях, где можно лаконично описать процесс
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Не знаю, чё це таке, но C# точно ООП язык с примесями ФП. И народ, не переходит на тот же F# раз у него нет ограничений.
В F# ограничения как раз есть. Там полиморфизм такой же как в C# и ОCaml.
Не переходят на него потому же почему и на Скалу — голову придется утруждать, а производительность в разы не поднимется.
Здравствуйте, novitk, Вы писали:
S>>Не знаю, чё це таке, но C# точно ООП язык с примесями ФП. И народ, не переходит на тот же F# раз у него нет ограничений. N>В F# ограничения как раз есть. Там полиморфизм такой же как в C# и ОCaml. N>Не переходят на него потому же почему и на Скалу — голову придется утруждать, а производительность в разы не поднимется.
Утруждать то необходимо! Новые нейронные связи образуются. Помню как на Linq плевались.
Жалко, что в одном проекте нельзя 2 языка использовать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, novitk, Вы писали:
S>> Жалко, что в одном проекте нельзя 2 языка использовать. N>зачем? для скорости через unsafe?
Ну для многих вещей хорошо подходит ФП. Я бы с удовольствием использовал F# для того же Рослина ну и просто мозг развлечь.
А так лениво делать в разных проектах.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Я бы с удовольствием использовал F# для того же Рослина ну и просто мозг развлечь. S>А так лениво делать в разных проектах.
Не понимаю use case. Для "того же Рослина" надо работать в MS, а для "просто мозг развлечь" берешь F# interactive и никакие проекты не нужны.
Здравствуйте, Serginio1, Вы писали:
S>ООП это прежде всего состояние
Собственно, и всё
S>и сокращения кода за счет наследования и переопределении методов.
Ни при наследовании ни при переопределении код (функций/методов) не сокращается. Сокращается только код, относящийся к состоянию. Т.е. всё отличие как ни крути сводится к появлению состояния и индивидуальных языковых плюшек для упрощения работы с ним.
S>>ООП это прежде всего состояние V>Собственно, и всё
S>>и сокращения кода за счет наследования и переопределении методов. V>Ни при наследовании ни при переопределении код (функций/методов) не сокращается. Сокращается только код, относящийся к состоянию. Т.е. всё отличие как ни крути сводится к появлению состояния и индивидуальных языковых плюшек для упрощения работы с ним.
Вот помню я программировал на Фортране, Паскале (не Турбо). Там никакого ООП не было. Только процедурное программирование. Но было состояние. Глобальные переменные и переменные функции и параметры.
Которые в огромном количестве передавались из метода в метод.
Что бы не таскать переменные через параметры, решили передавать через ссылку на структуру.
А затем, зачем нам передавать явно, давай прикрутим методы к структуре, а self будем передавать неявно через регистр, прикрутили наследование и VMT, информацию о типе, ну и так далее Получился ООП
и солнце б утром не вставало, когда бы не было меня
Р>/// 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к строк, и не в стиле маяковского, когда каждый чих на новой строке, а с нормальным заполнением.
То же ядро линукса можно было бы переписать на ООП и сделать код в целом понятнее и кратче, но это повлечет за собой сайд эффекты, которые будут несовместимы с требованиями.
Здравствуйте, 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
таким образом разработка идет намного веселей, вместо прыганья по класса,
отлаживаются идеальные программные единицы — функции.
Здравствуйте, 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
Именно. Я честно был недавно удивлен на интервью. Контора на дотнете, но для скриптов используют CPython, IronPython типа не развивается.
Я говорю "а что не F#?", ответ какой-то мутный, но я так понял "не осилили".
Мельком глянул, и Base.method это похоже на extension методы в шарпах и котлине и сложность становится сопоставимой, весь вопрос в квалификации разраба и условиях в которых это создавалось.
Здравствуйте, diez_p, Вы писали:
_>Мельком глянул, и Base.method это похоже на extension методы в шарпах и котлине и сложность становится сопоставимой, весь вопрос в квалификации разраба и условиях в которых это создавалось.
