вот, спасибо

Думал я один такой, ан нет, Почему с каждым месяцем в котлине все меньше и меньше кода становится? скоро одним слово весь класс заменят

взять например return, почему его убирает студия? чем 6 букв помешали JetBrains?

Статья в пору для условного Лурка.
Статья плохая (как минимум, выкладка претензий).

А комменты? почитайте комменты

Не хотите убирать - не убирайте. Студия делает подсказки как писать более идиоматичный код в некоторых случаях

Солидарен с автором вот этого

> Тут можно много о чем спорить, но большинство ваших негодований выглядят притянутыми за уши либо звучат как «смотрите какой быдлокод я могу написать, а язык не мешает».

Вы, конечно, извините, но кто ж мешает писать по-человечески? Вроде именования переменных в блоках и прочего такого?

Именно

лишний код. Котлин придумали что упростить код. Но они его упрощяет насотлько, что в обычном Гите тупо трудно понять что делает код.
Да и тормоза постоянные с Intellsense из - за этого. Раньшеб ыло лучше

let явно короче if со сравнением нулл, а если вы еще и умеете различать let и also (ну вдруг повезло), то let станет внезапно меньше

Попробуйте Flutter + Dart. Возможно, вам подойдет больше, если очень привыкли к синтаксису Java.

Как пишите, дэс:)

Мне проще понимать код на Kotlin, т.к. он более выразителен.

Позвольте спросить про ваш опыт?

против let ничего против не имею. Но вот против return бомбит.

@toadsD разбирал по пунктам давно, но если вкратце - Чирухин одновременно даже не пытался разобраться и нарочно пытался набросить, что приводит к очень сомнительным аргументам.

Примечание - не сильно перечитывал, может по каким-то вопросам у меня мнение за это время поменялось.

>В Java ты чаще понимаешь по узкому контексту, что происходит. a = b — запись в поле или локал, a[1] = 2 — запись в массив. В Котлине за любым простым выражением может стоять сколь угодно сложный код из-за всяких умностей вроде перегрузки. Без IDE ничего не поймёшь. А IDE плохо, когда ты едешь в поезде и видишь, что свинговый жабоинтерфейс высасывает из ноутбука батарейку как вампир.

Относительно Java - да, мы теряем однозначность, но получаем лаконичность. Ввиду того, что в среднем случае все пишут в IDE (а также JB пропагандирует это), то решение логичное.
Относильно JVM-мира - стоит отметить, что набор возможных перегрузок строго ограничен, что позволяет меньше офигевать от абсолютной кастомности и неявности происходящего (привет Dynamic, implicit и ещё миллиарду фич из Scala!). Также весь набор неявностей хорошо поддерживается в IDE (и снова привет implicit)

>Котлин даёт одинаковый API для коллекций и сиквенсов, из-за чего люди злоупотребляют цепочками map/filter на коллекциях, создавая кучу промежуточных неленивых копий. Стримы в джаве специально введены для различия между ленивой и неленивой коллекцией. Да, есть инспекция в IDE для этого — потому что инспекции призваны исправлять недостатки языков.

Сравнение некорректно, т.к. в джаве для коллекций этих операций просто нету, что выглядит в среднем случае ужасно, т.к. набор из 1-2 операций ты вынужден делать либо на стримах, либо на циклах, что просто дико захламляет код:

list.stream().filter(i -> i > 5).collect(Collectors.toList())
vs
list.filter { it > 5 }

Насчёт проблемы самой по себе - она есть, но незначительна. Причин несколько:
1. Мы работаем в IDE.
2. Цепочку вызовов и глазами на ревью хорошо видно.
3. Консистентность апи очень помогает из-за того, что надо меньше думать о названиях.




>Кстати, об IDE. Насколько хороша поддержка Kotlin в IntelliJ IDEA? Она действительно лучше, чем для Java? Есть большие сомнения. Может быть, кому-то из JB хватит духу проадвокатировать по данному вопросу.

Примечание - я не из JB. На мой взгляд в среднем случае не уступает. Иногда мне может не хватать постфиксных шаблонов, но я их дописываю сам.



>Котлин форсит использование it, что приводит к нечитаемому коду. Что-нибудь типа seq.map { it -> foo(it, 1); }.map { it -> bar(it, 2); }.filter { it -> it.getBaz() > 0; }. Что это вообще было? Имена переменным даны не зря! А тут получается монолог вроде «Возьмём это, прикрутим к нему то, потом его закрутим и если оно стало больше того, то наденем сверху шарнир».

В целом - Немного непонятно, зачем it объявлен явно, а также поставлены точки с запятыми.
Относительно Java - мы получили дополнительную возможность, которую удобно юзать в коротких лямбдах (коими являются лямбды в твоём примере). Если будет становиться неочевидно - просто объявляешь параметр лямбды явно.
Относительно JVM-мира - в Груви тоже самое (оттуда и взяли), в Scala вообще '_', который победитель по возможной неочевидности.



>Цепочки вроде ?.let { foo(it); }?.let { bar(it); } — это вообще ад и должны быть запрещены в декларации о правах человека. И это считается идиоматично, Карл. В отличие от нормального if. Читать такой код невозможно.

Как упомянули уже в чате, с ссылками на методы ситуация резко меняется:
?.let(::foo)?.let(::bar)
Также стоит отметить, что никто не мешает использовать if, вывод типов внутри будет работать.
Ну и в среднем случае нету нужды в цепочках let (больше одного вижу почти никогда)



>От интеропа с джавой кровь идёт из глаз. А тут всякие JvmStatic и JvmName, и код превращается в цирк с конями.


Относильно Java:
Проблема есть и это логично, что она возникла, т.к. языки не совпадают.

Решения простые:
1. Забить на идеальный интероп
2. Проставлять
3. Возвращаться на джаву, если проставлять приходится слишком много

Проблема не такая большая (всё аннотировать не нужно, только стыки апи), как мне кажется.

Относительно JVM-мира: Ну, либо мы имеем те же аннотации (привет @throws(classOf[IOException]) из Scala), либо не имеем функционала, чтобы эти проблемы возникли. Ну или не имеем интеропа.

>Автоматические геттеры/сеттеры с добавлением английского слова get и первой буквой проперти в большом регистре (видимо, в локали ENGLISH? Ведь регистр букв системно-зависим) — это страшно.

Из статьи непонятно, что именно страшно. Ну, так принято стало в джаве, Котлин подстроился. Для котлина это выглядит даже нормально, т.к. функциональность получения-изменения проперти действительно можно поменять.



>Экстеншн-методы загрязняют публичный интерфейс такими вещами, о которых автор и подумать боялся.
>Работа экстеншн-методов возможна, даже если автор специально сделал финальный класс, явно показав, что не хочет сторонних расширений. Получается что-то вроде изнасилования с особым цинизмом. И конечно, они ломают совместимость: что будет, если в следующей версии библиотеки автор добавит методы с теми же именами, но с другим возвращаемым типом? Он должен думать обо всех экстеншн-методах, которые любые люди могут добавить в тот же класс?

Изнасилования нету, т.к. в кишки класса ты так не пролезешь. Просто скомпонуешь то, что в классе уже есть более удобным тебе образом.
Насчёт совместимости. С одной стороны проблема может стоять. С другой стороны, если составлять апи так, как предлагается в языке, то её скорее всего не будет. Причина (надеюсь, что тут не вру) - апи предлагают делать таким, чтобы в нём было только самое важное, а всякие красивости прикручивать снаружи. Так мы сможем подменять те куски, что нам не нравятся, не боясь за совместимость, так мы сможем не бояться того, что хочется новую штуку прикрутить, а твою либу уже активно юзают и изменение несовместимо.


>Библиотека местами не продумана. Например, reduce.
В целом:
Fold и Reduce - устоявшиеся конструкции в куче языков. Fold - свёртка элементов относительно какого-то заданного аккумулятора. Reduce - голова коллекции является стартовым элементом, поэтому свёртка будет относительно него. Могу врать, но в доке вроде всё есть.
Если есть другие примеры, то надо разбирать. То, что всё можно сделать лучше, никто не исключает.

Относительно JVM-мира - та же Scala этот набор методов имеет.

>Давайте ещё навалим про библиотеку. Нафига в стандартную библиотеку языка, который поддерживает дата-классы, включили пары? Это ж прямое поощрение плохого кода.

Наверное можно было бы попробовать обойтись, тут кроме того, что с ними быстрее, ничего не могу сказать.

UPD: есть некоторые методы, лаконичность которых теряется без пар. Пример - zip.



>Очень странный момент — возможность не указывать возвращаемый тип метода (особенно публичного).

Как пользователь IDE, с проблемами из-за этого не сталкивался, пока только лаконичность получал.
Но если такой стиль не нравится, то можно проектную инспекцию по указанию типа выставить в значение "Кричать ошибку" вместо "говорить о проблеме"



P.S. Очевидно, что некоторые фичи требуют каких-то жертв. Но, как мне кажется, это не сильно дикие жертвы за ту лаконичность, которые мы получаем.