Comments 64
— Если вы говорите «ява», то скажите мне, как произносится слово «job»?
Поэтому английские Джерри, джаз и прочие, уживаются в нашем языке с Юпитер, Юнкерс, Ява из немецкого скандинавских и других языков.
Вообще, откуда у наших программистов манера произносить слово java именно так, я не знаю. Немцы и норвежцы говорят «ява», потому что это обычное для них произношение. Испанцы говорят «хава» по той же причине. Ну и довольно странно выглядит, когда это слово именно пишут русскими буквами, потому что произношение — штука тонкая, не у всех оно идеально, а вот раскладку переключить в состоянии каждый.
Ну и довольно странно выглядит, когда это слово именно пишут русскими буквами, потому что произношение — штука тонкая, не у всех оно идеально, а вот раскладку переключить в состоянии каждый.
Потому что данное заимствованное слово получило достаточно широкое распространение. Это, насколько я понимаю, обычный этап развития языка — сначала слово используется в маскимально первозданном виде, но, постепенно, обрастает особенностями слов языка, такими как склонение например. Которые, кстати, для джавы тоже уже появились. И срач по поводу "правильного" написания/произношения — тоже часть интеграции слова в язык.
по сабжу
а еще какие нибудь метрики замеряли, хотя бы на глаз? например, правка багов, их поиск и т.д.
Во-вторых, некоторые новые (для Джавы) конструкции могут быть использованы во вред, в то время как на Джаве так написать попросту не получится
Можете написать поподробнее?
when (x) {
-1 -> ...//some fallback here
validate(x) -> print("ok")
anotherOptionToValidate(x) -> ...//some action again
else -> processSomeError(x)
}
такой вариант читаемости уже не добавляет, и нужно держать в уме, что код выполняется не только по правую сторону от стрелок, но и по левую, когда функции validate и anotherOptionToValidate содержат сайд эффекты получается просто ужасно.
Это не функциональный стиль программирования, это стремление создать запутанную конструкцию там, где она не нужна) Вопрос в понимании что такое ФП, а не в языке)
когда функции validate и anotherOptionToValidate содержат сайд эффекты
… то ваши проблемы совсем не в котлине
Что говорит о том что конструкция хороша, а не плоха, разве не так?
var someEnumValue = SomeEnum.VALUE;
when (someEnumValue) {
in SomeEnum.values() -> doAction()
someFunctionThatReturnsEnum() -> doAnotherAction()
}
Более того, он останется корректным, даже если убрать первое условие и оставить только вызов функции someFunctionThatReturnsEnum. Справедливости ради стоит отметить, что Котлин в таких случаях все-таки вежливо попросит сделать явное перечисление, но если мы не сделаем этого, или перечислим не все варианты, код останется корректным. Полнота проверяется компилятором, если when используется как выражение, а не как оператор, но тогда в нашем примере мы получим ложную ошибку и просьбу добавить else ветку, потому что компилятору «не известно» что SomeEnum.values() уже является полным вариантом.
Собственно, исходный посыл и был в том, что так писать не надо :)
Ага, лучший. Вы посмотрите как на нем pattern matching
запилили через switch
, break
инструкции в pattern matching
, где это видано? А inline
функции, с параметрами которые можно менять когда и как угодно… Я интересовался у одного из лидов roslyn, насчет, когда же они наконец запилят tail recursion
в шарпы, его отвел был — скорее всего никогда из за параллельной поддержки VB.
В Котлине по умолчанию все immutable, есть tail recursion
оптимизация и pattern matching
красиво выполнен, так что не сравнивайте бараньи тестикулы с северным сиянием.
Наоборот, все были только рады возможности применить новую крутую игрушку со всеми ее свистелками в продакшене.
так себе причина.
Я вас удивлю, но есть команды с обратным эффектом. Вы явно фанат новых технологий, но поверьте, не все люди такие)
И ваше утверждение про
команда, застрявшая на старых технологиях, начинает терять мотивацию.
верно не везде и всегда, а только в конкретных случаях для конкретных команд.
банальное вынесение строки в константу пока еще не работает, к примеру
Да, пока не все возможности Java реализованы для Kotlin, но в тоже время в Kotlin многие вещи наоборот упрощают различные изменения и рефакторинг. Те же именованные параметры, необязательными типы, destructuring и многое другое.
Сам недавно сталкивался с Котлином, и, на мой взгляд, самой главной фичей этого языка можно назвать возможность применять функциональный стиль программирования без приплясыванием с лямбдами или адом анонимных классов. Вообще данный язык бессмысленен если писать "как привык", но когда мозг перестраивается на реактивный и/или компонентный подход в проектировании приложений, то тогда весь "сахар" языка становится необходимостью, без которой читаемость кода будет на нуле.
Ну и не понимаю я людей, которые идут работать "по тому, что тут пишут на новомодном языке"
Есть в ваших словах доля истины, но есть и то с чем не согласен.
Для начала, про востребованность. Кто лучше, кандидат, который знает вдоль и поперек UI движок платформы и владеет только одним языком или тот, кто знает пять языков программирования но поверхностно? К сожалению рынок труда у нас построен так, что хотят видеть тех, кого могут проверить, а проверить базовые знания по языкам проще, чем глубокие по архитектуре или фундаментальные по программированию. Да и в 90% случаев не нужны эти глубокие знания. Вот и получается, что второй кандидат востребованнее, вот только технологии создают и развивают люди с глубокими и фундаментальными знаниями.
Писать на Котлине это не "выход из зоны комфорта", это переход на более совершенную модель того же инструмента. Развитие происходит от смены парадигмы мышления и паттернов проектирования. Писать объектный код можно и на C и на многих языках, просто это не так удобно. То же касается и функционального кода. Его никто не мешает писать и на Java 7 и на Java 6. Просто это не так удобно. А говорить "я не могу писать функциональный код, по тому что я пишу на Java" — это уход от ответственности. По тому, что в данной фразе виноват не я, а обстоятельства.
Рынок труда устроен именно так, к счастью или к сожалению, и умеение держать баланс — это сугубо личное. Мое мнение — пять но плохо, хуже чем один но хорошо, но один досконально, хуже, чем два хорошо. В нашем случае эксперимент показал, что Котлин к продакшену готов, поэтому все новые модули мы теперь пишем на нем, так метаний между языками становится меньше, а знания платформы с любым языком в нашем случае остаются одинаковыми, что Котлин, что Джава живут поверх одной JVM и одного Андроида.
Никто не мешает, но идти против приниципов принятых платформой (язком, фреймворком, операционной системой — не важно) обычно не просто не так удобно, но еще и не так продуктивно, особенно если разработка идет в команде. Поэтому да, каждый отвечает сам за свои действия, но влияние среды все-таки надо учитывать, и менять среду, если есть такая возможность.
Ну и не понимаю я людей, которые идут работать «по тому, что тут пишут на новомодном языке»
Ну вот представьте — появился новый язык. Человек его изучил. Думаю, желание изучить что-то новое, вопросов ни у кого не вызывает. А какой должен быть следующий шаг? Очевидно, применить новые знания на практике. Что может быть естественней?
Не соглашусь с тем, что "применить на практике" = "выбрать работу, где его используют". Можно писать библиотеки для open source, можно делать интересные утилиты и выкладывать их в GP. Можно брать на аутсорсинг проекты и там применять. Возможностей много если стоит острое желание попробовать. Я довел два проекта до релиза полностью написав их на Котлине и ни один из них не был привязан к моей постоянной работе. Так что не согласен.
Особенно если у вас будет Spring, появляется еще плагин к сборке gradle, нужно добавлять kotlin-spring plugin, без которого все классы нужно обозначать как open, чтобы они не имели final модифактор.
Также столкнулись с большой проблемой использования kotlin не для банальных unit тестов, а в связке с cucumber, из-за сложностей использования reflection — на 100% чистом котлине не взлетело, пришлось делать вставки на джаве.
В целом — сделали ряд микросервисов, в том числе и на akka написаных на котлине без единого джава класса.
Еще вспомнились проблемы с байт кодом и kotlin plugin в Idea, почему в последней версии плагина — байт код несколько изменился, так что порой вовсе не видит каких-то классов при компиляции. Решилось откатом на старую версии идеи и котлин плагина.
Чтобы решить проблему с тем, что Mockito не работает с такими классами, есть обходной пусть: можно создать конфиг файл, который сделает все котлин-классы открытыми для мокито, но только для тестов.
Котлином не поставляется никаких новых инструментов или библиотек для тестирования
а как же https://github.com/JetBrains/spek? (http://spekframework.org/)
Пару месяцев назад втащил в текущий проект котлин. Напишу здесь несколько своих пространных мыслей.
Проект древний (по меркам Android, первые коммиты сделаны в 2010-ом), поэтому одной из главных целей было добавление хоть какого-то фана. Эту цель я действительно достиг, фана добавилось :) На данный момент примерно 25% кода уже на котлине. Часть — это новый код, писавшийся на протяжении последних месяцев, часть — сконвертированный имевшийся код.
Новые языковые фичи использовать по большей мере приятно. Extension-методы удобны. data-классы, дефолтные методы в интерфейсах, лямбды несколько уменьшили boilerplate. Стандартная библиотека фактически лишила смысла присутствие guava в зависимостях. Но всё-таки null-safety на границах с джавой меня смущает. Нет консистентности, типы со знаком восклицания, по сути, имеют ту же проблему, что и «голая» джава — отсутствие compile-time null-safety. Изначальный подход «все, что приходит от джавы, считаем null-небезопасным, если аннотации не указывают иного» мне как-то больше импонировал. Также некоторые фичи накладывают неожиданные penalties. К примеру, forEach оказался чуть ли не в три раза медленнее, чем «классическое» итерирование. Поэтому надо быть внимательным.
Также пока так и не смог осилить делегаты. Чувствую, что они могут решить достаточно много проблем, к примеру, все эти ужасные колбеки от фрагментов в activity через реализацию интерфейсов. Но все примеры с делегатами, которые я встречал, довольно искусственные и четкого понимания так и не дали. И в целом best practices пока не очень развиты.
Конвертация из джавы есть и это хорошо, но я поймал себя на постоянном исправлении одних и тех же шероховатостей после каждой конвертации. Это же чувство при написании кода на джаве подтолкнуло авторов вообще котлин создавать, так что надеюсь, этот функционал будет улучшаться.
Скорость компиляции значительно просела. Kapt сыроват, часто при переключении между гитовыми ветками приходится делать rebuild. Инкрементальная компиляция сломалась, пока не разбирался, можно ли что-то с этим сделать. И плагин котлина регулярно сыплет краши, что отвлекает, раздражает и вообще не сильно хорошо.
В целом, на острие прогресса быть весело, но немного напряжно.
val radioButtons: List<RadioButton> by lazy { some_radio_group.getButtonsList() }
some_radio_group — это прямая «ссылка» на вьюху через Kotlin-X, но она нам не нужна, а нужно только ее содержимое. Аналогично инициализируем все объекты строк, анимаций и т.п, если они переиспользуются в активити/фрагменте несколько раз.
С проблемой отсутствия консистентности на стыке с нативным кодом очень согласен, досаждает регулярно, и получается не так красиво, как должно быть.
Да, спасибо, lazy использую, но это очень частный случай делегатов.
Ещё вспомнилось из разряда: «Как раньше без этого жили?» Это интерполяция строк и дефолтные параметры методов. Реально нужные вещи.
А особенно весело стало, когда я начал использовать корутины. Только ради них уже можно вылезти из уютного мирка джавы.
Kotlin в продакшене, что мы получили, и что мы потеряли?