это кстати от места зависит. Большинство мест работы, как мне видится, это действительно реки, в которые нельзя войти дважды. Может, это только мой опыт.
Да, я тоже из возвращенцев)
Шутки шутками, но есть например, бешенство. Больной бешенством по поведению напоминает классического зомби из хорроров, за одним исключением — свето- и водобоязнь. Стоит этой заразе чуток мутировать, и зомби-апокалипсис уже не кажется такой уж фантастикой.
мне помогает просто (спойлер: это далеко не всегда просто) взять листочек бумаги и дать на нем волю своему внутреннему критику, всем мыслям, фразам и чувствам. Прикол мыслей в том, что когда мы начинаем с ними бороться, вступать в диалог, конфронтировать — они никуда не денутся, наоборот, будут продолжать не давать покоя. Каждая мысль хочет быть услышанной и будет стучать до тех пор, пока это не произойдет. Для меня более оптимальная стратегия — дать «критику» высказаться и быть услышанным. Там (по крайней мере у меня, про других не знаю) — целая гора мнений, чувств и желаний. Когда накал спадет, можно начинать диалог.
Вообще последние полгода приучаюсь мыслить на бумаге. Мы же задачи по математике в голове не решаем, бумажку берем. Так и здесь.
Ну да, иммутабельность чего-то стоит, несомненно. Но в тоже время она почти даром дает нам например такие вещи, как возможность версионирования значения
Да вполне терпимо стоит. По асимптотике функциональные структуры данных такие же, как и мутабельные. Зато параллелизм из коробки.
ФП работает с «чистыми» функциями. Но реальное приложение работает с файлами, БД, внешними сервисами, которые нарушают требования «чистоты», в итоге приходится придумывать костыли
И как это мешает бизнес-логику реализовать на чистых функциях, а ввод-вывод оставить грязным функциям? IO-монада, там, вот это все.
в ФП переменные иммутабельны. Если у вас есть массив из 100 пользователей, и вы должны одному обновить рейтинг, вы должны сделать полную копию массива. И так на каждое изменение. Это негативно влияет на производительность и потребление памяти.(пример: реакт, где на любой чих пересоздается стейт заново и хорошо, если он у вас маленький).
Лишний повод почитать структуры данных. Immutable hash trie (через который в ФП реализуются immutable массивы) решает проблему.
в ФП нет исключений. В нормальном программировании вы просто пишете действия подряд, если произойдет ошибка, выбросится исключение и оставшиеся не будут выполняться. В ФП вам приходится лепить костыли, делая типы вроде Maybe и делая «пропуск» функции, если ей передано Maybe с ошибкой внутри.
Зато есть Either (это в scala), Option и до черта всякого остального. Пропуск функции делать не нужно, монада сделает это за вас.
в ФП нет ООП, которым удобно представлять объекты реального мира. Вместо этого там приходится делать разрозненные структуры и функции для работы с ними — то, для замены чего и придуман ООП. А ведь в ФП вы еще не можете модифицировать объект, с которым работаете.
ФП плох потому, что в нем нет ООП)
Вообще есть до черта всего. Алгебраические типы данных. Coproduct-ы. Функторы. Аппликативные Фнукторы. Монады, в конце-то концов. Полугруппы, моноиды, группы. Этим всем вполне можно представлять объекты реального мира.
в ООП функуция это просто последовательность шагов: 1) проверь, что такого емайла нет 2) добавь запись в БД 3) отправь письмо для подтверждения почты. В ФП же так не принято, а принято комбинировать функции в составные функции, из-за чего разбор кода превращается в кошмар (registrator = (formData) => combine(formValiadtor(rules), fieldExtractor('email'), emailNotInDbChecker(db), emailToDbAdder(db), emailSender(db, sendService)).
Это на уровне бреда. Вполне можно и последовательные вычисления организовывать, мешает-то кто?
по-моему, принудительная установка софта российских производителей, да еще со штрафами за невыполнение — это уже перебор. Мне в этом видится как раз нарушение антимонопольного законодательства. За российских производителей софта, впрочем, остается только порадоваться. Вопрос, как с ценами на конечное устройство для пользователей это дело будет, ведь производители смартфонов теоретически могут лишиться каких-нибудь бонусов за предустановку приложений иных производителей.
да, я чуток накосячил в терминологии. Исключительная ситуация — когда ничего другого не остается, кроме как форснуть ошибку выше, вплоть до падения программы. Ошибка — это то, что обрабатываем здесь и сейчас. Первое — подмножество второго. Я имел в виду, что для обработки ошибок в плюсах принято использовать исключения. Но тут еще нужно более развернуто определить, что же такое ошибка) Exceptional-based logic тоже стоит избегать, конечно же.
Вам в конструктуре было бы неплохо узнать — а какой, собственно, будет размер «внутренностей» у вашего окна
я может быть туплю, но мне показалось, что вы хотите вызвать в конструкторе виртуальные методы объектов-агрегатов. В этом случае — никаких ограничений. А вот вызов виртуального метода самого объекта из конструктора противоречит просто здравому смыслу, так как предполагает выполнение кода потомка до вызова его конструктора
Использование фабрик и RAII — вещи не конкурирующие, а дополняющие друг друга.
Ну и позволю себе чуток уточнить по вашим пунктам)
1. На самом деле нельзя) Если вы хотите вызвать из конструктора/деструктора виртуальный метод, то вы хотите странного.
2. Альтернатива — предусмотреть неинициализированное состояние объекта и перед использованием проверять, прям как в C. Исключение — удобный механизм, но производительность — соглашусь, хреновая. Но на то оно и исключение, что это именно что исключительная ситуация. А кинете вы исключение из конструктора или из фабрики — не суть важно, в любом случае все недоинициализированное придется так или иначе подчистить.
3. Полностью согласен, если Destroy вызывается не из деструктора какого-нибудь объекта в каком-нибудь фреймворке)
4. Если объект — готовое сетевое соединение, то он собственно уже готов, его осталось обернуть в RAII. Переделать код с синхронного на асинхронный — это все равно все к чертям переписать, и RAII там тоже нужен, но по-другому)
Компиляции тоже нужны, тем более эта выполнена качественно. Мне бы эта статья лет этак 8 назад весьма бы подсократила мой (ныне оставленный) путь C++ программиста
Да, я тоже из возвращенцев)
ОКР еще до кучи.
Вообще последние полгода приучаюсь мыслить на бумаге. Мы же задачи по математике в голове не решаем, бумажку берем. Так и здесь.
Да вполне терпимо стоит. По асимптотике функциональные структуры данных такие же, как и мутабельные. Зато параллелизм из коробки.
BigData еще.
И как это мешает бизнес-логику реализовать на чистых функциях, а ввод-вывод оставить грязным функциям? IO-монада, там, вот это все.
Лишний повод почитать структуры данных. Immutable hash trie (через который в ФП реализуются immutable массивы) решает проблему.
Зато есть Either (это в scala), Option и до черта всякого остального. Пропуск функции делать не нужно, монада сделает это за вас.
ФП плох потому, что в нем нет ООП)
Вообще есть до черта всего. Алгебраические типы данных. Coproduct-ы. Функторы. Аппликативные Фнукторы. Монады, в конце-то концов. Полугруппы, моноиды, группы. Этим всем вполне можно представлять объекты реального мира.
Это на уровне бреда. Вполне можно и последовательные вычисления организовывать, мешает-то кто?
И это прекрасно.
Отличается принципиально механизмом ввода-вывода и доступа к данным/
вот это для меня — новость. Пойду гуглить) У нас (сейчас я на scala) хоть и параллелится и асинхронится все влет, но автоматических средств нема
я может быть туплю, но мне показалось, что вы хотите вызвать в конструкторе виртуальные методы объектов-агрегатов. В этом случае — никаких ограничений. А вот вызов виртуального метода самого объекта из конструктора противоречит просто здравому смыслу, так как предполагает выполнение кода потомка до вызова его конструктора
Ну и позволю себе чуток уточнить по вашим пунктам)
1. На самом деле нельзя) Если вы хотите вызвать из конструктора/деструктора виртуальный метод, то вы хотите странного.
2. Альтернатива — предусмотреть неинициализированное состояние объекта и перед использованием проверять, прям как в C. Исключение — удобный механизм, но производительность — соглашусь, хреновая. Но на то оно и исключение, что это именно что исключительная ситуация. А кинете вы исключение из конструктора или из фабрики — не суть важно, в любом случае все недоинициализированное придется так или иначе подчистить.
3. Полностью согласен, если Destroy вызывается не из деструктора какого-нибудь объекта в каком-нибудь фреймворке)
4. Если объект — готовое сетевое соединение, то он собственно уже готов, его осталось обернуть в RAII. Переделать код с синхронного на асинхронный — это все равно все к чертям переписать, и RAII там тоже нужен, но по-другому)
Как-то так)