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

scf>Но сейчас не 90е и ООП как граф мутабельных объектов "реального мира уже неактуален.
Расскрой мысль, а то не понятно что-то что сейчас у нас ООП?

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

scf>>Но сейчас не 90е и ООП как граф мутабельных объектов "реального мира уже неактуален.
K>Расскрой мысль, а то не понятно что-то что сейчас у нас ООП?

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

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

UPD: еще один кит, который раньше был неявно, — это типы, в т.ч. АТД. Начиная с Бертрана Мейера люди начали открыто говорить об этом. Собственно именно по этому важен принцип замещения Лисков.

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

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

Далее, утвердилась концепция "обработка данных". Для ООП это значит, что бизнес-логика не размазывается по классам, а помещается в класс, который обычно stateless. Такой класс занят обработкой данных. Какая унутре модель вычислений, мутабельная или иммутабельная, дело десятое. Со временем такие классы начали называть сервисами. Важно, что такой сервис может агрегировать другие сервисы и делегировать им обработку, может проксировать, может замещать, может представлять собой композицию сервисов и тд и тд и тд.
Все это можно посмотреть в Service Oriented Programming — тут есть и инкапсуляция, и абстракция, и композиция, и интерфейсы и все что угодно.

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

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

Теперь самое страшное — выяснилось, что дизайн всех мейнстримных языков построен по слоёной структуре:
Верхний слой, это парадигма для структурирования
Средний слой, это парадигма для каких нибудь многозадачных вещей
Нижний слой, это парадигма для вычислений

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

То есть, ООП всех победил и стал королём горы. Радикальные функционалисты с этим не согласны, а потому регулярно радуют эмуляцией известных из ООП паттернов типа Роутер, Медиатор и тд. При этом они любят повторять "смотрите, для ФП не надо никаких паттернов, щас я вам Роутер покажу..."

P.S. Из этого не следует, что ФП не нужно. Проблема исключительно в головах радикальных функионалистов, которые то свои любимые ЯП применяют тотально, вне зависимости от доводов рынка, заказчика, разума.

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

I>Далее, подход к дизайну поменялся. Вместо "моделируем реальный мир" стала применяться концепция "моделируем решение", что предполагает, что задачу сначала надо решить, а уже потом при помощи ООП транслировать решение в код.
Мне вот этот тезис не понятен. Всегда же отталкивались от юзкейсов, выделяли из них сущности, строили entity diagram (собсвтенно, делали ОО анализ), sequence diagram чтобы визуализировать что проиходит и в итоге делали ОО декомпозию, резали на слои и т.п. и т.д. после чего писали код. Я, наерное, не в тренде, и вообще ретроград, но ВТФ? Что занчит "моделируем решение"?

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

I>То есть, ООП всех победил и стал королём горы. Радикальные функционалисты с этим не согласны, а потому регулярно радуют эмуляцией известных из ООП паттернов типа Роутер, Медиатор и тд. При этом они любят повторять "смотрите, для ФП не надо никаких паттернов, щас я вам Роутер покажу..."

I>P.S. Из этого не следует, что ФП не нужно. Проблема исключительно в головах радикальных функионалистов, которые то свои любимые ЯП применяют тотально, вне зависимости от доводов рынка, заказчика, разума.

Спасибо, очень крутой ответ.
Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.
(Scala hint hint)

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

scf>Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.

Т.е. за C#.

scf>(Scala hint hint)

Скорее уже Kotlin подтянется.

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

scf>>Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.

IT>Т.е. за C#.

Шарп — крутой язык, но вот владелец у него не очень. В отличие от sun/oracle, которые монетизировали платформу за счет платной техподдержки, майкрософт действует намного агрессивнее, лишая свободы выбора.

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

scf>Шарп — крутой язык, но вот владелец у него не очень. В отличие от sun/oracle, которые монетизировали платформу за счет платной техподдержки, майкрософт действует намного агрессивнее, лишая свободы выбора.

Выбора чего?

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

I>>Далее, подход к дизайну поменялся. Вместо "моделируем реальный мир" стала применяться концепция "моделируем решение", что предполагает, что задачу сначала надо решить, а уже потом при помощи ООП транслировать решение в код.
K>Мне вот этот тезис не понятен. Всегда же отталкивались от юзкейсов, выделяли из них сущности, строили entity diagram (собсвтенно, делали ОО анализ), sequence diagram чтобы визуализировать что проиходит и в итоге делали ОО декомпозию, резали на слои и т.п. и т.д. после чего писали код. Я, наерное, не в тренде, и вообще ретроград, но ВТФ? Что занчит "моделируем решение"?

Да вот не всегда. Слишком часто юзкейсы всплывают после написания кода, а уже всё пронаследовано, модель реального мира создана и тд. Юзкейсы, анализ это считай что рокетсаенс. Многие считают, что ОО-пэшить можно и без этого. Я бы сказал, что большинство.

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

I>>То есть, ООП всех победил и стал королём горы. Радикальные функционалисты с этим не согласны, а потому регулярно радуют эмуляцией известных из ООП паттернов типа Роутер, Медиатор и тд. При этом они любят повторять "смотрите, для ФП не надо никаких паттернов, щас я вам Роутер покажу..."

I>>P.S. Из этого не следует, что ФП не нужно. Проблема исключительно в головах радикальных функионалистов, которые то свои любимые ЯП применяют тотально, вне зависимости от доводов рынка, заказчика, разума.

scf>Спасибо, очень крутой ответ.
scf>Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.
scf>(Scala hint hint)

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

Радикальные функционалисты уверены, что квалификацю определяет N-изученых ЯП — каждый ЯП прибавляет 1..n уровней к квалификации. На самом деле, если задачи не выше группировки по сложности, хоть миллион языков изучи, потолок в квалификации очевиден — решаемые задачи, то есть, группировка.

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

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

scf>>>Будущее за языками, совмещающими интерфейсы и классы для структурирования, монады для моделирования асинхронных процессов, ФП стиль для вычислений.

IT>>Т.е. за C#.

scf>Шарп — крутой язык, но вот владелец у него не очень. В отличие от sun/oracle, которые монетизировали платформу за счет платной техподдержки, майкрософт действует намного агрессивнее, лишая свободы выбора.
Простие, в каком месте агрессивнее?
Если вы уснули в 2010, а проснулись только сейчас, то вот вам свежая сводка:
1) Visual Studio бесплатна для всех некоммерческих разработчиков
2) Visual Studio теперь есть и на маке
3) Для консоледрочеров есть command-line тулы для разработки и VSCode (блокнот на стероидах)
4) .NET Core работает на всех платформах (win, mac, linux) и распространяется одним
5) .NET Core и все его компоненты в опенсорсе
6) Компилятор C# в опенсорсе
7) .NET Core с последним релизом дружит в том числе с WPF и частично с WinForms (последний бастион, оберегающий "взрослый" .NET пал)
8) .NET Core приложения научились упаковываться в один исполняемый бинарник
9) Microsoft даже Xamarin выкупил и выложил в опенсорс

Помоему все претензии к Microsoft и .NET\C# уже должны кончиться.

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

I>Да вот не всегда. Слишком часто юзкейсы всплывают после написания кода, а уже всё пронаследовано, модель реального мира создана и тд.
Ну так оно всё равно не выходит за рамки бизнес процессов.
I>Юзкейсы, анализ это считай что рокетсаенс. Многие считают, что ОО-пэшить можно и без этого. Я бы сказал, что большинство.
Я не отказываюсь в это верить.. А как же классическое CS образование, курсы по архитектуре, книги, передача опыта на работе? Ты меня расстраиваешь.

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

BFE>>Ну так потому, что это не возможно, поэтому и не опровергните.
BFE>>В фп нет структур, там есть только последовательности операций, некоторые из которых принято называть "список", "очередь"...
S>Странно. Куда вы дели структуры из ФП?

Я? Их там отрадясь не было.

S>Конечно же там есть структуры.

Конечно же там нет структур. Структура — это нечто размещённое по определённым правилам по ячейкам памяти.

S>Для перевода диалога в конструктивное русло рекомендую почитать, например, https://ru.wikibooks.org/wiki/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/%D0%A1%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D0%B8_%D0%B1%D0%B0%D0%B7%D0%B8%D1%81%D0%BD%D1%8B%D0%B5_%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%B8

Ну и?
Где там списки?
Вот, определение:


Вы хотите сказать, что это структура?
Или может быть это структура ?

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

Всё это ясно видно, например, из преведённой вами ссылки. В разделе "Несколько слов о программной реализации" прямо показано, что то, что называется списком в ФЯ может при реализации представлять из себя дерево.

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

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

Такие вещи сейчас делают на Питоне. Хотя сами вычисления естественно происходят в высокопроизводительных C/C++ библиотеках. Причём интерфейсы к этим библиотекам вполне себе имеют как функциональные, так и ООП черты, одновременно!

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

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

Наоборот. Если софт не удается заделиверить вовремя или не получается обеспечить качесвтво, приходится подстраивать под это бизнес. Это и есть выход за рамки.

I>>Юзкейсы, анализ это считай что рокетсаенс. Многие считают, что ОО-пэшить можно и без этого. Я бы сказал, что большинство.
K>Я не отказываюсь в это верить.. А как же классическое CS образование, курсы по архитектуре, книги, передача опыта на работе? Ты меня расстраиваешь.

Подробнее, причем здесь я ? Думаешь это я причной тому, что у вас в ИТ приходят люди без образования?

Реально самообразованием занимается только увлеченное меньшинство. В университете ооп рассказывают все еще про трех китов, когда их давно уже не три — то есть, достаточно кривая симуловская модель ООП, да еще и в устаревшем виде. Ну за каким то раком паттерны добавили. Знаний по ООП от этого не добавилось. Студенты прикладной математики, где CS по самые нидерланды, как правило не умеет объяснить принцип замещения Лисков.
Это все вне зависимости от конторы, города или страны.

CS образование как правило кривое и оно есть у меньшинства. Более того, последние годы тренд такой, что люди идут в IT вообще без этого.
Курсы по архитектуре не заменяют ООП.
Книги читает меньшиство — так было во все времена.
Передача опыта по работе — смешной аргумент. Сейчас тимлидами-менеджерами становятся за пару лет. Если платят много денег и можно быть менеджером без всего этого, зачем тратить время на CS, ООА, ООД и тд?

Повторяю — так почти везде, по крайней мере в странах бывшего СССР и Восточной Европе.

Рельно ООА, ООД, кейсы, внятные сущности есть там, где хорошие бизнес-аналитики и толковые архитекторы. И это встречается не так уж часто

Здравствуйте, B0FEE664, Вы писали:
BFE>Конечно же там нет структур. Структура — это нечто размещённое по определённым правилам по ячейкам памяти.
Нет. Это штука, которая ведёт себя определённым образом.
BFE>Где там списки?
Вы же сами дальше показываете список .
BFE>Вот, определение:
BFE>Image: 7dfa43a83bdab173d7b5c70d33b71c824fcb130a
BFE>Image: 9addfb4bd70438af57b74f7fc2409f465cd97e99
BFE>Вы хотите сказать, что это структура?
BFE>Или может быть это структура Image: d82ca855cb461e60170868daaaa530e35d613649?

BFE>Ничего подобного. Этот список и эта структура ничего не говорят о том, как это хранится в памяти и что из себя представляет.
И слава байту. Зачем вам знать, как он хранится в памяти?
BFE>Эти понятия имеют очень мало общего, почти ничего, со структурой типа список, который рассматривается в структурах программирования.
"Что из себя представляет" == "какие операции можно совершить".
Byte layout к этому имеет очень косвенное отношение. Ситуаций, когда нам точно нужно знать, как именно расположены данные в физической памяти, исчезающе мало.

BFE>Это записи говорят о том, что и в какой последовательности сделать с входным потоком данных, задают преобразование над аргументами, отношения в математическом смысле.
Совершенно верно.
BFE>Списком называется нечто такое: Image: Singly_linked_list.png
BFE>Всё это ясно видно, например, из преведённой вами ссылки. В разделе "Несколько слов о программной реализации" прямо показано, что то, что называется списком в ФЯ может при реализации представлять из себя дерево.
Конечно. А почему вас это беспокоит?
Если эта штука ведёт себя как список, то списком она и является.

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

BFE>>Ничего подобного. Этот список и эта структура ничего не говорят о том, как это хранится в памяти и что из себя представляет.
S>И слава байту. Зачем вам знать, как он хранится в памяти?

S>Если эта штука ведёт себя как список, то списком она и является.


На досуге воспроизвел классику жанра функционального списка без объявления структуры. Структура данных есть, т.к. ведет себя как список. А структуры (хранения, byte layout) данных — нет. Точнее, нет объявления такой структуры в коде.

void Main()
{
    var list = new[] {1, 2, 3, 4, 5}
        .Aggregate(List<int>.Empty, (acc, v) => List.Cons(v, acc));
        
    var rev = List.Reverse(list);
    
    Console.WriteLine("Length = " + List.Length(list));
    Console.WriteLine("Sum = " + List.Fold(list, 0, (acc, item) => acc + item));
}

static class List
{
    public static List<T>.Node Cons<T>(T head, List<T>.Node tail)
        => List<T>.Cons(head, tail);
        
    public static S Fold<T,S>(List<T>.Node l, S acc, Func<S, T, S> f)
        => List<T>.IsEmpty(l)
            ? acc
            : Fold(List<T>.Tail(l), f(acc, List<T>.Head(l)), f);

    public static int Length<T>(List<T>.Node n)
        => Fold(n, 0, (acc, _) => acc + 1);
        
    public static List<T>.Node Reverse<T>(List<T>.Node n)
        => Fold(n, List<T>.Empty, (acc, i) => Cons(i, acc));
}

static class List<T>
{
    public delegate (Func<T>, Func<Node>) Node();

    public static Node Cons(T head, Node tail)
        => () => (() => head, () => tail);

    public static T Head(Node list) => list().Item1();
    public static Node Tail(Node list) => list().Item2();

    public static readonly Node Empty = () => (() => throw new Exception(), () => throw new Exception());
    public static bool IsEmpty(Node node) => node == Empty;
}

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

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

BFE>>Ничего подобного. Этот список и эта структура ничего не говорят о том, как это хранится в памяти и что из себя представляет.
S>И слава байту. Зачем вам знать, как он хранится в памяти?
BFE>>Эти понятия имеют очень мало общего, почти ничего, со структурой типа список, который рассматривается в структурах программирования.
S>"Что из себя представляет" == "какие операции можно совершить".
S>Byte layout к этому имеет очень косвенное отношение. Ситуаций, когда нам точно нужно знать, как именно расположены данные в физической памяти, исчезающе мало.

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

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

S>Из этого кода не следует, что данные в ФП хранятся именно подобным образом (без объявления структур). Это лишь пример того, что хранить можно используя одни лишь функции.

К сожалению, именно такой код часто и пишут функционалисты и называют это "красиво". Я даже видел библиотеки всерьёз написаные в подобном стиле на C# и даже на JS

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

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

S>>Из этого кода не следует, что данные в ФП хранятся именно подобным образом (без объявления структур). Это лишь пример того, что хранить можно используя одни лишь функции.

I>К сожалению, именно такой код часто и пишут функционалисты и называют это "красиво". Я даже видел библиотеки всерьёз написаные в подобном стиле на C# и даже на JS

Пишут — и славно. Чего они тебе покоя не дают? Есть куча софта, где это не мешает никак. Вот надо 4 сообщения в телеге обработать за сутки. Не заниматься же там преждевременной оптимизацией в обнимку с профайлером?

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

I>>К сожалению, именно такой код часто и пишут функционалисты и называют это "красиво". Я даже видел библиотеки всерьёз написаные в подобном стиле на C# и даже на JS

S>Пишут — и славно. Чего они тебе покоя не дают? Есть куча софта, где это не мешает никак. Вот надо 4 сообщения в телеге обработать за сутки. Не заниматься же там преждевременной оптимизацией в обнимку с профайлером?

Я пишу про те кейсы, где это неуместно. Типа это надо объяснять ?
Кроме того:
— на кой ляд изобретат велосипед в ЯП с другой парадигмой, где вообще всё построено на других принципах ?
— преждевременная пессимизация "всё и так будет работать" не менее вредна чем преждевременная оптимизация.
— сложность сопровождения вырастает — нужно постоянно продираться через такие велосипеды, соответсвенно, такое решение обычно усложняет проект, а не наоборот.