не напоминает. Совсем. Однострочники на perl'е тем и примечательны, что в них ничего не понятно для не perl программистов. В этом примере понятно всё(даже мне, незнакомому с питоном). Код намного более наглядный чем предложенный в статье.
Но я это пишу к тому, что если уж и учить что-то новое, то для себя я лучше разберусь в том, как кешируются данные в Hibernate
я занимаюсь проектом на java, немного знаю haskell. С уверенностью могу сказать, что мне проще разобраться как работает какой-нибудь persistent или slick, чем hibernate.
Многие требуют какой-то невероятной подготовленности к production для новых/непривычных инструментов. При это на сырость привычных инструментов закрывают глаза.
Будь моя воля, как разработчика на java — я бы никогда hibernate в production не пропустил. Т.к. это библиотека, как не парадоксально, для него не готова. И, судя по всему, не будет готова никогда =)
>F# победил с большим отрывом от всех.
а можно краткое пояснение причин? Чем он лучше haskell, scala? Вы пишите на F# промышленный код? Интересно узнать именно с точки зрения готовности для прода.
Сразу скажу, что можно любой формат вывода сделать, здесь используется стандартный Show.
Если есть вариант реализовать подобное не каким-то магическим способом, а средствами языка — то почему нет? Но встраивать подобную конструкцию в язык точно не стоит.
В контексте сравнения функционального и процедурного программирования — это про стиль.
т.е. в ходе сравнения двух парадигм, вы пришли к выводу, что отличие только в стиле? Или как это понимать?
Декларативное и императивное программирование — это вообще отдельно, касается ООП и функциональщины в равной степени.
ФП это декларативная парадигма программирования, ООП — императивная. Как видите, далеко не «в равной степени».
И ООП гораздо ближе к процедурному подходу, чем ФП.
На самом деле там более обширный инструментарий. ФП языки, как правило, имеют хорошие возможности для создания DSL, которые в дальнейшем и используются для описания предметной области. Плюс позволяют гораздо более точно управлять контекстом исполнения, предоставляя гарантии там, где при императивно-ОО подходе приходится довольствоваться соглашениями.
В хаскеле — язык позволяет так делать, но это не рекомендуется. В скала все проще, насколько я понимаю. Там тайпклассы эмулируются через implicit. И уже правила разруливания implicit помогают выбрать конкретный инстанс тайпкласса.
Ничего не могу сказать, тк за все время я ни разу не использовал BigDecimal и не могу сказать это плохо не плохо, есть ли что то оборачивающее в более наглядный вид или нет.
а я использовал, и могу сказать что это однозначно плохо. Тем более Java позиционируется как Enterprise решение, при этом не подходит для точных расчётов(обычно так считают деньги).
так и говорю что я не хочу чтобы у меня стандартный класс на каждом проекте магическим образом обрастал разными методами в каждом проекте.
как бы от простого математического выражения не отличается. Если очень сильно глаза зажмурить
А вот это тоже на мой взгляд не надо делать
Это не только со Flux работает. Как видно из примера на kotlin — там вообще никакого Flux не понадобилось. А `as`- дополнительное усложнение в Java коде, и без того не маленьком.
А писать? вместо map уже мелочь.
А Вы попробуйте сначала язык — поймёте, что различие далеко не в паре символах. Простыни Java кода с разными кастомными наворотами, превращаются во вполне каноничный kotlin код. Плюс всякие удобные штуки для dsl, корутины опять же. Я, как бэкендщик, вижу кучу преимуществ, и с радостью бы использовал этот язык в нашем проекте, если бы была возможность.
тогда ок. А как Вы решаете, когда использовать Lombok аннотации вроде Nullable, а когда использовать Optional?
Мне обилие? и ?: ну вообще не заходит. Я и в джава x ?y:z не люблю пользоваться.
А мне очень заходит, особенно для цепочек вложенных значений вроде
foo?.bar?.baz?.someField?.etc
Так же всегда можно придумать код который будет использовать операторы от Flux/Mono и которых нет в Котлине и наоборот, как в приведеном примере filterIsInstance
Придумать можно. А в котлине можно ещё и самому этот метод добавить, не меняя Flux(что-бы всё было в единообразном fluent стиле).
Да это так, я проводил много интервью и люди со стримами не могут совладать, пишут такую жуть. Так что им и Котлин не поможет.
Только у Вас даже на таком небольшом участке кода — NPE(scriptBaseDir по условиям задачи — nullable).
И да, оригинальный код — не самый понятный, вот вариант получше:
Сравните — котлин со стандартной библиотекой выигрывает как по читаемости, так и по объему кода в два раза. Понимаю, если у Вас небольшая кодовая база — но для крупного проекта это очень большая разница.
А Flux, как и Lombok — это не стандарт, и Ваш код вполне может вызвать вопросы у рядового Java программиста.
Удивляет такое. Это не Java, это другой язык. Естественно, человеку, не использующему этот язык, будет сложно читать код на нём. Вы же не думаете, что Java легко читать всем? Как читать цепочки вызовов методов в BigDecimal, когда все привыкли к операторам?
А код на java будет выглядеть как-то так:
List<FileScriptSource> importedSources = annotations.stream().flatMap(it -> {
if (it instanceof Import) {
var paths = ((Import) it).getPaths();
return paths == null ? Stream.empty() : paths.stream().map(sourceName -> {
var dir = scriptBaseDir == null ? null : scriptBaseDir.resolve(sourceName);
if (dir == null)
dir = new File(sourceName);
return new FileScriptSource(dir);
});
} else
return Stream.empty();
}).collect(toList());
Намного понятнее стало? По моему нет, это надо в отдельный метод выносить(в java, в kotlin и так понятно). И так везде, вот вам и экономия в «пару строк». В пару строк на квадратный сантиметр, разве что.
Экосистема — это во-первых, сторонние библиотеки и фреймворки. Многие из них сильно заточены под джаву, а не котлин
Это заблуждение. Библиотеки, заточенные под котлин — да, лучше работают на котлин. Остальные — так же, как на Java. За очень редким исключением, ведь язык создавался именно под такой кейс использования.
на джаве не сильно больше букав писать приходится, особенно с поддеркой IDE.
Сильно больше букав. Никакая IDE вас не спасёт от чтения килотонн boilerplate и не завезёт в язык перегрузку операторов и прочие полезные вещи.
Ну вот вы как себе представляете null-safety в языке, так чтобы не пересобирать ничего? Кроме своего кода, может быть. Вот вы вызвали чей-то метод, и он вернул null. Чей-то метод написан на Java 6, и скомпилирован Java 8, например. И что будет?
Тут надо подумать. Можно сделать опционально включение null-safe по умолчанию для проекта, модуля, пакета или классов. Или отдельно обозначать параметры как null-safe.
Конечно, это не простое дело, я не спорю. Но в тот же C#, например, завезли(насколько я знаю), можно у них подсмотреть.
Но я согласен, что даже при большом желании завтра null-safe в Java не появится. На его внедрение потребуется очень много времени, и проекты будут переезжать очень долго.
Я таки думаю, что нет. Но скорее сидят и думают — а какие именно фичи нам сделать в следующем релизе? И вот тут уже выбор становится не таким очевидным.
Думаю тут проблема скорее в сложности фичи относительно других. А так — вещь вполне себе важная, в новую Java даже улучшенные сообщения об NPE завезли.
Модули в Java 9 сломали очень много всего, поэтому в частности хадуп до сих пор не может очухаться от этого изменения
Да, тут согласен. Модули важная причина, осложняющая переход.
Невозможность внедрить в Java 8 что-либо? Да ладно.
Не так прочитал, извиняюсь. Думал речь о Java вообще. Насчёт Java 8 Вы правы.
С другой стороны почему вообще выпуски языка привязаны к платформе? Почему бы не сделать как в котлине — отдельно язык, отдельно платформа? Но это уже к ораклу вопросы.
Плюс есть jooq, который сильно упрощает написание запросов. А запросы писать придется в любом случае, даже с hibernate.
Многие требуют какой-то невероятной подготовленности к production для новых/непривычных инструментов. При это на сырость привычных инструментов закрывают глаза.
Будь моя воля, как разработчика на java — я бы никогда hibernate в production не пропустил. Т.к. это библиотека, как не парадоксально, для него не готова. И, судя по всему, не будет готова никогда =)
а можно краткое пояснение причин? Чем он лучше haskell, scala? Вы пишите на F# промышленный код? Интересно узнать именно с точки зрения готовности для прода.
Вывод:
Сразу скажу, что можно любой формат вывода сделать, здесь используется стандартный Show.
Если есть вариант реализовать подобное не каким-то магическим способом, а средствами языка — то почему нет? Но встраивать подобную конструкцию в язык точно не стоит.
ФП это декларативная парадигма программирования, ООП — императивная. Как видите, далеко не «в равной степени».
И ООП гораздо ближе к процедурному подходу, чем ФП.
В хаскеле — язык позволяет так делать, но это не рекомендуется. В скала все проще, насколько я понимаю. Там тайпклассы эмулируются через implicit. И уже правила разруливания implicit помогают выбрать конкретный инстанс тайпкласса.
Ну так и не надо путать. Время это, как раз, не пространственная координата пространства-времени.
как правило, так и не происходит.
Ну да, и код вида
как бы от простого математического выражения не отличается. Если очень сильно глаза зажмурить
Это не только со Flux работает. Как видно из примера на kotlin — там вообще никакого Flux не понадобилось. А `as`- дополнительное усложнение в Java коде, и без того не маленьком.
А Вы попробуйте сначала язык — поймёте, что различие далеко не в паре символах. Простыни Java кода с разными кастомными наворотами, превращаются во вполне каноничный kotlin код. Плюс всякие удобные штуки для dsl, корутины опять же. Я, как бэкендщик, вижу кучу преимуществ, и с радостью бы использовал этот язык в нашем проекте, если бы была возможность.
А мне очень заходит, особенно для цепочек вложенных значений вроде
Придумать можно. А в котлине можно ещё и самому этот метод добавить, не меняя Flux(что-бы всё было в единообразном fluent стиле).
согласен.
И да, оригинальный код — не самый понятный, вот вариант получше:
Сравните — котлин со стандартной библиотекой выигрывает как по читаемости, так и по объему кода в два раза. Понимаю, если у Вас небольшая кодовая база — но для крупного проекта это очень большая разница.
А Flux, как и Lombok — это не стандарт, и Ваш код вполне может вызвать вопросы у рядового Java программиста.
А код на java будет выглядеть как-то так:
Намного понятнее стало? По моему нет, это надо в отдельный метод выносить(в java, в kotlin и так понятно). И так везде, вот вам и экономия в «пару строк». В пару строк на квадратный сантиметр, разве что.
Конечно, это не простое дело, я не спорю. Но в тот же C#, например, завезли(насколько я знаю), можно у них подсмотреть.
Но я согласен, что даже при большом желании завтра null-safe в Java не появится. На его внедрение потребуется очень много времени, и проекты будут переезжать очень долго.
Да, тут согласен. Модули важная причина, осложняющая переход.Не так прочитал, извиняюсь. Думал речь о Java вообще. Насчёт Java 8 Вы правы.
С другой стороны почему вообще выпуски языка привязаны к платформе? Почему бы не сделать как в котлине — отдельно язык, отдельно платформа? Но это уже к ораклу вопросы.