Наивно думал, что под вечер быстро прочту пост о любимой игре, а тут прям как в нарнию нырнул =) Спасибо за подробнейший разбор и за организацию всего в одном месте!
Как-то вы лихо занизили Бауманцев =) По своему опыту могу сказать что после N лет всем все равно на то какой у тебя диплом и где что ты заканчивал. Но и даже если смотреть на диплом, в моем пузыре Бауманцев достаточно много в IT, и при приеме ни разу не встречал чтобы кто-то считал диплом Бауманки хуже чем МФТИ, ВШЭ и т.п.. Возможно немного предвзят из-за того что сам оттуда, но все же =)
Большие языковые изменения тяжело делать до выхода K2, иначе каждую из них придется делать 2 раза в обоих компиляторах. Но близится дата релиза, после нее, надеюсь, фичи будут активнее появляться.
Контейнеры это полумера. В них также можно передать null. На моей практике бывали и null переданные в Optional, и даже Some в котором лежал null (правда это было в Scala, но все же).
Nullable типы не про то, что вы никогда не поймаете NPE, это лишь более естественный механизм описания типов.
И он практично реализован в Kotlin. В рамках Kotlin кода без рефлексии тяжело поймать NPE, а все проверяется на уровне компиляции. Для всего того что приходит из Java кода полагаемся на аннотации (часть которых также понимает компилятор), а в крайнем случае возвращается платформенный тип.
Для всех публичных методов добавляется instristic на проверку not null типов. С приватными методами такой проверки нет, т.к. компилятор делает проверки на уровне компиляции.
Андрей Бреслав говорил, что посмотрят на то, как сделает Java и какие проблемы встретят. И если эта фича хорошо зайдет то тоже добавят в Kotlin аналогичное решение.
В IDEA нужно только включить "Enable annotation processing" и все должно работать точно также как в Java (так как механизм используется точно такой же). По крайней мере у себя я не помню, чтобы что-то дополнительно настраивал. Проект с gradle. Единственное что все gradle, kotlin и IDEA самые свежие. При запуске build запускается и annotation processing.
Вообще в IDE все настраивается и с kapt. Но в целом да, альтернатива annotation processors нужна и пока планируется что это будут компиляторные плагины.
Она медленее, но не в 10-20 раз как вы говорите. Работы по улучшению постоянно идут и новый большой скачек будет с релизом FIR.
Но местами можно и быстрее написать. Есть inline, tailrec, корутины. С боксингом действительно можно напороться, но это, пожалуй, единственное.
Мешает он, как правило, в тех местах, когда делаются такие хаки, как вы описываете. В таких местах можно вполне жить с!!! или чем-то аналогичным. Но зато nullability расширяет систему типов значительно упрощая код.
Есть такое, но в планах писали что package private появится.
Нет идеального решения, к сожалению. Final by default правильней, но исторически в java все было open и много существующих инструментов используют это.
почти каждая новая фича, которая появилась в Java недавно или вот-вот появится (в смысле, имеет активный JPE и обсуждается в рассылках) выглядит более продуманной, чем любая фича Kotlin.
Очень спорный аргумент. Новые фичи Kotlin также тщательно обсуждаются в рамках KEEP. А на счет "продуманности", скорее наоборот =). В существующий синтаксис Java сложно что-то добавлять, не ломая что уже есть. Посмотрите доклады Тагира (https://www.youtube.com/watch?v=qurG_J81_Cs) про то как встраивался pattern matching.
К тому же все, что появляется в Java никак не мешает Kotlin. Data class можно использовать с record. Как выйдет Valhalla то value классы тоже можно будет использовать.
Java будет и дальше развиваться, но языковые фичи (которых на самом деле не так и много) с трудом в нее попадают, а от улучшения jvm получают выгоду все jvm-языки.
Думаю, что в будущем Kotlin будет больше позиционироваться как Java 2.0, поддерживая все новые фичи, что появляются в Java и добавляя новый функционал поверх. Возможно в какой-то момент и настанет критическая точка что Java разойдется сильно с Kotlin, но ничего не мешает тогда появится Kotlin 2.0 c поддержкой миграции всего и вся из Kotlin 1.0. Kotlin ведь не Java, он может себе позволить куда более критичные изменения.
У нас не то чтоб времени было на все это много, да и в первую очередь решали более приоритетные проблемы =) На счет исправления сферичности тоже думали, но до нее руки не дошли да и не решало бы это всех проблем.
EfficientNet-B0 сеть должна неплохо работать на мобильны устройствах. С ее помощью можно посчитать вектора для картинок, и потом самому между векторами посчитать косинусное расстояние или L2.
Наивно думал, что под вечер быстро прочту пост о любимой игре, а тут прям как в нарнию нырнул =)
Спасибо за подробнейший разбор и за организацию всего в одном месте!
Как-то вы лихо занизили Бауманцев =)
По своему опыту могу сказать что после N лет всем все равно на то какой у тебя диплом и где что ты заканчивал.
Но и даже если смотреть на диплом, в моем пузыре Бауманцев достаточно много в IT, и при приеме ни разу не встречал чтобы кто-то считал диплом Бауманки хуже чем МФТИ, ВШЭ и т.п.. Возможно немного предвзят из-за того что сам оттуда, но все же =)
Большие языковые изменения тяжело делать до выхода K2, иначе каждую из них придется делать 2 раза в обоих компиляторах. Но близится дата релиза, после нее, надеюсь, фичи будут активнее появляться.
Будет интересно посмотреть на результаты. И еще было бы интересно в функциональном плане сравнить.
Спасибо за статью, интересный проект. А у вас есть какое-нибудь сравнение с Milvus? Особенно с его 2.0 версией?
Контейнеры это полумера. В них также можно передать null. На моей практике бывали и null переданные в Optional, и даже Some в котором лежал null (правда это было в Scala, но все же).
Nullable типы не про то, что вы никогда не поймаете NPE, это лишь более естественный механизм описания типов.
И он практично реализован в Kotlin. В рамках Kotlin кода без рефлексии тяжело поймать NPE, а все проверяется на уровне компиляции. Для всего того что приходит из Java кода полагаемся на аннотации (часть которых также понимает компилятор), а в крайнем случае возвращается платформенный тип.
deleted
Можно еще чуть улучшить:
Таможню и пограничников тоже на дирижабле пускать =)
Для всех публичных методов добавляется instristic на проверку not null типов. С приватными методами такой проверки нет, т.к. компилятор делает проверки на уровне компиляции.
Андрей Бреслав говорил, что посмотрят на то, как сделает Java и какие проблемы встретят. И если эта фича хорошо зайдет то тоже добавят в Kotlin аналогичное решение.
Придумывать еще одни имена для уже имеющихся переменных такое себе =)
В идеале бы, сделать чтобы был возможен и тот и другой вариант.
Например, можно было бы в Kotlin поддеражать такое:
Или можно сделать чтобы переменная неявно создавалась бы, если нужно (ну или явно, но опять же автоматом):
В IDEA нужно только включить "Enable annotation processing" и все должно работать точно также как в Java (так как механизм используется точно такой же). По крайней мере у себя я не помню, чтобы что-то дополнительно настраивал. Проект с gradle. Единственное что все gradle, kotlin и IDEA самые свежие. При запуске build запускается и annotation processing.
Сейчас появился еще один пример, Scala 2 => 3. Можно посмотреть что у них получится и сделать правильные выводы =)
Очень спорный аргумент. Новые фичи Kotlin также тщательно обсуждаются в рамках KEEP. А на счет "продуманности", скорее наоборот =). В существующий синтаксис Java сложно что-то добавлять, не ломая что уже есть. Посмотрите доклады Тагира (https://www.youtube.com/watch?v=qurG_J81_Cs) про то как встраивался pattern matching.
К тому же все, что появляется в Java никак не мешает Kotlin. Data class можно использовать с record. Как выйдет Valhalla то value классы тоже можно будет использовать.
Java будет и дальше развиваться, но языковые фичи (которых на самом деле не так и много) с трудом в нее попадают, а от улучшения jvm получают выгоду все jvm-языки.
Думаю, что в будущем Kotlin будет больше позиционироваться как Java 2.0, поддерживая все новые фичи, что появляются в Java и добавляя новый функционал поверх. Возможно в какой-то момент и настанет критическая точка что Java разойдется сильно с Kotlin, но ничего не мешает тогда появится Kotlin 2.0 c поддержкой миграции всего и вся из Kotlin 1.0. Kotlin ведь не Java, он может себе позволить куда более критичные изменения.
С hsv как раз и делали =)
https://github.com/evgzakharov/iddqd_playground Код написан в очень сжатые сроки, поэтому страшный местами.
А вот с углами идея интересная, спасибо!
У нас не то чтоб времени было на все это много, да и в первую очередь решали более приоритетные проблемы =) На счет исправления сферичности тоже думали, но до нее руки не дошли да и не решало бы это всех проблем.
Можно посмотреть на https://www.milvus.io/.
EfficientNet-B0 сеть должна неплохо работать на мобильны устройствах. С ее помощью можно посчитать вектора для картинок, и потом самому между векторами посчитать косинусное расстояние или L2.