Не могу аргументированно сказать, что в ФП-коде из-за мутабельности «сломается» больше вещей, чем в ООП.

В "ФП-коде" - нормальном, а не "с элементами" - нет мутабельного состояния, ибо оно просто не нужно, т.к. задачи иначе решаются

Если приходится втыкать мутацию направо и налево, то имеет место недостаточное понимание парадигмы, увы

Ну ок. Значит, у меня на практике бывает только код «с элементами» ФП. Чистого ФП на F# не практиковал.

В F# это норма :)

Такой код обычно уже сильно лучше, чем голая процедурщина :)

Алгебраические типы и паттернматчинг уже делают язык пристойным ;)

И в F# волей-неволей "элементов ФП" будет больше, чем в каком-нибудь питоне, потому что язык к этому сподвигает - и это отлично! :)

Алгебраические типы и паттернматчинг уже делают язык пристойным ;)

Ну и частичное применение из коробки, пожалуй, тоже.

Ага

Потому что вот на C# мне частенько хочется написать какой-нибудь функциональный код, частично применить что-нибудь куда-нибудь — и неизменно в этих местах я вынужден городить какую-нибудь дребедень типа вложенных вложенных функций, ну или выносить всё в DI-контейнер, резолвить, конструировать какие-то сервисы, добавляя для них интерфейсы.

Шо так фигня, шо эдак фигня.

Это одна из стадий знакомства с ФП :) - Ничего не понятно - О, прикольно! - Как раньше жил без этого? - Применяю и в процедурных языках - Понял, что лучше в процедурщину не тащить ФП, потому как убого получается <--- - Умею процедурщину процедурно и функциональщину функционально (но первое - не хочется) - Не могу процедурно ибо уже ФП глубоко проросло - Почитаю как ещё пейперов, т.к. настоящее программирование, это уныло

> Не могу процедурно ибо уже ФП глубоко проросло я где-то тут :)

Если "ООП" здесь, это подход к моделированию доменной области, то да, в ФП можно объектный подход применять. Если же ООП - "мейнстримовое", т.е. локальное (инкапсулированное в объекты) мутабельное состояние, то не стоит даже пытаться применять ФП ибо будет только хуже - и асбстракции потекут с точки зрения ООП, и нужных предусловий для применения ФП тоже не будет (я про иммутабельность, явное преобразование данных)

Всегда путаница происходит. :) А как, например, назвать программирование с помощью параметризуемых иммутабельных объектов?

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

Если мы пишем player |> stepTo North |> drink HealthPotion |> equip Shield |> attack (player |> targetsOf |> first) то это вполне себе объектненько

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

Чтото беседа Бугаенковщиной отдаёт

Бугаенко местами прав, но он просто не может сделать последний шаг и уйти накоец в ФП :)

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

То есть ответ "ООП"?

В широком смысле - да

Ок.

Смоллтолков ООП тоже больше похож на на модель акторов, чем на "мейстримовый" ООП, хотя это и есть одна из классический версий парадигмы :)

Этот факт всегда любят вспоминать. Но меня больше "мейнстримовый" ООП интересует. :)

Как минимум потому, что это один из основных способов организации кода в F#.

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

Так что кое-что из мейнстримового ООП вполне применимо в ФП - в каком-то виде

Кто сказал, что ООП требует мутабельность?

Кто сказал, что ООП требует мутабельность?

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

Которое еще и наследуют, создавая развесистные иерархии. :)

Поэтому сложилось некоторое негативное мнение об "ООП".

Мы тут скорее говорим о прадигме, а не о каманли практиках. И вот парадигмы, насколько я понимаю, друг другу не противоречат.

Точнее не "мешают".

Мы тут скорее говорим о прадигме, а не о каманли практиках. И вот парадигмы, насколько я понимаю, друг другу не противоречат.

Проблема в том, что понятие "ООП" можно определить только из конкретного использования. :) В смоллтолке вот так, а в C# иначе, в F# рекомендуют третье.

Есть чат @oop_ru, там до сих пор не могут определиться точно, что это значит.

https://github.com/dsyme/fsharp-presentations/raw/master/images/PatternMatchHints.bmp

Привет из 2005.

Удивительно, с одной стороны тулинг F# улучшается, а с другой — хорошие фичи пропадают. %)

о том, что такое ФП тоже спорят

Бугаенко местами прав, но он просто не может сделать последний шаг и уйти накоец в ФП :)

оспади, попробую свои 5 копеек всунуть в обсуждение ООП и ФП и прочего вот попробуйте забить отвёрткой гвоздь, так же и с языками, у каждого изначально свои задачи и каждым нужно УМЕТЬ пользоватся по назначению (а не как егор твердить что ооп порочно) и не совать их повсюду, да и дико сомневаюсь что на функциональщине с иммутабильностью можно написать что-то для эмбеддед девайса с ограниченной памятью и иными ресурсами... ровно так же и с процедурщиной получается - её засунуть в энтерпрайз грешно. у егора есть идеи а-ля синтаксис языка это объект (это я про EO, "if" типо объект) так это смахивает на DSL.. но DSL это вообще тонкая тема, вавилонская башня рядом, каждый расширяет язык своими терминами в итоге никто никого не понимает ибо терминология может быть не едина

если у каждого свои задачи, то почему на языках создаваемых для программирования телевизоров, редкатирования текстов и мигания надписи "андер констракшн" на домашней страничке бекенд пишут, например?

^ this

в этом чатике еще, небось, есть те, кто бекенд пишет на языке, который создавали для скриптования пруф ассистента

оспади, попробую свои 5 копеек всунуть в обсуждение ООП и ФП и прочего вот попробуйте забить отвёрткой гвоздь, так же и с языками, у каждого изначально свои задачи и каждым нужно УМЕТЬ пользоватся по назначению (а не как егор твердить что ооп порочно) и не совать их повсюду, да и дико сомневаюсь что на функциональщине с иммутабильностью можно написать что-то для эмбеддед девайса с ограниченной памятью и иными ресурсами... ровно так же и с процедурщиной получается - её засунуть в энтерпрайз грешно. у егора есть идеи а-ля синтаксис языка это объект (это я про EO, "if" типо объект) так это смахивает на DSL.. но DSL это вообще тонкая тема, вавилонская башня рядом, каждый расширяет язык своими терминами в итоге никто никого не понимает ибо терминология может быть не едина

Эмбеддед с фп не дружит не из-за ресурсов, а из-за высокоуровневых абстракций. Но вообще вроде как если пару фич завести, то вполне можно. А что же касается ограничений по ресурсам, то тот же ghc очень агрессивно всё оптимизирует и на выходе появляется программа ни чуть не медленней написанной на сишке(ну если правильно готовить, офк)

На ФП можно синтезировать код для эмбеддеда. Да и Forth - вполне себе ФП :) А уж он то точно в железки лезет :)

Опять же, железки железкам рознь. FPGA хорошо "программируются" декларативно

Эмбеддед с фп не дружит не из-за ресурсов, а из-за высокоуровневых абстракций. Но вообще вроде как если пару фич завести, то вполне можно. А что же касается ограничений по ресурсам, то тот же ghc очень агрессивно всё оптимизирует и на выходе появляется программа ни чуть не медленней написанной на сишке(ну если правильно готовить, офк)

высокоуровневые абстракции обычно требуют толстый рантайм, так что из-за ресурсов

Вон, скоро линейные типы привезут в Haskell и смогём в железки ;)

Rust вполне себе ФП. Однако в железки его точно запихнут.

Rust вполне себе ФП. Однако в железки его точно запихнут.

даже по минимальному требованию к ФП - не ФП

в ФЯ как минимум UFP должна быть решена

Да, лисп тогда то же не ФП. Не стоит путать все же Pure ФП и ФП

в лиспе UFP решена, там с этим все в порядке

А что такое UFP?

Upwards funarg problem

когда можно функцию возвращать из функции, на практике без ГЦ это нормально не работает

В Rust можно возвращать функцию из функции. Поскольку функция - это трейт.

тут дело не в том трейт или нет, а в замыкании

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

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

там, где УФП не решена нужно делать специальные приседания связанные с управлением памятью

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

это не офтоп, это как раз самая суть минимальной поддержки ФП и передачи владения для этого недостаточно

также недостаточно счетчиков, из за циклов

Хорошо, это не ФП. Кроме Хаскеля в таком случае ФП не завезли. Потому что без безпроблемной поддержки HKT ФП - не ФП. ?

почему? По этому определению почти все языки с ГЦ - ФЯ

По этому - да. А вот по возможности и богатству применения...

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

Старая ява

Звучит как ностальгический крик

оспади, попробую свои 5 копеек всунуть в обсуждение ООП и ФП и прочего вот попробуйте забить отвёрткой гвоздь, так же и с языками, у каждого изначально свои задачи и каждым нужно УМЕТЬ пользоватся по назначению (а не как егор твердить что ооп порочно) и не совать их повсюду, да и дико сомневаюсь что на функциональщине с иммутабильностью можно написать что-то для эмбеддед девайса с ограниченной памятью и иными ресурсами... ровно так же и с процедурщиной получается - её засунуть в энтерпрайз грешно. у егора есть идеи а-ля синтаксис языка это объект (это я про EO, "if" типо объект) так это смахивает на DSL.. но DSL это вообще тонкая тема, вавилонская башня рядом, каждый расширяет язык своими терминами в итоге никто никого не понимает ибо терминология может быть не едина

Не думаю, что ООП и ФП предназначены для решения разных задач. Вообще ни одного аргумента в защиту этого мнения не приходит в голову

Если мы пишем player |> stepTo North |> drink HealthPotion |> equip Shield |> attack (player |> targetsOf |> first) то это вполне себе объектненько

а функционально это как было бы?

Это уже вполне функционально :)

Это уже вполне функционально :)

но и объектненько?

Объектный подход абсолютно перпендикулярен оси ПП<->ФП

Т.е. объектно можно писать и там и там

Объектный подход абсолютно перпендикулярен оси ПП<->ФП

пп это процедурное?

Да

Да

понятно, спасибо

Да не за что :)

https://visualmips.github.io

Зацените, какая штука.

На Fable написана.

https://twitter.com/realWeiJianWong/status/944905676966563840

Зацените, какая штука.

Я так и не понял что это

Я так и не понял что это

Редактор + эмулятор какого-то MIPS процессора.

Редактор + эмулятор какого-то MIPS процессора.

Вот я про мипс этот

Я видела когда-то ассемблер мипса

В сетевом оборудовании встречается

MIPS - довольно популярная архитектура :)

Ребят, столкнулся с проблемой. Из этого примера не работает 39 и 84 строчка handShakeWithSubprotocol и UTF8 попросту не существует

https://github.com/SuaveIO/suave/blob/master/examples/WebSocket/Program.fs

Может у F# API поменялся ?

@fvnever @gsomix есть мысли ?

тут тоже пример с UTF8 https://suave.io/websockets.html

Они сделали интернал

Utf8 модуль

С версии 2.2 вроде