Как стать автором
Обновить

Комментарии 26

А мне нравится такая запись:


ImageSets(
    inCircle = true,
    needFit = true,
    defaultDrawableResource = 0
).let { print(it) }

Приятно читать :)

Тогда уже)
ImageSets(needFit = true).apply{ print(needFit) }

На самом деле можно много чего разного дописать, но я не стал, чтобы не получилось слишком скомкано
Я уже было подумал, что хорошее начало статьи, когда она закончилась.
Скоро будет продолжение) Немного вбок, но тем не менее)
Такими статьями вы только отпугиваете желание других людей смотреть в сторону Kotlin. Мне нравится этот язык, и я считаю его прекрасным инструментом для решения повседневных задач, но то что вы привели это не аргументы. Тот же lombok убирает весь ненужный код, и получается что с ним и Kotlin не нужен?
Дело в том что в Kotlin куда больше прекрасных возможностей для написания красивого и выразительного кода, а читая такие посты у читателей будет создаваться именно негативное впечатление.
Есть такая поговорка — «нет еще задачи по программированию, которую нельзя решить на ассемблере».
Я не утверждаю, что Kotlin — язык, на который непременно нужно полностью перейти с Java. Это личный выбор каждого разработчика. Если для выполнения задач человеку хватает Java — почему нет? Более того, сама парадигма котлина о совместимости с явой — утверждает то же самое.
Lombok сам по себе весит 1400кб, значительно увеличивает время сборки, а так же сложность самого проекта. О влиянии на скорость работы конечного кода не знаю, но подозреваю, что тоже влияет. Kotlin предоставляет тот же функционал, но уже из коробки, гораздо меньшими средствами. Разве это не хорошо?
НЛО прилетело и опубликовало эту надпись здесь

Геттер/сеттер и поле на байткоде уж точно есть.

НЛО прилетело и опубликовало эту надпись здесь
А можно пруфы по времени сборки эквивалентного кода на:
  • Чистой Java
  • Java + Lombok
  • Kotlin

Просто по моему это слишком сильное утверждение, ну и да байткод полученный с использование Lombok насколько я понимаю полностью эквивалентен коду с использованием бойлерплейта.
PS: в следующий раз буду читать комментарии ниже, что бы не дублировать.
Есть сравнение чистой java и kotlin
habrahabr.ru/company/badoo/blog/329026
При инкрементальной сборке kotlin быстрее. Сомневаюсь, что при добавлении lombok проекты на java будут собираться быстрее.
Чистой Java
Kotlin

тут и тут посмотрите.

Статья ни о чём. О какой защищённости речь? Примеры и на джаве и на котлине на уровне "начал чего-то учить, решил написать статью".

Для чистой Java есть прекрасная библиотека lombok. Ваш длиннющий пример превращается в что-то подобное:


@Data
@Builder
public class ImageSets {
    Boolean inCircle = false;
    Boolean needFit = false;
    Size size = null;
    int defaultDrawableResource = -1;
}
Все верно. Я выше уже написал, что все, что есть в Kotlin, есть и в Java, в виде той или иной библиотеки. Вопрос в цене — вес, время сборки, быстродействие.
Так и котлин отчасти сторонняя библиотека к яве. А по поводу быстродействия, и времени сборки, еще непонятно что быстрее будет java + lombok или котлин, если вы конечно не готовы поделиться ссылочкой на тесты.
Kotlin это никак не библиотека к Java. Безусловно, он выполняется на JVM, но по поводу библиотеки — это большое заблуждение. Более подробно уже 5 лет назад разжевывалось
habrahabr.ru/post/150104
Могу поделиться замерами, что Kotlin по умолчанию собирается быстрее Java
habrahabr.ru/company/badoo/blog/329026
Тут уже было обсуждение.
Я думаю, не стоит объяснять, почему время сборки Java с подключением lombok будет определенно больше, чем на голой java.
По личным наблюдениям, занимаюсь обоими языками, Kotlin существенно быстрее.
Простите, наоборот, не по умолчанию, а при инкрементальной сборке. Не успеваю поправить.
Kotlin это никак не библиотека к Java

Только 50% языка это расширеные классы стандартной ява библиотеки. Со своим компилятором, а дальше называйте как хотите)
а как же nullability на уровне системы типов?
Только 50% языка это расширеные классы стандартной ява библиотеки

Где-то есть статистика?
Котлин опенсоурс, откройте его на гитхабе и гляньте если интересно.
Опять статья из разряда, смотрите в котлине нету точек с запятыми буквально на днях был точно такой пост. Всем кому действительно нужны фичи из котлин, на него перейдут и без таких статей, а это все больше и больше продолжает смахивать на какуюто дешевую рекламу.
Я постарался в первом абзаце описать ситуацию, которая сподвигла меня написать эту статью. Очень жаль, что вы видите статье именно рекламу.

Пару слов в защиту Котлина:


Дизайн джавы стар! Многие механизмы давно вросли в языки (свойства, экстнешены, иммутабельность, нулабилити).


Изза старого дизайна не срослось с выводом типов (даймонд синтакс) и вариантностью (in/out удобнее чем вилдкардс), не получилось убрать треугольные скобочки.


Ребята из JetBrains, вроде как много лет непосредственно работают с JVM делайя шустрый комплишн для идеи. Не мало знают о и ее компиляторе, и о дестятке других в придачу (есть из чего выбирать фичи).


Можно псиать библиотеки в рамках старого дизайна (обвешать все аннотациями, и навставлять треугольных скобочек друг в друга), а можно написать свой язык, используя накопленные знания и опыт. А за 6 лет разработки уж наверняка


Не нужно держаться за старое, а если и нужно, то 100%-ный интероп вам поможет :)

Ваш пример с буленовскими флажками под каждое свойство и нуллабл полем — признак нарушения single resposibility. Я бы использовал другую крутую возможность котлина — sealed class и сделал бы несколько вариантов картинок, которые используются конкретно в проекте. Бонусом будет использование конструкции when для обработки всех возможных вариантов изображений в проекте, проверяемое на этапе компиляции

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.