SimpleX
На том же хаскелле все куда сложнее
ㅤ
Напротив, в ООП с SOLID никаких проблем нет
открой любой крупный ява проект например, и разверни конечный класс взад, там под десяток другой родителей
ㅤ
и попробуй легко поменять, муаххаа
SimpleX
Унаследовал, поменял
Vladimir
он сейчас скажет что овверайдинг - костыль
SimpleX
Конечно
Vladimir
три.два.один
ㅤ
целостность потерялась
SimpleX
Если вам нужно поменять поведение интерфейса, вы что-то делаете не так
Vladimir
Если вам нужно поменять поведение интерфейса, вы что-то делаете не так
какие ещё интерфейсы
Vladislav
и классы которые ожидают от детей тоже поведение что у родителя встали раком
ну так бездумно везде применять наследование это как весь код в IO заворачивать в Хаскелле
Vladimir
это же придётся плодить абстракции
Vladimir
ты что
ㅤ
Если вам нужно поменять поведение интерфейса, вы что-то делаете не так
конечно, в ооп если ты хочешь делать чтото свободно, ты не прав, делай в согласии с архитектурой проекта
SimpleX
Соглашение интерфейса важнее ваших костылей
ㅤ
ну так бездумно везде применять наследование это как весь код в IO заворачивать в Хаскелле
почти все в ооп это костыли обхода зависимостей
Андрей
конечно, в ооп если ты хочешь делать чтото свободно, ты не прав, делай в согласии с архитектурой проекта
Т.е. функциональщина - полная анархия? Или всё таки какого-то стиля придерживаться надо?
Vladislav
конечно, в ооп если ты хочешь делать чтото свободно, ты не прав, делай в согласии с архитектурой проекта
а в хаскелле ты свободно можешь поменять определение типа?
SimpleX
В фп вы точно так же не можете менять логику функций
SimpleX
Это бред
Vladimir
какую путанницу вносят интерфейсы?
Vladislav
иметь много типов норма
иметь много классов не норма
иметь много типов не норма
иметь много классов норма
Quet
не, все же круто товарищ вас троллит )
Андрей
Почему иметь много классов - не норма?
Quet
Vladimir
мне интересно, он рофлит или серьёзно?
Андрей
потомучто типы не связываются потом в дерево, а классы связываются
Не связывай классы, кто мешает?
Vladislav
Alex, твои аргументы невалидны, потому что в них всегда можно поменять ооп и фп местами и смысл не поменяется
Quet
тоже вот начал задумываться этим
ну я просто не верю что вменямый человек может так яростно топить за фп и еще такими аргументами мощными
Vladimir
я думаю такие существуют
ㅤ
Alex, твои аргументы невалидны, потому что в них всегда можно поменять ооп и фп местами и смысл не поменяется
нет :) посмотри проект, дерево ооп на хаскеле
ㅤ
вот наглядный пример
ㅤ
отличия фп от ооп и почему нельзя на фп писать в стиле ооп
Vladimir
отличия фп от ооп и почему нельзя на фп писать в стиле ооп
потому что это разные парадигмы - думаю по этой причине
Vladislav
нет :) посмотри проект, дерево ооп на хаскеле
а есть какие-то объективные метрики, показывающие превосходство фп над ооп, а не голословные утверждения?
Quet
а есть какие-то объективные метрики, показывающие превосходство фп над ооп, а не голословные утверждения?
ну че ты начинаешь, нормально же общались =р
ㅤ
а есть какие-то объективные метрики, показывающие превосходство фп над ооп, а не голословные утверждения?
сам принцип, описание действий а не дерево-действий-данных
ㅤ
фп это теги
ооп это дерево
ㅤ
каково отличие?
Vladislav
сам принцип, описание действий а не дерево-действий-данных
у тебя там чистые действия без данных?
Андрей
фп это теги
ооп это дерево
Понятно, ты считаешь, что ООП - это только дерево. Соглашусь, не всегда вот такое понимание подходит под задачу.
ㅤ
в ооп это куча работы
ㅤ
возьми пример,
класс автомобиль
подкласс водитель
подкласс маршрут
а теперь отрефактори зеркально
в фп это очень просто
в ооп это ад
Quet
водитель подкласс автомобиля?
Андрей
возьми пример,
класс автомобиль
подкласс водитель
подкласс маршрут
а теперь отрефактори зеркально
в фп это очень просто
в ооп это ад
Отрефактори зеркально? И что должно получиться?
Андрей
А, понял. ФП - это сделай через задницу, верно?
Quet
Vladislav
верно ли что на haskell можно быстрее и безбажнее чем на C++/java писать небольшие, хорошо формализованные задачи?