Поправьте если я ошибаюсь, но ключевая позиция фп - это работа с данными в иммутабельном виде а ключевая позиция ооп - когда данные представляют собой живой граф объектов. То есть, с ооп, когда отдельная функция получает какой-то глубокий объект этого графа то она может сохранить этот объект в замыкании и со временем свободно обновлять поля этого объекта и актуальные изменения увидят все другие функции которые также хранят ссылку на этот объект. А подход иммутабельности и отсуствия сайдэффектов в фп предполагает что мы должны вернуть новый объект после его изменения но помимо этого также должны рекурсивно заменить всех родителей новыми объектами (потому что у них нужно изменить поле ссылающееся на новый объект ребенка) а это добавляет неудобств в при появлении циклических ссылок друг на друга потому что их нужно хранить через айдишники на эти объекты (иначе будут рекурсивно пересоздаваться все связанные по ссылке объекты и результате получим что чуть ли не весь граф объектов будет пересоздан заново). Например в мессенджере когда есть объект юзера со списком чат-комнат и каждая такая чат-комната ссылается на объект юзера и также на объект самой комнаты то с ооп мы можем просто хранить эти объекты в виде вложенных объектов и ссылок и удобно получить например список чатов юзера user.chatRooms.map(cr=>cr.room)а с фп придется дополнительно джойнить данные получая каждый объект чата по его айдишнику из глобального хеша user.chatRoomsIds.map(id=>globalHash.get(id)).map(roomUser=>globalHash.get(roomUser.roomId))что добавляет некоторой неясности в код. А когда функция захочет обратиться к более глубоким объектам по цепочке то код с фп становится еще сложнее Например есть приложение с кучей вложенных сущностей - юзер может создавать папки, внутри папок проекты, внутри проектов задачи и к задачам может создавать подзадачи то функция которая получает объект подзадачи и ей нужно вычислить приоритет на основе приоритета папки в которой эта подзадача находится то ей по сути нужно будет от объекта задачи добраться до объекта папки через все промежуточные объекты. И если в ооп это можно записать просто и наглядно subtask.task.project.folder.priorityто с иммутабельным подходом нужно будет вытаскивать каждый промежуточный объект из глобального хеша и код становится совсем не наглядным globalHash.get(globalHash.get(globalHash.get(subtask.taskId).projectId).folderId).priorityИ в реальных приложениях код бизнес-логики будет сплошь и рядом увешан кодом постоянного вытаскивания нужных объектов по их айдишникам из хеша и в итоге превращается в ненаглядную лапшу.

Immutable object не слышал Для начала таких фундаментальных заявлений не плохо бы понять чем декларативное от императивного отличается, а уже потом к ооп vs фп

Потому что можно ещё статься на тему процедурное vs объектно ориентированное

Процедурки форевар!

Я наркоман, у меня асинхронные команд басы на пыхе

Я наркоман, у меня асинхронные команд басы на пыхе

Я наркоман, у меня асинхронные команд басы на пыхе

Хотя вот некоторые (не буду показывать пальцем @desper1989) прониклись

расскажешь потом историю успеха как ты при помощи асинхронных саг перевел проект с пыхи на шарпы)

Да, пожалуйста: https://www.peachpie.io/

это надо @mkusher убедить что мол f#/c# лучше чем тайпскрипт.

Он топит за ts?!

он слишком благоговеет перед дартом, мы не смеем на нем писать

всё же лучше чем на жс без типов

Но, flow...

flow недостаточно объектно ориентирован

flow недостаточно объектно ориентирован

всем java :)

* процедурщины

я ангуляр пишу на работе вообще

scala?)

тип ты в команде разработчиков ангуляра или ты на ангуляре формы накидываешь?

function call<TS extends any[], R>(fn: (...args: TS) => R, ...args: TS): R { return fn(...args); } Какие еще доказательства нужны?

реактивные формы из коробки

ммм... это шарпы да? а то выглядит как ts

Это как раз TS...

можешь не оправдываться. Как там ng ivy? релизнули уже?