При чем здесь БОД и сфера занятости? Люди станут более требовательны к условиям труда и оплаты, это да, а в остальном все останется также. И это просто здорово!
Так в том-то и дело, что в реальной жизни необходимы и мутабельность и иммутабельность, поэтому вопрос не в примирении сторонников разных подходов, а в том — зачем нужна была революция, если и эволюция вполне себе бы справилась (иммутабельный объект — это просто как вариант «с ходу»)?
В чем ФП-парадигма не могла быть интегрирована в существующие ОО-ЯП? Да, они бы не были уже чисто оопешными, ну и что, какая разница, если такие «фичи» бы появились?
Ветка очень интересная, спасибо!
Только вот теперь непонятно, зачем такое громкое название было давать — ФП, когда большинство улучшений (по сравнению с ООП) можно было бы реализовать в рамках несколько видоизмененного ООП, применяя например объекты с явным указанием вроде «с сайд-эффектами» / «без сайд-эффектов»?
Есть ли какие-то вещи, которые принципально не вписываются в ООП?
Так стартап — это и есть «неправильный» проект. Это фактически постановка нового эксперимента, здесь не до отчетности. Применение Agille в стартапах это большая ошибка менеджмента.
А тот джуниор ошибался, думая, что надо сделать «правильно», сделать надо было «лишь бы работало».
Требования к синтаксису всегда взаимосвязаны с характером решаемой задачи, ее масштабами и необходимостью дальнейшего поддержания программы и ее модернизации. Это даже не вопрос вкуса, но бизнес-процессов — т.е. объективное требование.
> Всё-таки читабельность — это ответственность программиста.
Чеж тогда все Бейсик ругали с его goto? Писали бы ответственно и проблем бы не было…
> А урезание выразительных возможностей наоборот снижает читабельность в сложных проектах.
Согласен, выразительность должна быть большая и безальтернативная.
Как раз наоборот — автор поднялся в теме. Теперь они видит не только вопрос создания кода, но и его поддержания т.д. Да, это другая сторона баррикад, которая ближе к потребителю, а потому и более правильная.
В чем ФП-парадигма не могла быть интегрирована в существующие ОО-ЯП? Да, они бы не были уже чисто оопешными, ну и что, какая разница, если такие «фичи» бы появились?
Только вот теперь непонятно, зачем такое громкое название было давать — ФП, когда большинство улучшений (по сравнению с ООП) можно было бы реализовать в рамках несколько видоизмененного ООП, применяя например объекты с явным указанием вроде «с сайд-эффектами» / «без сайд-эффектов»?
Есть ли какие-то вещи, которые принципально не вписываются в ООП?
А тот джуниор ошибался, думая, что надо сделать «правильно», сделать надо было «лишь бы работало».
Чеж тогда все Бейсик ругали с его goto? Писали бы ответственно и проблем бы не было…
> А урезание выразительных возможностей наоборот снижает читабельность в сложных проектах.
Согласен, выразительность должна быть большая и безальтернативная.