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

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

AA>>Думаю, стоит поискать ответы в книге "Чистая архитектура" Р.М.

S>Увы, это не ответ. Сложилось впечатление, что Вы не совсем понимаете о чем говорите.

Нет, просто иногда устаешь, и нет времени объяснять. Это не троллинг.

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

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

I>>>Инкапсуляция решает вполне конкретные задачи. Нет таких задач — не надо за неё и держаться. Самое главное в ООП это структуризация решения сложной задачи, и, как следствие, организация взаимодействия.

AA>>Вообще, будущее все равно за ФП. Почему? ООП — это моделирование поведения объектов.
AA>>ФП — это функция. Вычисление которой есть результат. ЭВМ это калькулятор. Поэтому ФП ближе по природе к программированию нежели ООП.

ltc>И доколе человек будет ломать мозг, чтобы писать на языке, более близком и понятном компьютеру, а не наоборот?

ФП — это чистая математика. Со времен Пифагора. Почему математическая запись не близка человеку?

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

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

AA>> 1. оператор goto — усложняет понимание логики.

DC>Смотря как его применять.
404

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


ARK>Нет никаких преимуществ в том, что АлгТД весь в одном файле. Его преимущество — исчерпывающий match. И вытекающий отсюда же недостаток — нерасширяемость при необходимости. Всё это известно под названием expression problem.

Помимо состояния(описываемого int-ом в сишарпе) в АТД(DU) мы еще передаем данные.

ARK>ФП или ООП — вообще ортогонально данному вопросу.
Совсем нет.
ФП — типы данных и функции это отдельные сущности.
в ООП — классы(типы данных) организационно(концептуально) связаны с функциями для работы с этим данными.
Это заставляет плодить состояние внутри классов.
Когда типы данных лишены поведения они автоматически избавляют нас от необходимости следить за консистецией данных.

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

ARK>>Идеологически алгебраический тип данных — это один тип, никаких подтипов в нем нет (хотя внутри можно реализовывать и классами, разумеется). Это "расширенный енум". И его конструкторы — это аналог членов енума, а не типов.
AA>

AA>enum X {
AA> A
AA>}
AA>void Method(X x)
AA>{
AA>}
AA>Method(10);
AA>

AA>Спокойно скомпилится.

Правда?

https://ideone.com/pQlsqB

using System;

enum X { A }

public class Test
{
    static void Method(X x)
    {
    }

    public static void Main()
    {
        Method(10);
    }
}

prog.cs(13,10): error CS1503: Argument `#1' cannot convert `int' expression to type `X'

Вот это поворот.


UPD. А, вижу, ты подредактировал уже с приведением типов. Так скомпилится, да. Но что это доказывает или опровергает?


AA>Попробуй тоже самое с АТД и скажи что это одно и тоже.

Это не одно и то же. Это сходные концепции. Только вот наследование к ним не имеет никакого отношения.

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

ARK>>Нет никаких преимуществ в том, что АлгТД весь в одном файле. Его преимущество — исчерпывающий match. И вытекающий отсюда же недостаток — нерасширяемость при необходимости. Всё это известно под названием expression problem.
AA>Помимо состояния(описываемого int-ом в сишарпе) в АТД(DU) мы еще передаем данные.

Спасибо, я в курсе.

AA>ФП — типы данных и функции это отдельные сущности.
AA>в ООП — классы(типы данных) организационно(концептуально) связаны с функциями для работы с этим данными.

Верно. Правда, причем тут некорректное сравнение наследования и АлгТД, я не понял.

AA>Это заставляет плодить состояние внутри классов.

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

AA>Когда типы данных лишены поведения они автоматически избавляют нас от необходимости следить за консистецией данных.

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

Здравствуйте, MadHuman, Вы писали:
MH>Учетная система всё никогда не будет на ФП, так как всегда будет бизнес логика задачей которой является изменения состояния базы, создание новых счетов, изменения состояния счетов, вот это всё.
Вот это — философский вопрос. Например, вся бухгалтерия — она вовсе не про "изменения состояния счетов", а как раз наоборот — добавление записей в нестираемую историю.
То, что мы называем "состоянием счетов" — это штука сугубо вторичная, интеграл от ledger.
Другое дело, что российский бухучёт — он в рамки блокчейна невпихуем, т.к. весь про то "а что, если полгода назад это было вовсе не списание, а амортизация", "ой, мы тут щёт-фактурку забыли провести" и прочие попытки таки выйти к концу отчётного периода на приемлемые (с т.з. налогового кодекса) "состояния счетов".

MH>На ФП возможно только часть учетной системы — отчетность, и прочее когда не надо изменять состояние, а по существующему нужно получить что-то.
MH>И вот для этой части, ФП вполне себе хорошо.
Понятие "состояния" нужно для систем оперативного управления и документооборота.
Не исключаю, что и там ФП будет вполне себе применимо, главное — найти как.

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

I>>>>Инкапсуляция решает вполне конкретные задачи. Нет таких задач — не надо за неё и держаться. Самое главное в ООП это структуризация решения сложной задачи, и, как следствие, организация взаимодействия.

AA>>>Вообще, будущее все равно за ФП. Почему? ООП — это моделирование поведения объектов.
AA>>>ФП — это функция. Вычисление которой есть результат. ЭВМ это калькулятор. Поэтому ФП ближе по природе к программированию нежели ООП.

ltc>>И доколе человек будет ломать мозг, чтобы писать на языке, более близком и понятном компьютеру, а не наоборот?

AA>Да что там ломать? У меня есть опыт использования F# и Nemerle в учебных целях. Скажу так, ФП по синтаксису намного проще ООП.
AA>Возьмем конкретный пример — наследование. И для простоты Nemerle (как более близкий по синтаксису с C#).

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

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

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

I>>Представь себе такую задачу — есть сервер, который умеет работать с несколькими протоколами. Для конкретного соединения нужно выбрать тот или иной протокол. Каждый из протоколов имеет кое какие общие черты. В силу требований реализация протокола должна подключаться через плагины и управляться через общий конфиг.

AA>Это ТЗ? вы хотите чтобы я закодил задачу?

Это что бы ты представил вещи, где может понадобиться ООП.

AA>ХМ, Если вас не тронула чистота ФП-кода, значит вам это не подходит. Что ж, рано или поздно все придут к ФП.
AA>Наверно также со скрипом заходило ООП когда-то.

Ты всё еще противопоставляешь ФП и ООП и не слышишь, что я тебе говорю. ООП не про мелочевку, а про структурирование вещей довольно большого масштаба.
ФП — про вычисления, ООП — про структурирование. Отсюда ясно, почему есть ФП+ООП языки(Окамл, F#). Более того, логические + ООП.

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

ltc>>И доколе человек будет ломать мозг, чтобы писать на языке, более близком и понятном компьютеру, а не наоборот?

AA>ФП — это чистая математика. Со времен Пифагора. Почему математическая запись не близка человеку?

Потому, что это математика. К человеку близко именно ООП, т.к. в основе ментальная модель мышления человека.

То, как человек управляется со сложной задачей, и легло в основу ООП.

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

S>>Ну, я пока не видел учётных систем, построенных на ФП. Но, по идее, в отличие от императивы, мы можем формально проверить, что все пререквизиты есть — и действие "отгрузка" просто не выполнится, пока нет оплаты, даже если программист это руками не проверил.
MH>Учетная система всё никогда не будет на ФП, так как всегда будет бизнес логика задачей которой является изменения состояния базы, создание новых счетов, изменения состояния счетов, вот это всё.

На ФП можно сделать все что угодно, даже изменения в базу. Для этого есть всякие монады и тд.

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

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

И далее начинается вариации между "подымем бонус до одной ЗП за функционалоста ... перепишем на JavaC#C++ ... закроем проект и уйдем в ML на пейтоне"

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

Собтсвенно требований и так много, даже без ФП. Поэтому поток кандидатов сужается примерно до нуля людей в месяц несмотря на конские ЗП и конские бонусы.

Не дай бог функционалист решит уйти невовремя — ПМ и ХР поседеют. Собственно, ПМ и ХР, которые которые готовы работать с функционалистами, становится все меньше и меньше...

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

MH>>Учетная система всё никогда не будет на ФП, так как всегда будет бизнес логика задачей которой является изменения состояния базы, создание новых счетов, изменения состояния счетов, вот это всё.
S>Вот это — философский вопрос. Например, вся бухгалтерия — она вовсе не про "изменения состояния счетов", а как раз наоборот — добавление записей в нестираемую историю.
S>То, что мы называем "состоянием счетов" — это штука сугубо вторичная, интеграл от ledger.
Согласен, вопрос довольно филосовский. В своём примере ранее я не точно выразился — имел ввиду счет на оплату (либо заказ), и под его изменением — изменение его статуса — черновик, подготовлен, подтверждён и прочие.
То есть изменение данных всё таки есть.
Если говорить об бух счете, то действительно "состояние" счета можно рассматривать как функцию от проводок, и сами проводки неизменяемые. Тогда действительно нет "изменения состояния счета".
Но опять же — добавление проводки это уже изменение базы.


S>Другое дело, что российский бухучёт — он в рамки блокчейна невпихуем, т.к. весь про то "а что, если полгода назад это было вовсе не списание, а амортизация", "ой, мы тут щёт-фактурку забыли провести" и прочие попытки таки выйти к концу отчётного периода на приемлемые (с т.з. налогового кодекса) "состояния счетов".
не сказал, бы что это свойственно именно российскому бухучету это свойственно людям, не всё сразу сделать, ошибиться где-то. И затем позже и приходится задним числом что-то корректировать подправлять.
а вот сданные отчеты уже впихуемы, тк если в отчете уже после нашли ошибку, затем обычно сдают корректировочный отчет/декларацию и делают это корректировочными проводками в новом периоде.


MH>>На ФП возможно только часть учетной системы — отчетность, и прочее когда не надо изменять состояние, а по существующему нужно получить что-то.
MH>>И вот для этой части, ФП вполне себе хорошо.
S>Понятие "состояния" нужно для систем оперативного управления и документооборота.
S>Не исключаю, что и там ФП будет вполне себе применимо, главное — найти как.
Мы упремся опять в апдэйты базы, когда в рамках бизнес-процедуры вытягиваются какие-то записи, меняются в них поля, и создаются новые.
Тут можно пойти по аналогии как в Хаскеле, смотреть на базу как на RealWorl и апдэйт порождает её новую версию... но хз хз... проще ли это уже будет для понимания)
А также обычно в логике бизнес-процедур, присутсвует чистая императивщина — условные операторы, присвоения в поля поднятой записи. И это в данном случае удобно, так как
соотвествует нашей ментальной модели — изменяем записи, тому как на постановочном уровне выражена бизнес-логика.
Как вот это совместить с ФП ... действительно вопрос...

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

AA>в ООП — классы(типы данных) организационно(концептуально) связаны с функциями для работы с этим данными.
AA>Это заставляет плодить состояние внутри классов.

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

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

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

AA>>в ООП — классы(типы данных) организационно(концептуально) связаны с функциями для работы с этим данными.
AA>>Это заставляет плодить состояние внутри классов.

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

Нет, конечно, он ООП-языки не для этого разрабатывались.
В C# невозможно объявить функцию вне класса.
В F# же, наоборот, функция объявляется самостоятельной сущностью
и может быть использована месте( и в методе класса и в другом модуле) через композицию.

Разница тонкая, но существенная, и не только концептуальная, но что важнее — синтаксическая.

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

MH>>Учетная система всё никогда не будет на ФП, так как всегда будет бизнес логика задачей которой является изменения состояния базы, создание новых счетов, изменения состояния счетов, вот это всё.

I>На ФП можно сделать все что угодно, даже изменения в базу. Для этого есть всякие монады и тд.
Про монады (точнее подход через IO аля хаскел) в курсе.
но если ФП там где нет IO красив, понятен и уместен, то лично для меня IO — это костыль позволяющий натягивать императивный подход поверх ФП.
то есть это уже не упрощение — а усложнение. Решением тут могло бы быть какое-то изящное комбинирование ФП и ИП подходов, возможно так как в F#, где есть нормальные присвоения, что позволяет писать вполне императивные куски кода.


I>Собрать большое количество функционалистов удаётся в исключительных случаях. Этим товарищам рутинной мелочевкой заниматься уже лет пять как не интересно. Поскольку рутины всегд много, то слишком редко удается удержать функционалистов на одном месте. Соответственно, начинается головняк у HR "где найти очередного функционалиста".
I> ....
с этим и всем что было далее в целом соглашусь.
Хотя на мой взгляд для применения ФП подхода не нужно быть прям вот таким крутым функционалистом. Достаточно его понять и можно использовать даже в майнстримовских языках.

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

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

I>>>Представь себе такую задачу — есть сервер, который умеет работать с несколькими протоколами. Для конкретного соединения нужно выбрать тот или иной протокол. Каждый из протоколов имеет кое какие общие черты. В силу требований реализация протокола должна подключаться через плагины и управляться через общий конфиг.

AA>>Это ТЗ? вы хотите чтобы я закодил задачу?

I>Это что бы ты представил вещи, где может понадобиться ООП.

AA>>ХМ, Если вас не тронула чистота ФП-кода, значит вам это не подходит. Что ж, рано или поздно все придут к ФП.
AA>>Наверно также со скрипом заходило ООП когда-то.

I>Ты всё еще противопоставляешь ФП и ООП и не слышишь, что я тебе говорю. ООП не про мелочевку, а про структурирование вещей довольно большого масштаба.
I>ФП — про вычисления, ООП — про структурирование. Отсюда ясно, почему есть ФП+ООП языки(Окамл, F#). Более того, логические + ООП.

ФП вполне себе может использоваться для построения больших систем:

Composing bigger programs: combinators

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

AA>>>в ООП — классы(типы данных) организационно(концептуально) связаны с функциями для работы с этим данными.
AA>>>Это заставляет плодить состояние внутри классов.

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

AA>Нет, конечно, он ООП-языки не для этого разрабатывались.

Вообще то именно для того. Вероятно, для тебя ООП это чисто его Симуловский вариант из трёх китов. Пока что ты дальше этих китов никуда не вышел. А между тем ООП гораздо ширше, это еще Алан Кей сказал.

AA>В C# невозможно объявить функцию вне класса.

Зато в C# есть т.н. extension method, который именно то и есть.
Далее, есть статические методы, которые снова именно то и есть.

AA>В F# же, наоборот, функция объявляется самостоятельной сущностью

И это ничем не лучше статического метода.

AA>и может быть использована месте( и в методе класса и в другом модуле) через композицию.

И что с того?

AA>Разница тонкая, но существенная, и не только концептуальная, но что важнее — синтаксическая.

Да-да, тёплый ламповый звук и всё такое.

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

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

ltc>>>И доколе человек будет ломать мозг, чтобы писать на языке, более близком и понятном компьютеру, а не наоборот?

AA>>ФП — это чистая математика. Со времен Пифагора. Почему математическая запись не близка человеку?

I>Потому, что это математика. К человеку близко именно ООП, т.к. в основе ментальная модель мышления человека.

I>То, как человек управляется со сложной задачей, и легло в основу ООП.

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

let f = fun x -> x * x; //вывод типов здесь здорово упрощает нотацию функций. чистый код - одна суть

В C# придется напрячься:

Func<int, int> f = (a) => a * a;//уже много лишнего, ведь код будет вызван и у продвинутого компилятора есть возможность определить типы из контекста?

//или по старинке
public static class Funcs {
    public static int F (int a) {
        return a * a;
    }
}

Как я уже сказал, разница не значительная на первый взгляд и в то же время колосальная.
Именно поэтому последние 10 лет очень много внимания уделяется ФП.

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

I>Вообще то именно для того. Вероятно, для тебя ООП это чисто его Симуловский вариант из трёх китов. Пока что ты дальше этих китов никуда не вышел. А между тем ООП гораздо ширше, это еще Алан Кей сказал.
Каюсь, все знать не дано.
Я не противник ООП в принципе, но я сторонник ФП.
Правда, в РФ его время еще не пришло.

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

I>>На ФП можно сделать все что угодно, даже изменения в базу. Для этого есть всякие монады и тд.
MH>Про монады (точнее подход через IO аля хаскел) в курсе.
MH>но если ФП там где нет IO красив, понятен и уместен, то лично для меня IO — это костыль позволяющий натягивать императивный подход поверх ФП.
MH>то есть это уже не упрощение — а усложнение. Решением тут могло бы быть какое-то изящное комбинирование ФП и ИП подходов, возможно так как в F#, где есть нормальные присвоения, что позволяет писать вполне императивные куски кода.

В тру ФЯ есть такой синтаксис, https://github.com/ixy-languages/ixy.hs/blob/master/src/Lib/Ixgbe.hs
Выглядит вполне сносно.


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

Мейнстримное ФП классом более простое, но даже оно вызывает проблемы у большОго числа людей.