Далеко ходить не надо - у меня тут проект, часть платежной системы, которую планируют заморозить потому что добавление новых фич стало занимать столько времени что на зарплаты уходит больше чем доходы с комиссий от клиентов. При этом количество клиентов не поменялось. То есть это на столько рядом что деньгами касается меня лично. А потому что сначала несколько лет писали как придётся потому что бизнес ждет уже вчера, а не было того кто сказал бы нет. Или того кто проактивно ввёл бы культуру разработки. Результат - прошли годы, добавление фичи выглядящей на три дня работы занимает два месяца, буквально.
В этом и проблема - забывают проверить, либо делают как в меме про и так сойдёт. А тут тебе компилятор скажет что есть шанс отстрелить пол-ноги, давай-ка решим этот вопросик.
Наоборот получалось обычно - была проблема с производительностью, я заходил, а там помимо всего прочего не редко массивы с пачкой данных копировались вместо модификаций, цепочки вызовов над массивами с преобразованиями, порождающими новые массивы и прочее такое. И вот когда в один проход переписывалось или с мутабельностью - скорость росла вот прямо по метрикам было видно. А кое-какой код вообще не работал в моменте, потому что бывает что полтора гигабайта json в приложение на nodejs заходит за раз без потока и там все способы работы привычные уже не способны существовать в принципе. Ну и конечно порождение квадратичных алгоритмов. В общем я видел некоторое волшебство и, конечно же, концепт иммутабельности решает множество проблем, меньше багов, но вот когда возводится идея в абсолют - потом приходится ходить и переписывать код.
Хаскелл в продакшене встречается на столько редко что пример не подходящий. И база данных не для всего решение. Потому что результат из базы тоже можно начать весело обрабатывать, вот половина проблем из моего опыта оптимизации тормозов - именно на этом этапе.
Второй — это иммутабельность, то есть отсутствие повторных присваиваний переменных и изменений существующих значений.
А потом чего это у нас код тормозит, надо серверов то добавить, да и базу подтюнить. И клиент как-то много памяти ест, но ничего, пользователь планочку памяти всегда может докупить.
Ох, как часто я встречал тормоза и неадекватное потребление памяти из-за того что выбрали иммутабельность как правило. И нет, не только потому что его готовить не умеют. Компьютер он абстрактно работать не умеет, там на дне нули и единицы и если ты их оставляешь лежать потому что иммутабельность - они так и лежат. Сборщик мусора, возможно их очистит. Возможно. Съев пачку тактов процессора на анализ. Впрочем, засорить можно и на том же Расте.
Если вы можете - никогда не используете иммутабельность, пожалейте других людей.
Он коверкает определение чистой функции, по сути, применяя её только с позиции публичных методов.
Ну вообще по ООП в идеале у тебя во вне смотрят публичные методы и свойства, а то что происходит внутри - оно на то и внутри. Просто не надо считать метод функцией, даже если в вашем языке программирования префикс fn, func или что-то подобное. Функция в объекте привязана к данным в объекте. А вот если она ходит куда-то во вне - вот это уже проблема и грязь, в контексте чистоты функций. Функциональное программирование и объекто-ориентированное это разные вещи. Конечно никто не мешает делать все методы у класса чистыми функциями, но тогда это модуль или неймспейс, а не класс в его основном понимании.
А чего бы нет? Сложнее понять - сложнее внедрять фичи - больше времени на разработку - больше расходы - расходы стали больше доходов. Не такая и редкость.
С одной стороны да, с другой смотря как именно это будет работать. Если кейс такой что для плейн текста будет плейн текст, а для остального специальный формат, то ещё ок. С другой стороны можно было и wordpad оставить тогда. Видимо идея в том чтобы одно приложение на две задачи, типа базовое редактирование текста и популярные фичи без излишеств, но побольше чем у просто текста, а для остального покупайте Office.
У меня правило - не обновляться на новую iOS/MacOS до выхода минимум первой версии минорных обновлений, ну и полгода должно пройти. И вот тогда всё хорошо работает и проблем нет. Вообще вроде как на все глобальные апдейты жаловались каждый раз, но потом основные баги фиксили и все всё забывали. Когда под линуксом был - примерно также поступал, да и с виндой. В общем хороший подход, рекомендую.
В северной части Московской области частенько включается белый список на мобильных операторах. Только Яндекс, Вконтакте и гос сайты работают. То есть белый список это реальность в пятидесяти километрах от Москвы. То есть вот уже.
Далеко ходить не надо - у меня тут проект, часть платежной системы, которую планируют заморозить потому что добавление новых фич стало занимать столько времени что на зарплаты уходит больше чем доходы с комиссий от клиентов. При этом количество клиентов не поменялось. То есть это на столько рядом что деньгами касается меня лично. А потому что сначала несколько лет писали как придётся потому что бизнес ждет уже вчера, а не было того кто сказал бы нет. Или того кто проактивно ввёл бы культуру разработки. Результат - прошли годы, добавление фичи выглядящей на три дня работы занимает два месяца, буквально.
К сожалению, это не единственный случай.
Согласен, можно сразу писать без багов. Непонятно, почему люди так не делают…
В этом и проблема - забывают проверить, либо делают как в меме про и так сойдёт. А тут тебе компилятор скажет что есть шанс отстрелить пол-ноги, давай-ка решим этот вопросик.
Наоборот получалось обычно - была проблема с производительностью, я заходил, а там помимо всего прочего не редко массивы с пачкой данных копировались вместо модификаций, цепочки вызовов над массивами с преобразованиями, порождающими новые массивы и прочее такое. И вот когда в один проход переписывалось или с мутабельностью - скорость росла вот прямо по метрикам было видно. А кое-какой код вообще не работал в моменте, потому что бывает что полтора гигабайта json в приложение на nodejs заходит за раз без потока и там все способы работы привычные уже не способны существовать в принципе. Ну и конечно порождение квадратичных алгоритмов. В общем я видел некоторое волшебство и, конечно же, концепт иммутабельности решает множество проблем, меньше багов, но вот когда возводится идея в абсолют - потом приходится ходить и переписывать код.
Хаскелл в продакшене встречается на столько редко что пример не подходящий. И база данных не для всего решение. Потому что результат из базы тоже можно начать весело обрабатывать, вот половина проблем из моего опыта оптимизации тормозов - именно на этом этапе.
А потом чего это у нас код тормозит, надо серверов то добавить, да и базу подтюнить. И клиент как-то много памяти ест, но ничего, пользователь планочку памяти всегда может докупить.
Ох, как часто я встречал тормоза и неадекватное потребление памяти из-за того что выбрали иммутабельность как правило. И нет, не только потому что его готовить не умеют. Компьютер он абстрактно работать не умеет, там на дне нули и единицы и если ты их оставляешь лежать потому что иммутабельность - они так и лежат. Сборщик мусора, возможно их очистит. Возможно. Съев пачку тактов процессора на анализ. Впрочем, засорить можно и на том же Расте.
Если вы можете - никогда не используете иммутабельность, пожалейте других людей.
Ну вообще по ООП в идеале у тебя во вне смотрят публичные методы и свойства, а то что происходит внутри - оно на то и внутри. Просто не надо считать метод функцией, даже если в вашем языке программирования префикс fn, func или что-то подобное. Функция в объекте привязана к данным в объекте. А вот если она ходит куда-то во вне - вот это уже проблема и грязь, в контексте чистоты функций. Функциональное программирование и объекто-ориентированное это разные вещи. Конечно никто не мешает делать все методы у класса чистыми функциями, но тогда это модуль или неймспейс, а не класс в его основном понимании.
А чего бы нет? Сложнее понять - сложнее внедрять фичи - больше времени на разработку - больше расходы - расходы стали больше доходов. Не такая и редкость.
Если ты не платишь - то товар это ты. Каждый выбирает своё.
С одной стороны да, с другой смотря как именно это будет работать. Если кейс такой что для плейн текста будет плейн текст, а для остального специальный формат, то ещё ок. С другой стороны можно было и wordpad оставить тогда. Видимо идея в том чтобы одно приложение на две задачи, типа базовое редактирование текста и популярные фичи без излишеств, но побольше чем у просто текста, а для остального покупайте Office.
Если бы я продавал роботов - я бы тоже также говорил.
Jetbrains решили своё ИИ делать, вот и не подружились.
Google+, попытка номер два. На базе ютуба поинтереснее чем кольца связи и прочее что там было.
Если после этого прилетите на дирижабле - то да.
Зависит от давления.
Слово «например» тут не переводится, это значение заголовка, иначе тогда нужно всё на русский транслировать.
Возможно авторы что-то знали.
Есть люди, которые и бетту ставят. Вообще в целом за последние 25 лет особо ничего не поменялось в процессах.
У меня правило - не обновляться на новую iOS/MacOS до выхода минимум первой версии минорных обновлений, ну и полгода должно пройти. И вот тогда всё хорошо работает и проблем нет. Вообще вроде как на все глобальные апдейты жаловались каждый раз, но потом основные баги фиксили и все всё забывали. Когда под линуксом был - примерно также поступал, да и с виндой. В общем хороший подход, рекомендую.
В северной части Московской области частенько включается белый список на мобильных операторах. Только Яндекс, Вконтакте и гос сайты работают. То есть белый список это реальность в пятидесяти километрах от Москвы. То есть вот уже.