отсутствие static (при переписывании некоторых моментов на котлин это самая большая боль)

отсутствие static (при переписывании некоторых моментов на котлин это самая большая боль)

top-level функции не спасают?

top-level функции не спасают?

Наверное имелось ввиду, что обходные пути найти то можно, а вот удобства это не добавляет

top-level функции не спасают?

ну там, где я статики переписывал, там имя класса + имя функции читабельность хорошую дают, так что не спасают

ну да, companion objects часто уродливо выглядят

override синим поначалу не нравилось, сейчас привык

раньше по коду с помощью желтых @Override проще было глазами бегать

массивы убрали static ::class.java arrayOf в аннотациях

final забыл

а что не так с массивами?

byteArrayOf, doubleArrayOf, intArrayOf, ...

final забыл

если ты о static final, то лично мне это как-то не очень нравилось визуально

Народ, а можно вбросить? Что вам больше всего НЕ нравится в котлине?) Такой себе топ

Лично меня не устраивает тулинг, каждую версию что-нибудь чинят и ломают новое...

На джаве куда удобнее писать только из-за того что там все стабильно работает

Лично меня не устраивает тулинг, каждую версию что-нибудь чинят и ломают новое...

Это потому что ты слишком давно видимо в котлине, у меня вот пока еще с тулингом все норм было

public по-умолчанию?

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

public по-умолчанию?

Да.

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

У меня местами бывает не происходит автоимпорта, но это очень редко + Alt-Enter все решает

Наоборот, хорошо что они убрали static.

отсутствие static (при переписывании некоторых моментов на котлин это самая большая боль)

А чем, интересно, это обусловлено, не знаете?

А чем, интересно, это обусловлено, не знаете?

Я не знаю, но, возможно, потому что нелогично внутри класса иметь функцию, которая этому классу не принадлежит

А так же статик противоречит парадигме ООП. И почти везде можно придумать как обойтись без статика.

Народ, а можно вбросить? Что вам больше всего НЕ нравится в котлине?) Такой себе топ

очень мееедленный плагин (анализ, автокомплит). на современной машине незаметно, но периодечески приходится работать на старом ноуте с кор2дуо. достаточно большой проект на джаве (10к строк, спринг, жпа, полный набор) шевелится еще терпимо, а на котлине даже с 1к строк начинается боль

очень мееедленный плагин (анализ, автокомплит). на современной машине незаметно, но периодечески приходится работать на старом ноуте с кор2дуо. достаточно большой проект на джаве (10к строк, спринг, жпа, полный набор) шевелится еще терпимо, а на котлине даже с 1к строк начинается боль

Ну так современный язык требует и современную машину )

А так же статик противоречит парадигме ООП. И почти везде можно придумать как обойтись без статика.

Ну вообще в котлине есть вещи которые противоречат ооп

Ну вообще в котлине есть вещи которые противоречат ооп

ну тут скорее зависит от стиля написания. В java тоже такие вещи имеют место быть.

А чем, интересно, это обусловлено, не знаете?

Статик торчит в те области видимости, в которые не стоило бы.

А так же статик противоречит парадигме ООП. И почти везде можно придумать как обойтись без статика.

используя утилитарный класс?

Статик торчит в те области видимости, в которые не стоило бы.

да, наверное резонно

используя утилитарный класс?

Утил-классы — процедурщина в чистом виде.

и как правило статика ))

очень мееедленный плагин (анализ, автокомплит). на современной машине незаметно, но периодечески приходится работать на старом ноуте с кор2дуо. достаточно большой проект на джаве (10к строк, спринг, жпа, полный набор) шевелится еще терпимо, а на котлине даже с 1к строк начинается боль

1.1.3?

Утил-классы — процедурщина в чистом виде.

И что вы решили вместо них обычные классы использовать?

И что вы решили вместо них обычные классы использовать?

Экстеншены же.

Нууу

Тоже процедурщина, только не уродливо.

В том-то и дело. Самообман)

Контекста не имеем так же

1.1.3?

Да

Ну вообще в котлине есть вещи которые противоречат ооп

Да котлин чистого ооп нигде и нет сейчас

раньше по коду с помощью желтых @Override проще было глазами бегать

File -> Settings -> Editor -> Colors & Fonts -> Kotlin -> Annotation

File -> Settings -> Editor -> Colors & Fonts -> Kotlin -> Annotation

в котлине override - не аннотация

в котлине override - не аннотация

а, черт, точно) просто у меня и аннотации были синими из-за Material Theme

а, черт, точно) просто у меня и аннотации были синими из-за Material Theme

у меня тоже аннотации почему-то по дефолту были синими, я их сразу же поменял

А можете высказать свое мнение: стоит ли (при условии неплохого знания плюсов и чистого си) начинать изучение не с java а прямиком с kotlin? Знакомому нужен совет, я даже не уверен, что бы стоит сказать

Igor В котлине ничего плохого нет. Он сочетает в себе много парадигм и классных фич из других языков. Особенность его также в том, что он использует JVM, тобишь джаву все равно учить придется так или иначе (структура данных и все вот это), но не синтаксис. Помимо этого еще на нем не очень много вакансий и зарабатывать здесь и сейчас сложно.

Если начинающий - однозначно java. Как уже сказали выше всё равно придётся с ней работать. К тому же информации и обучающих материалов для java больше.

Igor В котлине ничего плохого нет. Он сочетает в себе много парадигм и классных фич из других языков. Особенность его также в том, что он использует JVM, тобишь джаву все равно учить придется так или иначе (структура данных и все вот это), но не синтаксис. Помимо этого еще на нем не очень много вакансий и зарабатывать здесь и сейчас сложно.

Что значит не много вакансий?

на андроиде мало вакансий?

Что значит не много вакансий?

Буду рад ошибиться, потому что переход на него это топчик

на андроиде, да

Если начинающий - однозначно java. Как уже сказали выше всё равно придётся с ней работать. К тому же информации и обучающих материалов для java больше.

ага, спасибо, тогда буду советовать для начала жабу

по джаве книг много толковых

ага, спасибо, тогда буду советовать для начала жабу

Если что есть чатик для начинающих https://t.me/javastart

ага, спасибо, тогда буду советовать для начала жабу

Если андроид у него профильный будет, то да. Это скорее всего самый правильный вариант Если нет, то я бы на его месте учил котлин в обнимку с книжкой или статьми по джавовским коллекциям

Если андроид у него профильный будет, то да. Это скорее всего самый правильный вариант Если нет, то я бы на его месте учил котлин в обнимку с книжкой или статьми по джавовским коллекциям

Нет, человек решил вкатываться в разработку, из знаний только плюсы

если он плюсы знает, то можно и сразу в котлин

зная плюсы можно любой другой язык освоить быстро)

да, скорее всего это так) обычно если хватает сил на плюсы то на все остальное уже смотришь как на деткий сад)

угу

всё-же, минимально знать джаву будет не лишним. например, знать, во что компилится код, почему, когда делаешь switch-case по всем значениям enum-а, надо делать ветку для default, и пр.

всё-же, минимально знать джаву будет не лишним. например, знать, во что компилится код, почему, когда делаешь switch-case по всем значениям enum-а, надо делать ветку для default, и пр.

простите, а зачем делать default для switch-case по всем значениям енума? null что-ли?

Да уж свич кейс по енаму самое главное знание в джаве

это просто пример

это просто пример

да мне вот интересно стало почему я впервые слышу об этом? Так ответ - null хэндлить, или там оптимизация какая-то идет?

в enum можно будет добавить новое значение, при этом сохранится обратная совместимость

ERROR: S client not available

мм... забавно

"открытость для расширения" из OCP

А можете высказать свое мнение: стоит ли (при условии неплохого знания плюсов и чистого си) начинать изучение не с java а прямиком с kotlin? Знакомому нужен совет, я даже не уверен, что бы стоит сказать

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

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

Человеку по факту скорее для себя нужно освоить, он тоже студент первого курса, только в отличии от меня он еще ни разу не работал и только планирует вкатываться в разработку. А плюсы знает благодаря паре знакомых и МФТИ :)

всё-же, минимально знать джаву будет не лишним. например, знать, во что компилится код, почему, когда делаешь switch-case по всем значениям enum-а, надо делать ветку для default, и пр.

Зачем делать switch на enum? :)

Зачем делать switch на enum? :)

Фабрика?

что угодно

Зачем делать switch на enum? :)

Switch - это же по сути замена if. Неважно на чем его делать, если он вносит ясность и добавляет удобства. Так можно дойти "зачем switch, есть else-if" ))

Switch - это же по сути замена if. Неважно на чем его делать, если он вносит ясность и добавляет удобства. Так можно дойти "зачем switch, есть else-if" ))

Нет, можно наоборот сказать, «зачем if, если есть when?» Я говорю конкретно о switch/when на enum. Зачем?

Нет, можно наоборот сказать, «зачем if, если есть when?» Я говорю конкретно о switch/when на enum. Зачем?

А что такого? Непонятна суть твоего вопроса

А что такого? Непонятна суть твоего вопроса

Логику можно разместить в самих элементах enum'а.

Логику можно разместить в самих элементах enum'а.

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

If'у - if'ово, when'у - when'ово

Логику можно разместить в самих элементах enum'а.

а если enum - часть сторонней библиотеки?

логика в enum-ах - нарушение srp

логика в enum-ах - нарушение srp

Это как-то не совсем прослеживается, не могли бы вы пояснить?

Switch кажется вообще антипаттерн

Switch кажется вообще антипаттерн

Как же без него?

полиморфизм и гора if else

Нет гора if else не решает проблему и это тоже плохо

Вот нашел статью касательно вопроса https://refactoring.guru/ru/replace-conditional-with-polymorphism

Ключевая проблема if else и switch в том что никогда не знаешь сегодня у тебя 3 условия, завтра 4... 10... 110

а проблема в чем?

В том что ты всегда можешь получить огромное количество if else, который плохо читаетсяи допускаются ошибки

поэтому в котлине есть when)

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

error: incompatible types: NonExistentClass cannot be converted to Annotation Откуда может эта ошибка появляться на всех объявлениях даггеровских аннотаций? Причем такое только в версии 1.1.3

посмотри на другие ошибки компиляции

error: incompatible types: NonExistentClass cannot be converted to Annotation Откуда может эта ошибка появляться на всех объявлениях даггеровских аннотаций? Причем такое только в версии 1.1.3

Хм, перешел обратно на версию 1.1.2-3, все норм запустилось, перешел снова на версию 1.1.3, и тоже все норм сбилдилось... Магия...

В проекте ничего не менял, только версию котлина менял

вот и проблемы тулинга)

посмотри на другие ошибки компиляции

Других не было, было только штук 20-30 таких вот