Oleg
Это как стек технологий сменить, только ещё жестче
Oleg
Ну от тебя я другого и не ждал 😄
Дима
Для фп требуется определенный уровень развития технологий, как компиляторов так и железа
Oleg
С этим согласен
Дима
Потому что ничего не бывает бесплатно, и в качестве базовго размена предлагается часть оперативной памяти в обмен на скорость и иммутабельность, когда у тебя всего пара сотен мегабайт — об этом даже подумать сложно)
Oleg
Какие из реально продакшн ФП языков сейчас действительно популярны?
Дима
Closure, Scala
Дима
Haskell как ни странно тоже далеко не академический
Oleg
Мультипарадигменность же
Oleg
Скала кстати менее популярна чем кобол
Oleg
Хаскел не входит в топ 50 языков
Oleg
По индексу TIOBE
Oleg
Пока всё идет к тому что будущее за мультипарадигменностью
Oleg
Когда у тебя и оттуда и отсюда
Oleg
Правда это нарушает чистоту функций и тп в ФП
Oleg
Когда часть кода в ФП, вторая в ООП - сложно доверять части с ФП ибо а вдруг там стейты мутабельны
Oleg
То есть надо либо всё ФП, либо мульти
Дима
Фп — это промежуточное звено между высокой теорией и низкоуровневым кодом
Oleg
Мир сейчас выбирает мульти
Дима
Дима
Фп отлично работает с мутабельностью именно потому что может свободно оперировать понятиями чистоты и сайд-эффектов
Дима
То есть это даже не единичные факты, это стандартные ADT в любом фп языке
Oleg
В итоге всё-равно мульти 😄
Oleg
В том плане что чистые ФП языки сильно далеко от топа
Дима
В итоге всё-равно мульти 😄
Да, просто тебе сложно поверить, что это всё равно означает отказ от ооп)
Oleg
Ну вон в JS нормально и классы юзаешь и функции передаешь в обработчики даже в банально forEach
Oleg
В других языках это была бы отправка блока кода
Дима
Ага, потому что в жс концепция функций как first class citizens
Oleg
То есть объективно функции высшего порядка очень удачно вписались во всё это
Дима
И замыканий
Oleg
Вот
Дима
Да ты не поверишь, тут и объекты суперски вписываются
Дима
ФП не означает, что у тебя прям всё является какой-то буквальной функцией
Дима
Просто теперь никому больше не хочется пихать логику в каким-то образом связанные с ними объекты или пытаться строить структуру предметной области без взаимосвязей-функций, одними объектами — это просто нонсенс
Oleg
Ну вообще это норма
Oleg
Объекты, инкапсулирующие логику, общающиеся сообщениями
Oleg
Объект описывает сущность и действия что можно с ним сделать
Дима
Это пиздец, а не норма)) Так как даже сам процесс обмена сообщениями уже не описывается самими объектами
Oleg
И может быть логическим продолжением другого объекта через наследование
Oleg
Ну и полиморфизм и тп
Vitaly
банан-горила-джунгли.jpg
Дима
Объект описывает сущность и действия что можно с ним сделать
Действия которые можно с ним делать не принадлежат субьекту этих действий
Oleg
А это нормально тоже, ты на телефоне жмешь кнопку, а телефон уже сам работает как нужно
Oleg
Или как у Кантора с кофемолками пример
Oleg
Тебе не важно как оно будет работать - тебе важно что ты можешь сказать - хочу это, а тебе результат
Oleg
И интерфейс взаимодействия - методы как список действий что ты можешь совершить
Oleg
Ну и приватные методы как внутренние действия
Vitaly
Тебе не важно как оно будет работать - тебе важно что ты можешь сказать - хочу это, а тебе результат
если неважно тогда зачем OOP?
Vitaly
ну я спроецировал: просто зачем смешивать абстрации на разныхз уровнях
Oleg
А не нужно ничего смешивать
Дима
Объекты можно сравнивать (Eq)
Объекты можно складывать в группы (+)
Можно сказать, что в случаях выше мы применяем какой либо эффект к объекту, не важно какому и какой эффект
F :: f -> obj -> f obj
AK
oop только для структурирования кода, не более того.
Oleg
Можно сравнивать объекты если они поддерживают метод сравнения
Oleg
И тд
Дима
Вот с и т.д. у тебя начнутся критические проблемы
Oleg
Если они имеют признак необходимый, по которому их можно сравнить
Дима
Нет, это вообще не важно
Дима
Это — несущественные детали
Roman
Дима
Нам не важно как производит сравнение инстанс тайпкласса EQ, это его дело
Дима
Проблемы ооп подхода начнутся далее, когда мы сформулируем, что сортируемый массив — это суммируемуя (+ / concat) сущность, состоящая из сравниваемых (EQ, ==) элементов
Дима
Пытаясь выразить это через ооп столкнёмся с диким интерфейсоми остановимся на том, что выразить один дженерик через жругой практически невозможно
Oleg
Возможно проблема в том что некоторые объекты нельзя так просто взять и сравнить?
Oleg
Как минимум по одному свойству
Дима
Ты не понимаешь)
Дима
Свойство — это компарабельность сама по себе
Oleg
Вот
Oleg
Так в чем проблема?
Дима
В том что это тайпкласс, который не выражается через ооп
Дима
Мы можем сравнить два любых объекта тайпкласса EQ a между собой, по определению можем
Oleg
В предложении в обоих частях два раза слово "можем"
Oleg
Так можем или не можем? 😄
Дима
Это базовые понятия
Дима
Они — фундаментальны и всеобщи, ввиду чего оперировать этим значительно проще чем weak oop
Oleg
Я не вижу проблемы тут, возможно всё решилось бы примером, может быть я действительно чего-то не вижу. А может и нет никакой проблемы или мы просто о разном.
Oleg
А так мы можем сравнить что угодно с чем угодно если у нас есть шкала и у цели есть то, к чему эту шкалу можно приложить
Oleg
В данном случае прикладываем к некоторым свойствам