Классы только код тормозят и ещё по памяти дорогие.
Писать плохой код всегда дорого.
Эмммм… В С вообще нет классов и для многих задач это является оптимальным решением. Не очень понял как это связано с плохим кодом. Вообще, складывается впечатление, что вы называете плохим кодом все в чем не разобрались. Помимо ООП есть ещё много хороших практик, которые могут упростить поддержку.
Конечно! Можно писать такие приложения и на С. Посмотрите на JVM. :)
У меня есть знакомые, которые после работы на C/Python вообще не понимают зачем нужно ООП. Ведь можно и на основе модулей и без классов строить поддерживаемые приложения. Классы только код тормозят и ещё по памяти дорогие.
Вопрос не в можно/нельзя, а на сколько просто решается та или иная задача. Например, я бы не взял с собой Java при написании приложения на акторах. Ведь пользоваться Scala с Akka гораздо более приятно.
Никто же не говорит, что на скале все круче. Мне, например, дико не нравится sbt. Кроме того, меня самого устрашают сервисы, которые делаеют долго и упорно на скале, но которые могли бы появиться по щелчку пальцев на спринге. Тут все зависит от задачи.
Мне показалось очевидным странность сложения двух чисел в отдельном потоке. Одно выделение времени планировщика будет дороже. Представьте, что внутри более сложные операции, которые выполняются асинхронно. Ну, например, у нас в методе не сложение, а логика вызова 20 других сервисов, а ваше приложение под нагрузкой. Вряд ли вы захотите возвращать просто результат выполнения. Наверняка вы будете внутри проводить манипуляции с фьючерами и в итоге вернете фьючер для максимальной нагрузки ЦП без простоя на IO. Нет?
Ну или можете заменить CompletableFuture на Optional, если вы совсем придирчивы. Можем даже придумать требование: возвращение empty, если сложение привело к битовому переполнению.
Во-первых, здесь я хотел показать, что так можно в принципе. При простом сложении такого точно не нужно. Вы слишком цепляетесь к конкретному небольшому примеру, но не видите сути.
Во-вторых, вы же согласны, что возращать контейнеры типов можно и это нормально? Тот же Optional.
Ну хорошо, представим, что так. Но ведь где-то вы будете оборачивать вызов метода во фьючер? И если у вас асинхронный код, то наверняка вы заходите из каких-то методов возвращать фьючу, ну или хотя бы использовать?
Привет! Статья совсем не про python и не про языки программирования. Изначально я хотел написать примеры на Java, но получилось как-то много специфичного для языка (например, проверяемые исключения). Спасибо за замечание.
можно ли обосновать, для чего конкретно мало, и как vavr это решает?
Действительно стоило пояснить. Мало для написания программ в функциональном стиле. Далее разбирается почему (например, базовые структуры для этого непригодны).
это весьма странное утверждение, совсем далекое от правильного определения persistent структуры («структуры, которые при модификации сохраняют все свои предыдущие состояния и ссылки на них эти состояния будут оставаться полностью работоспособными» или как-то так)
Здесь я попытался по-простому написать то, что вы описываете. Но я согласен, что ваше опеределение более формально и, скорее всего, подходит лучше. Поменяю. :)
Эмммм… В С вообще нет классов и для многих задач это является оптимальным решением. Не очень понял как это связано с плохим кодом. Вообще, складывается впечатление, что вы называете плохим кодом все в чем не разобрались. Помимо ООП есть ещё много хороших практик, которые могут упростить поддержку.
Тогда уж Elixir :)
Конечно! Можно писать такие приложения и на С. Посмотрите на JVM. :)
У меня есть знакомые, которые после работы на C/Python вообще не понимают зачем нужно ООП. Ведь можно и на основе модулей и без классов строить поддерживаемые приложения. Классы только код тормозят и ещё по памяти дорогие.
Вопрос не в можно/нельзя, а на сколько просто решается та или иная задача. Например, я бы не взял с собой Java при написании приложения на акторах. Ведь пользоваться Scala с Akka гораздо более приятно.
Ну или можете заменить CompletableFuture на Optional, если вы совсем придирчивы. Можем даже придумать требование: возвращение empty, если сложение привело к битовому переполнению.
Суть от этого не меняется, но пример усложняется.
Во-вторых, вы же согласны, что возращать контейнеры типов можно и это нормально? Тот же Optional.
Действительно стоило пояснить. Мало для написания программ в функциональном стиле. Далее разбирается почему (например, базовые структуры для этого непригодны).
Здесь я попытался по-простому написать то, что вы описываете. Но я согласен, что ваше опеределение более формально и, скорее всего, подходит лучше. Поменяю. :)
Не могли бы вы уточнить вопрос про реоупены?)