Конечно, вы правы в том, что использование thenApplyAsync без специфичного Executor кажется избыточным. Однако, стоит понимать, что демонстрация асинхронных возможностей Java с помощью CompletableFuture в данном случае была направлена на показ возможностей языка, а не на идеальную оптимизацию производительности. Не каждый пример должен быть прямым указанием к действию, иногда это просто демонстрация возможностей.
Что касается вашего комментария о Kotlin и использовании withContext — да, конечно, можно всё сделать проще и понятнее, если использовать GlobalScope.async. Тем не менее, использование различных контекстов исполнения служит для показа гибкости корутин. Мне показалось это очевидным, тк заголовок называется Цепочка многопоточных вычислений, что предполагает понимания причин происходящего.
Категорически не согласен. Мне кажется, что это вредный совет. Если на крутого специалиста, который занимается публичной деятельностью это и может сработать, то для мидл/джунов нет. Вот приходит мне пачка резюмех мидлов (которые предварительно отсеил hr) и я понимаю, что не смогу всех прособесить, надо отсеить лучшие. Я же не буду писать уточняющие вопросы каждому кандидату. Поэтому резюме очень сильно решает. Кроме того, если hr написала кандидату, то совершенно не факт, что специалист согласится прособесить и тем более взять кандидата. Между тем как написала hr и взяли на работу пропасть, которую было бы не плохо заполнить чем-то.
Ну модули можно наследовать импортом, динамика типов даёт полиморфизм, ну и приватные методы и переменные тоже можно делать (на сколько это допустимо в языке). Я мог бы написать пример, но обучение вас питону не входит сейчас в мои планы. :)
Откройте почти любую документацию и вы увидите там игрушечные примеры. Так же и здесь. Просто вы не разобрались с материалом. А доказывать, что в Java нет kind'ов мне надоело. :)
Я возможно вас удивлю, но существует не только Энтерпрайз разработка. Например, в разработке под МК постоянные аллокации памяти часто нежелательны. Поэтому там редко делается выбор в сторону C++.
Классы только код тормозят и ещё по памяти дорогие.
Писать плохой код всегда дорого.
Эмммм… В С вообще нет классов и для многих задач это является оптимальным решением. Не очень понял как это связано с плохим кодом. Вообще, складывается впечатление, что вы называете плохим кодом все в чем не разобрались. Помимо ООП есть ещё много хороших практик, которые могут упростить поддержку.
Конечно! Можно писать такие приложения и на С. Посмотрите на JVM. :)
У меня есть знакомые, которые после работы на C/Python вообще не понимают зачем нужно ООП. Ведь можно и на основе модулей и без классов строить поддерживаемые приложения. Классы только код тормозят и ещё по памяти дорогие.
Вопрос не в можно/нельзя, а на сколько просто решается та или иная задача. Например, я бы не взял с собой Java при написании приложения на акторах. Ведь пользоваться Scala с Akka гораздо более приятно.
Конечно, вы правы в том, что использование
thenApplyAsyncбез специфичногоExecutorкажется избыточным. Однако, стоит понимать, что демонстрация асинхронных возможностей Java с помощью CompletableFuture в данном случае была направлена на показ возможностей языка, а не на идеальную оптимизацию производительности. Не каждый пример должен быть прямым указанием к действию, иногда это просто демонстрация возможностей.Что касается вашего комментария о Kotlin и использовании
withContext— да, конечно, можно всё сделать проще и понятнее, если использоватьGlobalScope.async. Тем не менее, использование различных контекстов исполнения служит для показа гибкости корутин. Мне показалось это очевидным, тк заголовок называется Цепочка многопоточных вычислений, что предполагает понимания причин происходящего.Спасибо за своевременный комментарий!)))
Категорически не согласен. Мне кажется, что это вредный совет. Если на крутого специалиста, который занимается публичной деятельностью это и может сработать, то для мидл/джунов нет. Вот приходит мне пачка резюмех мидлов (которые предварительно отсеил hr) и я понимаю, что не смогу всех прособесить, надо отсеить лучшие. Я же не буду писать уточняющие вопросы каждому кандидату. Поэтому резюме очень сильно решает. Кроме того, если hr написала кандидату, то совершенно не факт, что специалист согласится прособесить и тем более взять кандидата. Между тем как написала hr и взяли на работу пропасть, которую было бы не плохо заполнить чем-то.
Я и не смел надеяться :)
Откройте почти любую документацию и вы увидите там игрушечные примеры. Так же и здесь. Просто вы не разобрались с материалом. А доказывать, что в Java нет kind'ов мне надоело. :)
То есть, если я получаю optional с результатом запроса из базы, то мой код плох и надо было в случае отсутствия информации возвращать null?
А да, ещё же старый добрый js с замыканиями вместо классов. :)
Не понял вашу мысль (
Модули в Python
Я возможно вас удивлю, но существует не только Энтерпрайз разработка. Например, в разработке под МК постоянные аллокации памяти часто нежелательны. Поэтому там редко делается выбор в сторону C++.
Ну так, а что вы ответите про Optional или асинхронные вычисления??? :)
ООП не про классы, а про объекты :)
Эмммм… В С вообще нет классов и для многих задач это является оптимальным решением. Не очень понял как это связано с плохим кодом. Вообще, складывается впечатление, что вы называете плохим кодом все в чем не разобрались. Помимо ООП есть ещё много хороших практик, которые могут упростить поддержку.
Тогда уж Elixir :)
Конечно! Можно писать такие приложения и на С. Посмотрите на JVM. :)
У меня есть знакомые, которые после работы на C/Python вообще не понимают зачем нужно ООП. Ведь можно и на основе модулей и без классов строить поддерживаемые приложения. Классы только код тормозят и ещё по памяти дорогие.
Вопрос не в можно/нельзя, а на сколько просто решается та или иная задача. Например, я бы не взял с собой Java при написании приложения на акторах. Ведь пользоваться Scala с Akka гораздо более приятно.