Хочу рассказать вам о новом языке программирования, который называется Kotlin, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я предпочитал Java, но в последний год пишу на Kotlin везде, где только можно. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java.
Kotlin разработан в JetBrains, и участие тех же людей в создании наборов IDE, таких как IntelliJ и ReSharper, хорошо заметно по самому языку. Он прагматичен и краток, благодаря чему написание кода превращается в приятный и эффективный процесс.
Хотя Kotlin компилируется в JavaScript и скоро будет компилироваться в машинный код, я сконцентрируюсь на его первичной среде — JVM.
Итак, несколько причин, почему вам следует полностью переходить на Kotlin (порядок случаен):
0# Совместимость с Java
Kotlin на 100 % совместим с Java. Вы можете в буквальном смысле продолжать работать над своим старым Java-проектом, но уже используя Kotlin. Все ваши любимые Java-фреймворки также будут доступны, и, в каком бы фреймворке вы ни писали, Kotlin будет легко принят упрямым любителем Java.
1# Знакомый синтаксис
Kotlin — не какой-то там странный язык, рождённый в академических кругах. Его синтаксис знаком любому программисту, воспитанному на парадигме ООП, и с самого начала может быть более-менее понятным. Конечно, есть некоторые отличия от Java вроде переработанного конструктора или объявлений переменных val var. В этом коде отражена большая часть базового синтаксиса:
class Foo {
val b: String = "b" // val means unmodifiable
var i: Int = 0 // var means modifiable
fun hello() {
val str = "Hello"
print("$str World")
}
fun sum(x: Int, y: Int): Int {
return x + y
}
fun maxOf(a: Float, b: Float) = if (a > b) a else b
}2# Интерполяция строк
Это как бы более умная и читабельная версия String.format() из Java, встроенная в язык:
val x = 4
val y = 7
print("sum of $x and $y is ${x + y}") // sum of 4 and 7 is 113# Выведение типа
Kotlin будет выводить ваши типы, если вы посчитаете, что это улучшит читабельность:
val a = "abc" // type inferred to String
val b = 4 // type inferred to Int
val c: Double = 0.7 // type declared explicitly
val d: List<String> = ArrayList() // type declared explicitly4# Умные приведения типов (Smart Casts)
Компилятор Kotlin отслеживает вашу логику и по мере возможности автоматически выполняет приведение типов, т. е. вам больше не нужны проверки instanceof после явных приведений:
if (obj is String) {
print(obj.toUpperCase()) // obj is now known to be a String
}5# Интуитивные равенства (Intuitive Equals)
Можно больше не вызывать явно equals(), потому что оператор == теперь проверяет структурное равенство:
val john1 = Person("John")
val john2 = Person("John")
john1 == john2 // true (structural equality)
john1 === john2 // false (referential equality)6# Аргументы по умолчанию
Больше не нужно определять несколько одинаковых методов с разными аргументами:
fun build(title: String, width: Int = 800, height: Int = 600) {
Frame(title, width, height)
}7# Именованные аргументы
В сочетании с аргументами по умолчанию именованные аргументы избавляют от необходимости использовать Строителей:
build("PacMan", 400, 300) // equivalent
build(title = "PacMan", width = 400, height = 300) // equivalent
build(width = 400, height = 300, title = "PacMan") // equivalent8# Выражение When
Оператор ветвления заменён гораздо более читабельным и гибким в применении выражением when:
when (x) {
1 -> print("x is 1")
2 -> print("x is 2")
3, 4 -> print("x is 3 or 4")
in 5..10 -> print("x is 5, 6, 7, 8, 9, or 10")
else -> print("x is out of range")
}Оно работает и как выражение (expression), и как описание (statement), с аргументом или без него:
val res: Boolean = when {
obj == null -> false
obj is String -> true
else -> throw IllegalStateException()
}9# Свойства
Можно добавить публичным полям кастомное поведение set & get, т. е. перестать набивать код безумными геттерами и сеттерами.
class Frame {
var width: Int = 800
var height: Int = 600
val pixels: Int
get() = width * height
}10# Data Class
Он наполнен POJO-объектами toString(), equals(), hashCode() и copy(), но, в отличие от Java, не занимает 100 строк кода:
data class Person(val name: String,
var email: String,
var age: Int)
val john = Person("John", "john@gmail.com", 112)11# Перегрузка оператора (Operator Overloading)
Заранее определённый набор операторов, которые можно перегружать для улучшения читабельности:
data class Vec(val x: Float, val y: Float) {
operator fun plus(v: Vec) = Vec(x + v.x, y + v.y)
}
val v = Vec(2f, 3f) + Vec(4f, 1f)12# Деструктурирующие объявления (Destructuring Declarations)
Некоторые объекты могут быть деструктурированы, что бывает полезно, к примеру, для итерирования map:
for ((key, value) in map) {
print("Key: $key")
print("Value: $value")
}13# Диапазоны (Ranges)
Для улучшения читабельности:
for (i in 1..100) { ... }
for (i in 0 until 100) { ... }
for (i in 2..10 step 2) { ... }
for (i in 10 downTo 1) { ... }
if (x in 1..10) { ... }14# Функции-расширения (Extension Functions)
Помните свой первый раз, когда пришлось сортировать List в Java? Вам не удалось найти функцию sort(), и пришлось изучать Collections.sort(). Позднее, когда нужно было в строковом значении заменить все буквы строчными, вам пришлось писать собственную вспомогательную функцию, потому что вы не знали о StringUtils.capitalize().
Если бы существовал способ добавления новых функций в старые классы, тогда ваш IDE помог бы найти правильную функцию при завершении кода. Именно это можно делать в Kotlin:
fun String.format(): String {
return this.replace(' ', '_')
}
val formatted = str.format()Стандартная библиотека расширяет функциональность оригинальных Java-типов, что особенно полезно для String:
str.removeSuffix(".txt")
str.capitalize()
str.substringAfterLast("/")
str.replaceAfter(":", "classified")15# Безопасность Null
Java следует называть почти статично типизированным языком. Внутри него переменная типа String не гарантированно ссылается на String — она может ссылаться на null. И хотя мы к этому привыкли, это снижает безопасность проверки на статичное типизирование, и в результате Java-разработчики вынуждены жить в постоянном страхе перед NPE.
В Kotlin эта проблема решена посредством разделения на типы, допускающие и не допускающие значение null. По умолчанию типы не допускают null, но их можно преобразовать в допускающие, если добавить ?:
var a: String = "abc"
a = null // compile error
var b: String? = "xyz"
b = null // no problemKotlin заставляет вас бороться с NPE, когда вы обращаетесь к типу, допускающему null:
val x = b.length // compile error: b might be nullВозможно, выглядит громоздко, но благодаря нескольким своим возможностям действительно полезно. У нас всё ещё есть умные приведения типов, когда типы, допускающие null, преобразуются в не допускающие:
if (b == null) return
val x = b.length // no problemТакже можно использовать безопасный вызов ?., он возвращает значение null вместо бросания NPE:
val x = b?.length // type of x is nullable IntМожно объединять безопасные вызовы в цепочки, чтобы избегать вложенных проверок если-не-null, которые иногда мы пишем в других языках. А если нам по умолчанию нужно не null-значение, то воспользуемся elvis-оператором ?::
val name = ship?.captain?.name ?: "unknown"Если всё это вам не подходит и вам совершенно точно нужны NPE, то скажите об этом явно:
val x = b?.length ?: throw NullPointerException() // same as below
val x = b!!.length // same as above16# Улучшенные лямбды
Это хорошая система лямбд —?идеальный баланс между читабельностью и лаконичностью благодаря нескольким толковым решениям. Синтаксис прост:
val sum = { x: Int, y: Int -> x + y } // type: (Int, Int) -> Int
val res = sum(4,7) // res == 11А вот и толковые решения:
- Можно переместить или опустить круглые скобки в методе, если лямбда идёт последней либо является единственным аргументом метода.
- Если вы решили не объявлять аргумент одноаргументной лямбды, то он будет неявно объявлен под именем
it.
Комбинация этих факторов делает эквивалентными эти три строки:
numbers.filter({ x -> x.isPrime() })
numbers.filter { x -> x.isPrime() }
numbers.filter { it.isPrime() }Это позволяет нам писать лаконичный функциональный код, вы только посмотрите на эту красоту:
persons
.filter { it.age >= 18 }
.sortedBy { it.name }
.map { it.email }
.forEach { print(it) }Система лямбд, объединённая с функциями-расширениями, делает Kotlin идеальным инструментом для создания DSL. Anko — пример DSL, предназначенного для расширения возможностей Android-разработки:
verticalLayout {
padding = dip(30)
editText {
hint = “Name”
textSize = 24f
}
editText {
hint = “Password”
textSize = 24f
}
button(“Login”) {
textSize = 26f
}
}17# Поддержка IDE
У вас есть целый ряд вариантов, как можно начать работать с Kotlin, но я крайне рекомендую использовать IntelliJ, идущий в комплекте поставки Kotlin — его возможности демонстрируют преимущество ситуации, когда одни и те же люди разрабатывают как язык, так и IDE.
Небольшой пример: это сообщение всплыло, когда я впервые попытался скопипастить Java-код со Stack Overflow:
IntelliJ заметит, что вы вставляете Java-код в файл Kotlin
На этом всё, спасибо за чтение! Если мне пока не удалось убедить вас насчёт Kotlin, то рекомендую почитать дополнительные материалы:
- Kotlin on Android. Now official
- Why Kotlin is my next programming language
- Scala vs Kotlin
- Swift is like Kotlin
- The Road to Gradle Script Kotlin 1.0
- Introducing Kotlin support in Spring Framework 5.0
- 10 cool things about Kotlin
- Kotlin full stack application example
- Why I abandoned Java in favour of Kotlin
- I used Kotlin at Hackathon
- From Java to Kotlin
- Kotlin Idioms
Комментарии (277)
kengur8
24.05.2017 19:29+2Осталось понять на сколько хорош его транслятор.
umren
24.05.2017 20:31Он не умеет транслировать код из типичной Java в идиоматичный Kotlin во многих случаях, однако на выходе всегда рабочий код (и визуально он не хуже Java :))
leventov
25.05.2017 08:18Не всегда рабочий, а иногда даже компилирующийся, но с привнесенными багами. Транслировать без ревью нельзя!
kengur8
25.05.2017 10:06Какой там транслятор из Java??
Меня интересует как вся эта магия с динамическими кастами транслируется в систему типов Java. И как это сказывается на памяти и производительности.
Azoh
25.05.2017 13:14А где вы увидели динамические касты? О_о
kengur8
27.05.2017 01:04-1Smart Casts
SilentRider
27.05.2017 01:50+3Но ведь нет никакой магии в Smart Casts.
Просто если компилятор может вывести, что переменная на данном участке программы имеет более "узкий" тип, то компилятор позволяет использовать особенности этого типа, автоматически расставляя касты, если это нужно.
С точки зрения java/байткода это либо простой каст к подтипу, который бы в java пришлось ручками писать, либо же это каст от nullable типа к not nullable, что отражается только в том, что в коде можно писать.вместо?.и никак не отражается в сгенерированном байткоде.
Соответственно это никак не отражается на памяти и производительности по сравнению с java.
solver
24.05.2017 19:30+29Еще одна, 100500-я по счету статья ни о чем… простое перечисление фич.
Думал, хоть что-то из практики применения будет.
А тут очередная копипаста документации.
nekdenis
25.05.2017 05:30+2Так она еще и перевод
zagayevskiy
25.05.2017 15:26Так ещё и неправильный местами.
т. е. вам больше не нужны проверки instanceof после явных приведений:
Steed
25.05.2017 11:22+1Не соглашусь. Да, перечисление фич, но это те фичи, которые реально вырастают из практики. Многие из них мне, как прикладному программисту на С++, очень хотелось бы использовать для повышения читаемости и надежности кода команды (или это уже есть в C++ и активно используется).
Например, именованные аргументы исключают ошибки, когда путаются местами параметры одинакового типа, и повышают читабельность функций с многими аргументами. Цена такой ошибки — от 2 минут до многих часов отладки. Читабельнось экономит кучу времени при анализе чужого и позапрошлогоднего своего кода.
Аналогично:
- when (иначе — длинные ошибкоемкие цепочки if-else для небанальных случаев)
- декомпозиция (удобный возврат нескольких аргументов из функции, иначе приходится создавать на каждый чих структуру либо нарушать RAII)
- not nullable (в С++ можно использовать &, но это не всегда достаточно гибко и трудно переучить народ),
- перегрузка операторов (читаемость математики)
Конечно, сами по себе эти вещи не должны побуждать сразу сменить язык (тут автор статьи перегнул), но забота о таких неочевидных практических деталях показывает, что разработчики языка приближены к жизни и имеют хороший опыт коммерческой разработки.
Sklott
25.05.2017 12:27декомпозиция (удобный возврат нескольких аргументов из функции, иначе приходится создавать на каждый чих структуру либо нарушать RAII)
А чем tuple/tie не подходят?Steed
25.05.2017 12:52Для tie надо заранее заводить переменные, к которым привязываешь значение (т.е. нарушение RAII). Есть в 17-м стандарте Structured Bindings (https://skebanga.github.io/structured-bindings/) — ровно то, что нужно, но пока они еще далеко не везде реализованы.
Crandel
24.05.2017 20:08+2Очень похоже на скалу, отличия просто минимальные, в чем была необходимость создавать новый язык?
Fervus
24.05.2017 21:04+3коммерция
Когда Kotlin станет мейнстрим-языком, значение компании JetBrains для рынка Software Engineering, на котором она работает, будет совершенно другим. То есть, про нас будут говорить, что мы не какие-то ребята, которые делают удобные, но в любой момент заменяемые инструменты, а как про тех, кто делает некоторую корневую фичу экосистемы, на которой всё строится. Это другой вес, другой информационный поток, и деньги, я думаю, тоже другие.
JC_IIB
24.05.2017 21:07+1Мне нравится их уверенность. Не «если станет...», а прямо-таки «когда станет...».
А станет ли?
AlexanderByndyu
25.05.2017 09:37+1Пока что на hh.ru есть 320 резюме, где указано слово Kotlin. Либо всё ещё впереди, либо...
ookami_kb
25.05.2017 10:13Всё впереди, раз гугл руку приложил. Хайп обеспечен теперь. Блоги уже восторженно истерят о "новом русском языке программирования, на который переходит гугл".
При том, что котлин мне очень нравится, и я его активно использую, эта истеричность слегка напрягает.
yarric
24.05.2017 21:52+4То есть предлагается выучить новый язык чисто во славу JetBrains. Называется "not invented here".
SergeyGrigorev
24.05.2017 20:08+9#1 Kotlin — не какой-то там странный язык, рождённый в академических кругах.
Это должно быть мотиватором для тех, кто не осилил Scala?umren
24.05.2017 20:24+8очевидно, что это отсылка к Haskell, причем тут Scala?
spetz911
25.05.2017 08:56+1Про скалу вечно пишут что Мартин сошел с ума и пренебрегает Enterprise в пользу своих академических интересов. Я с этим решительно не согласен.
AKiNO
25.05.2017 09:04Сошел-не сошел не понятно, но вот вам страшный пропозал который сломает обратную совместимость исходников:
https://github.com/lampepfl/dotty/issues/2491
Парни, которые понаписали много кода на скале уже думают, что им делать — переписывать все или вечно сидеть на устаревшей версии.Optik
25.05.2017 09:26Это не скальное предложение, как бы. В дотти новая система типов, что и без того сломает исходники. Но до неё дожить бы еще.
AKiNO
25.05.2017 15:23+1до сих пор там не было предложений, которые бы нельзя было решить в рамках scalafix. насчет того, что и это тоже можно покрыть scalafixом у меня есть сомнения
Sirikid
25.05.2017 17:24+1Пропозал есть пропозал, тем более что особого энтузиазма по его поводу не видно.
senia
26.05.2017 14:40+1Спокойствие, его закрыли.
https://github.com/lampepfl/dotty/issues/2491#issuecomment-304212551
В обсуждении восторги явно не доминировали и решили, что оно того не стоит.
CodderNik
24.05.2017 20:08+13Хорошая попытка но нет!
FadeToBlack
25.05.2017 11:07Зачем миру еще один язык с паскалеподобным синтаксисом объявления переменных? Почему не бейсиковский Let? Это тоже модно!
p1l1gr1m
24.05.2017 20:13+9Форсинг Kotlin на каждом углу уже начинает надоедать.
Зачем это всё когда есть Scala? Зачем это всё когда на этом языке не написано ничего сравнимого к Akka, Play, Spark, etc.?umren
24.05.2017 20:26+4Зачем все это писать на Kotlin, когда ты берешь и используешь все что есть на Java? вы упустили пункт номер 0.
Akka, Spark можно легко использовать в Kotlin и их не нужно переписывать если они вам нужны.
Хотя оригинальные штуки на Kotlin уже появляются, вот например очень интересный проект https://github.com/corda/corda
sshikov
24.05.2017 20:40-1Хм. Посмотрел минут пять. Знаете, я такое уже много лет пишу на груви. И можно привести почти такой же список, почему груви лучше Java (с версии 8 этот список чуть сократился). Почти 1 в 1 будет. А ведь кложу еще не начали вспоминать :)
umren
24.05.2017 20:45+2Так и есть, но все же Groovy & Clojure это языки с динамической типизацией (опустим compileStatic и core.typed) и нацелены несколько на иную аудиторию, в данной статье же сигнал в основном направлен на Java разработчиков.
Кроме того JVM тем и хороша — если давать удобный Java Interface, то можно свободно мешать языки в проекте.sshikov
24.05.2017 20:58-3Какую такую другую? Груви — вполне рабочий язык для бизнеса, не требующего реал-тайм или квази-рт. Это широчайшая аудитория, по большому счету. Если честно сравнивать, что разве что javascript как целевая платформа не покрывается. Совместимость с Java на высоком уровне — если случайно груви классы в API не выставить, проблем почти не бывает.
>(опустим compileStatic и core.typed
Почему опустим-то? Практической разницы — почти никакой.Scf
25.05.2017 09:51+4Очень низкое быстродействие по сравнению с джавой, непонятные перспективы из-за отсутствия финансирования. groovy-eclipse заброшен и только благодаря jetbrains этот язык еще на плаву.
sshikov
26.05.2017 20:55А можете подтвердить слова про быстродействие? Я вот ни разу пожалуй не сталкивался с серьезными проблемами. Ну т.е. оно ниже, чем у просто Java, да и то — JIT с этим борется более-менее успешно.
sshikov
26.05.2017 21:04Ну и кстати про перспективы. Apache Groovy. Помрет, думаете?
>только благодаря jetbrains
да что вы говорите? А я думал благодаря gradle…
p1l1gr1m
24.05.2017 21:08+3Во-первых "легко использовать" это миф. Для Java, Clojure есть отдельные API у Spark которые утилизируют сильные стороны соотв. языка. Для Kotlin ничего такого зрелого нет и чуть более-менее сложные вещи сразу будут болью.
Думаю это справедливо и для Akka, но в меньшей степени и в другой плоскости.
И второе и самое главное, так зачем в итоге переходить на Kotlin, если все то же самое можно делать и на Scala, а в случае фреймворков написанных на Scala — ещё и с меньшей болью.
Короче говоря все преимущества Kotlin ничтожны для того чтобы переходить на этот язык со Scala, например.
sshikov
24.05.2017 20:32+1Это все правда, про акку и пр, но объективности ради, у скалы далеко не все хорошо, например с бинарной совместимостью. И мне вот лично пока не ясно, что будет например после внедрения dotty — очередная ломка? Или наконец наоборот, некоторая стабильность?
Так что понять авторов котлина вполне можно — они пытаются создать очередной компромисс.
P.S. Я вовсе не хочу сказать, что у котлина все хорошо. Тут еще посмотреть надо будет.solver
24.05.2017 20:42+1Ну серьезно… уже надоело это передергивание про бинарную совместимость слушать.
Ну какая ломка? О чем вы?
У скалы с этим нормально все. Поддерживается совместимость в рамках мажорной версии.
Для 11-й версии это порядка 5 лет. Ну вот нафига нужны библиотеки которые 5 лет не поддерживаются?
Кейсы получения проблем в этом месте настолько малы, что не стоит заморачиваться.
А даже если прижмет где-то, можно пересобрать под актуальную версию…sshikov
24.05.2017 20:52+1Собственно, я и не говорю, что это критичная проблема. Я ее просто как пример привел — неудачные характеристики можно найти у любого языка. Этакий небольшой но лишний геморрой на пустом месте.
>Ну вот нафига нужны библиотеки которые 5 лет не поддерживаются?
Ну скажем так — работая на java, я вам таких покажу сотни. То есть тут этой проблемы нет вообще, исключения редчайшие.
leventov
25.05.2017 08:22+1У всех библиотек обязательно есть версии _2.10, _2.11, потому что иначе не работает, одни уже дропнули поддержку какой-то там версии, а другие еще не смигрировали… и такая веселуха постоянно. Все отлично в Скале с совместимостью.
Optik
25.05.2017 09:03Это редко, когда создает проблему. Крупные либы обновляются быстро. Остальные, написанные одним человеком когда-то, в большинстве случаев лучше выкинуть. Зачем тащить труп, который не пересобирается под новую мажорную версию языка при том, что обычно даже код править не надо, только поправить одну строчку в сборке.
Проблемы есть с тем что множество социально-безответственных авторов из всего jvm мира любят прибивать гвоздями определенные версии и включать их в поставку. Типичная ситуация — вязанка netty, сериализатор древней версии и т.д.leventov
25.05.2017 09:42+3По поводу "крупные либы обновляются быстро" — Apache Samza только-только добавила поддержку 2.11.
А вообще, экосистема так не работает. Библиотеки должны оставаться рабочими, даже если вообще некому ими заниматься. В крупных java-проектах сотни-тысячи зависимостей (включая транзитивные), древних версий, многие (не на первом уровне) — давно заброшены, но все это собирается и решает задачи.
Экосистемы, где библиотека=живая библиотека, будут оставаться уделом увлеченных энтузиастов и мейнстримом не станут никогда
solver
25.05.2017 11:03-1Посыл правильный. Поддержка нужна.
Но вот опять сильно передергиваете…
Эти ваши говно энтерпрайзы так и останутся на Java. Им не нужны эти хипстерские замашки с новыми языками.
Те проекты, кому это надо, будут использовать актуальные версии библиотек. Все, что имеет смыл — обновляется регулярно. И с этим нет никаких жутких проблем, описываемых всеми…
Подавляющее большинство древних легаси библиотек никогда не будут переписаны даже под новую Java, не говоря уже про новые языки. И для них так же как и сейчас, будут писать обертки, для удобства.
Все будет происходить ровно так же как сейчас на Java. Многие конторы только сейчас переходят на Java8, много еще сидит на Java6.
То же самое будет и со скалой. Люди будут долго сидеть на мажорной версии. А это все атаки несколько лет поддержки. Потом захотят перейти, обовиться, и либо найдут замену древним легаси библиотекам, либо пересоберут их сами. Ну или, как тоже делают, переосмыслят проект. Возможно и на другом языке. Слишком быстро сейчас все движется, что бы 20 лет сидеть на древних библиотеках…
Еще раз повторюсь, конечно такие конторы есть и будут. Которым надо 20 лет поддержки. Для них есть Java. Все остальные никаких особых проблем с обратной бинарной совместимостью библиотек для Scala не почувствуют…sshikov
26.05.2017 20:58Знаете, все вменяемые обновляются быстро и легко. А те кто сидит на Java 6… ну я знаю одну такую контору. Как почитаешь их требования — сразу хочется забыть, что видел эти вакансии. И Java 6 тут самое меньшее из зол обычно.
philya
31.05.2017 10:26+1У меня java6 в 10 магазинах на дебиане пятилетней свежести работает на местах кассира — я не вижу смысла в обновлении ради обновления. У меня есть масса более интересных занятий чем раз месяц кататься по магазинам с обновлениями дебиана на флэшке )
В прошлом годе даунгрейдил библиотеку для печати qr-кодов с java8 на java6, потому что это быстрее и проще. Я невменяемый )
sshikov
31.05.2017 20:07Я вообще-то в данном случае имел в виду, что миграция на другую версию Java — это наименьшая из трудностей. Решаемая при минимальном уровне вменяемости.
Если вам это не нужно — это немножко другой случай. Особено если вы это приложение не разрабатываете.
У меня другая ситуация — пришли безопасники, и принудительно потребовали обновиться на поддерживаемую Java 8. Возражения принимаются, но не охотно.
Optik
25.05.2017 11:29Не могу назвать опыт с «живым» софтом на коболе или java <=1.4 правильным. Это выливается в еще большие проблемы с поддержкой или миграцией, которые усугубляются с каждым годом. Имхо, принудительное стимулирование двигаться вперед полезно всем.
По поводу «крупные либы обновляются быстро» — Apache Samza только-только добавила поддержку 2.11.
Могу еще спарк привести в пример, но это не значит что это поголовная проблема.
Regis
25.05.2017 17:30+3У вас может быть библиотка с какой-то сложной математикой написанной под Java 1.4. И при переходе на Java 8 она все еще будет корректно рабоать (и почти наверняка станет работать быстрее).
Вопрос: зачем хоть что-то делать с библиотекой, если за пятнадцать лет математика и формулы не поменялись? Это очень хорошо и важно, когда можно использовать старые библиотеки без изменений. Если этого нет — то экосистема убивает сама себя.
Optik
25.05.2017 22:03-1[mode=troll]Мат либу, реализованную без дженериков, поддерживать само собой не особо захочется. Конечно она застряла без развития.[/mode]
Как ни странно, но математика меняется. И алгоритмы и оптимизации, которые могут быть применены тоже. Не говоря уже про blas библиотеки, которые стоят у многих java либ под капотом. Поэтому про перформанс, который улучшается с годами как вино, не надо говорить.
Понимаю, что это пример был, но он неудачный (опыт собственно был с этим).
semmaxim
24.05.2017 22:27+9Потому что 95% программистов никогда Scala не осилит. Она реально экстремально сложная. Одно и то же делается десятками путей, по-умолчанию в стандартной библиотеке дофига всяких знаков вместо нормальных ключевых слов. И не надо говорить «никто вас не заставляет все пути использовать» — открываешь какой-нибудь пример из гугла и сразу видишь жуткие конструкции с "++=" и прочим.
Я сам очень люблю Scala, прошёл пару курсов на Coursera, писал программы «для себя» на ней, но как только попробовал Kotlin, так возвращаться к Scala совсем не хочется.Fervus
24.05.2017 23:28+4Про 95% это вы так же с потолка взяли, так же как и JetBrains про 100% интероп?
жуткие конструкции с "++=" и прочим
Т.е. в java/kotlin
x += 1понятная конструкция, а вотxs ++= List(1,2,3,4)уже жуткая, если учесть конкатенация двух списков это++
В Котлин придостаточно жутких конструкция по типу
thing?.thing1?.thing2 ?: 10
или сложных конструкций по типу делегатов, которые Джавистам не знакомы. Я лично до сих пор не могу понять как работают эти делегаты.
Sirikid
25.05.2017 01:37Насколько я помню, Scala позволяет определелять новые "жуткие" конструкции (даже
<|*|>), а вот Kotlin нет. С точки зрения простоты языка это действительно преимущество.
или сложных конструкций по типу делегатов, которые Джавистам не знакомы.
Они появились как раз потому что знакомы, вызывают боль и ошибки из-за копипасты и вполне могут быть сгенерированы компилятором. Ещё один шаблон на уровне языка и это отлично.
VISTALL
25.05.2017 14:39-1А если ещё добавить магию statements, получаем
fun test() { for { val a = someVariable?.test ?: return .... } }
И если мы добавляем ещё лямбды, то можно ногу сломать.
что? где? когда?
potan
25.05.2017 12:51+1Scala многоуровневая. Требования к разработчику библиотек на порядок отличаются от требований к использующему их программисту. На уровне рядового программиста она не сложнее java. Даже проще, за счет меньшего объема шаблонного кода и поддержки системы типов в IDE.
semmaxim
25.05.2017 20:56+1В любой более-менее взрослой компании есть внутренний набор библиотек и общего кода. Да даже внутри серьёзных проектов такое постоянно.
Да и с чего Вы взяли, что рядовой программист не читает исходники использованных библиотек? А если это внутрикорпоративные библиотеки, то и правит.
artemshitov
24.05.2017 22:32+8Kotlin, на мой взгляд, находит баланс между функциональностью и простотой. Scala мощная и красивая, но за ней необходим очень-очень тщательный уход, чтобы избежать появления «i >>#$<<+=$ j col **%%# k», нужны очень дорогие разработчики и лид из-за высокого порога вхождения, дорого передавать проект другой команде.
Kotlin почти не сложнее Java, он не про «сделать новый сложный, мощный и красивый язык», а про «убрать болевые точки, упростить стандартные паттерны, не делая дороже совокупную стоимость владения и переиспользуя текущих людей». Поэтому, например, у Kotlin есть кросс-трансляция в Java и обратно, поэтому гарантируется полная интероперабельность с Java-кодом, а не как в Scala, когда Scala-классы из-под Java использовать зачастую нереально больно, если только они изначально не проектировались с расчетом на этом.
Для личных проектов for fun я бы выбрал Scala — она интересная; для бизнес-проектов — Kotlin — это стабильно, удобно и лучше в плане цена/качество.
Не претендую на истину, конечно, но для меня это выглядит так.Optik
24.05.2017 23:00+3Scala мощная и красивая, но за ней необходим очень-очень тщательный уход, чтобы избежать появления «i >>#$<<+=$ j col **%%# k», нужны очень дорогие разработчики и лид из-за высокого порога вхождения, дорого передавать проект другой команде.
Чтобы такие символы не появлялись, нужно код ревью. Стоимость разрабов этому ортогональна.
То сложное, что скала позволяет делать, завязано на работу с типами. Нужно в реализации приложений редко и можно обойтись. Как раз для таких финтов и нужны более дорогие разрабы.semmaxim
25.05.2017 12:32-1К каждому разработчику на планете тимлида с кодревью не поставишь. А читать код придётся разный.
p1l1gr1m
24.05.2017 23:13+1А вот это, так же как комментарий semmaxim выше — чистейшая правда.
Вот это действительный минус Scala и Одерски прекрасно это понимает:
My second resolution is to take a larger effort to promote simplicity in Scala. I believe the recent blog post by Jim Plush should be a wakeup call for our community. Scala is a very powerful and un-opinionated language. This means we have a large spectrum of choice how to write a Scala application or library. It’s very important for all of us to use this power wisely, and to promote simplicity of usage wherever possible.
И это действительно сильная сторона Kotlin — относительная простота, на это и стоило бы им делать упор.
potan
25.05.2017 12:57+1По моему опыту, код вида «i >>#$<<+=$ j col **%%# k» возникает очень редко. Если возникают сложные конструкции, то они почти всегда заменяют много строк, которые пришлось бы вместо них написать на java, и которые бы, за счет их количества, читать было бы не проще.
p1l1gr1m
24.05.2017 20:15+7«не какой-то там странный язык, рождённый в академических кругах» — ну а это просто смешно, учитывая что за почти каждой перечисленной здесь фичей мерещится аналогичная из Scala
sergey-b
24.05.2017 20:53+20YAPL — yet another programming language.
По-моему, после нескольких лет серьезной разработки становится все равно, на каком языке писать. Если у меня долгоиграющий проект, то я буду его продолжать на том языке, на котором написана большая часть кода, хоть на дельфи.
Если у меня новый проект, то я буду смотреть на:
- наличие специалистов в команде
- лицензионные ограничения
- требования к рабочему окружению
- среду разработки
- возможности стандартной библиотеки
- наличие сторонних библиотек
- поддержку параллелизма
- перспективу развития
- интеграцию с инструментами документирования, багтрекинга, управления ЖЦ, Continuos Integration и т. п.
и где-то там, пунктов на 10 ниже, будет синтаксис.
Поэтому описание особенностей синтаксиса не отвечает на вопрос из заголовка: «Почему следует полностью переходить на Kotlin».
vanxant
24.05.2017 21:15+3Ну, синтаксический сахар тут явно не экономили, так что тупо заметно меньше придётся печатать.
yarric
24.05.2017 21:58В плане меньше печатать — это к фреймворкам типа Spring. Интересно, есть ли подробные гайды по использованию Spring в Kotlin...
SilentRider
24.05.2017 22:46+3https://spring.io/blog/2016/02/15/developing-spring-boot-applications-with-kotlin
https://kotlinlang.org/docs/tutorials/spring-boot-restful.html
не сказал бы что это прям гайды, просто несколько фактов, которые полезно знать. А в целом гайды нужны именно для использования Spring, а уж использование его в Kotlin ничем не отличается от использования апи других библиотек/фрэймворков
если же интересуют именно подобные посты на хабре, то да, тут были несколько:
https://habrahabr.ru/post/274997/
https://habrahabr.ru/post/274713/
justboris
25.05.2017 13:12+2интеграцию с инструментами документирования, багтрекинга, управления ЖЦ, Continuos Integration и т. п.
Как язык программирования должен интегрироваться с багтрекерами? Подсветка синтаксиса разве что.
sergey-b
25.05.2017 18:10Язык точно этого не должен. Это для багтрекера желательно уметь использовать особенности языка. Я не говорю, что это обязательно, но при выборе языка для нового проекта я на это посмотрю
В некоторых случаях это может быть очень важно. Например, есть такая штука как SSIS-пакеты, в них практически невозможно изменения сматчить с дефектами, потому что там файлы почти бинарные. И разумеется, разработчики, когда их начинали писать, читали интересные статьи о том, какая это классная штука.
В части багтрекинга мне было бы достаточно, если бы в багтрекере была подсветка синаксиса, а в IDE работали бы ссылки из комментариев вида // Also see Issue 166;.justboris
25.05.2017 22:17Тем не менее, это больше про возможности вашего редактора кода. Если он умеет делать кликабельными ссылки в комментариях к коду, то он сделает это в любом языке с коммеетариями.
Почему вы считаете это более приоритетным, чем собственно синтакис языка, мне непонятно.
rraderio
25.05.2017 17:02ЯП это не только синтаксис, но и как часто он не позволяет отстреливать себе ноги.
Fervus
24.05.2017 21:02+10Почему… почему в каждой статье пишут про 100% интероп? Откуда взялась эта цифра, она взята с потолка? Почему не 90%, 95% или 148%?
Уже появляются доклады в которых рассказывать что даже Java код иногда сложно вызывать (https://youtu.be/CABN2r4GPpQ?t=45m9s), а этот язык только недавно релизнулся.
Я молу про то, что большую часть kotlin фишек нельзя вызвать из java кода. Вот что у меня получилось при попытке вызвать suspend method из java:
Sequence<Integer> seq = SequenceBuilderKt.buildSequence(new Function2<SequenceBuilder<? super Integer>, Continuation<? super Unit>, Object>() { public Object invoke(SequenceBuilder<? super Integer> sequenceBuilder, Continuation<? super Unit> continuation) { return null; } });
и это только начало списка, ещё есть extension methods, object companion и т.д.
В итоге получается, если хотите java interop не используйте kotlin фишки, пишите на такой же java только с сахаром.solver
24.05.2017 21:34+6Эта цифра взялась из маркетинга очевидно.
Если почаще кричать, то толпа не будет задумываться, а хайп покроет все.
Когда пыль рассеется, поздно будет давать заднюю…
alek_sys
24.05.2017 22:24+4Я бы не советовал как пример приводить вызов suspend методов. Все-таки suspend методы это очень специфичный механизм работы корутин (экспериментальной фичи) из 1.1, который настолько интегрирована в язык и инфраструктуру что вызов из Java и будет выглядеть абсолютно чужеродно.
А по поводу интеграции в Джаву вообще вопрос интересный. Вот реально субъективно возникает меньше ощущения «другой» платформы, чем от Скалы, хотя на Скале промышленно писать не доводилось.
Банальный пример, Скала:
collection.mutable.Map[String, String]().isInstanceOf[java.util.Map[String, String]] // false
и Котлин
emptyMap<String, String>() is java.util.Map<*, *> // true
И хотя у Скалы есть asJava, но все равно не используя полностью всю мощь коллекций Скалы наверное жить в мире Скала не очень весело.
Еще Котлин хорошо интегрируется во все системы байт-код «хакинга» (типа Мокито, хотя и не без проблем), анализа и т.п. Поэтому с ним работают Спринг (официально) и даже магические библиотеки типа Quasar (которые от поддержки Скалы отказались как раз по причине заморочек с байт-кодом). Т.е. Котлин чувствуется именно что «лучшей Java-ой», а Скала все таки другим языком и иногда даже другой платформой. Что в целом не плохо само по себе.
На какой-то конференции была фраза, что Котлин и Джава достаточно похожи, чтобы можно было легко перейти с одного языка на другой, но достаточно разные, чтобы этот переход того стоил.Fervus
24.05.2017 22:55+2А по поводу интеграции в Джаву вообще вопрос интересный. Вот реально субъективно возникает меньше ощущения «другой» платформы, чем от Скалы
Безусловно интеграция с джавой у Котлина лучше (и наверное лучше чем у любого другого JVM языка), по поводу этого не спорю. Но лучше, это относительное понятие, а не величина. Если мы говорим про цифры, то эти цифры должны быть подтверждены (а если нет подтверждения, то какой смысл в конкретных величинах?), тем более если мы говорим про громогласное заявленное на офф сайте 100%. 100% — значит что мы должны иметь возможность без костылей вызвать это в Java, не смотря на сколько это "чужеродно". И такие "чужеродности" не только с suspend method их ещё много, все это придется пережить и узнать кто будет использовать Котлин, выполняя роль тестировщика языка.
Я бы не советовал как пример приводить вызов suspend методов.
Осталось сделать такой список на офф сайте Котлина: "Мы не советуем вам использовать эти фичи Kotlin'а т.к. вы потеряйте интероп" и я бы даже слова не сказал. Или ещё лучше какой-нибудь флаг компилятора, который выключал все эти фичи и позволял бы писать на каком-нибудь подмножестве Котлина, который бы имел интероп. Потому что уже сейчас появляются библиотеки на Котлине, которые используют спицифичные для Котлина фичи, и которые сложно вызывать из Java, но создатели этих либ особо об этом не парятся. В результате получается своя экосистема, такая же как в Clojure или Scala.
Еще Котлин хорошо интегрируется во все системы байт-код «хакинга» (типа Мокито, хотя и не без проблем), анализа и т.п. Поэтому с ним работают Спринг (официально) и даже магические библиотеки типа Quasar
Если вы посмотрите issues лист Quasar, то увидите что там достаточно специфичных багов связанных с использованием Котлина.
snrostov
24.05.2017 22:46ещё есть extension methods, object companion и т.д.
А с ними что не так?
На самом деле лично меня раздражает только одна проблема с вызовом котлина из джавы: вызов методов принимающих колбэки с void (Unit в котлине)… Приходится писать return Unit.instance. Это из за этого что параметры имеют тип FunctionX<..., Unit>. Поэтому если предполагаются ява пользователи кода котлина, приходится делать утилитные методы.
suspend методы в принципе не могут быть вызваны из джавы, ведь все кто их вызывают также должны уметь засыпать в месте вызова этой самой функции. Без поддержки со стороны какого бы то ни было компилятора делать это бессмысленно.
К слову, большенство кода написанного на скале вызывать почти невозможно. В котлине таких проблем нет, и как ни крути в этом плане он все же выигрывает у скалы.
Fervus
24.05.2017 23:08+2А с ними что не так?
с extension methods все отлично, вот только проблема в том в Java их нет. Приходится вызывать статические методы. Особенно это уродски выглядит когда либа на Котлине их использует повсеместно.
companion object приходится анноторивать
@JvmStatic, что бы можно было нормально из Java вызывать, вот только к сожалению часто их не аннотируют почему-то.
на скале вызывать почти невозможно
Да уж невозможно конечно. Поэтому большинство мейн-стримовых скаловских фреймворках доступны из java.
В котлине таких проблем нет
Есть с тем же suspend methods. Или вы собрались использовать некое подмножество языка? Ну так это можно так с X где X любой JVM язык.
К слову, большенство кода написанного на скале вызывать почти невозможно.
Дело не в выигрышах или проигрышах, а дело в заявленных 100%, смотрите я ответил выше. Особенно это актуально для Джавистов, если они собрались потом использовать Котлиновский код.
bano-notit
24.05.2017 21:43… делает Kotlin идеальным инструментом для создания [DSL](C:\Users\Desktop\Cloud Mail.Ru\Mail — Почему нужно полностью переходить на Kotlin\в Kotlin). Anko — пример DSL...
Мне кажется, что что-то не дописано...
BinaryLifeStyle
24.05.2017 21:45+1Пора статью написать «Почему следует полностью оставаться на Java», а заголовки настолько вызывающе написаны, можно было сразу,java умерла.До сих пор не догоняю зачем это Kotlin? Есть же Scala…
autumnl
25.05.2017 08:56-2Kotlin много проще. Тут скорее стоит сравнить с xtend или чем-то подобным — рафинированная java. С учетом теоретической возможности Kotlin транслироваться в native (ага, опять привет Scala!) — есть возможность красиво отвязаться от jdk/oracle/суды/…
А вообще, конечно, «это уже было в Симпсонах» (с)
yarric
25.05.2017 11:59Под native же ещё native-библиотека понадобится, язык на этом фоне будет незначительной проблемой.
autumnl
25.05.2017 13:42Затянуть LLVM на Android, думаю, не проблема. Scala-native, насколько мне не изменяет память, аккурат на LLVM заточена. Уверен, что Kotlin-native, тоже LLVM.
К чему это я? Стараюсь, упорно стараюсь найти use-case для Kotlin, и native звучит как некоторый возможный задел на будущее. Однако в данный момент — не нужно.yarric
25.05.2017 14:19Под LLVM нет стандартной библиотеки классов, в отличии от JVM или .NET. Хорошо написать такую библиотеку, а потом ещё и убедить разработчиков её освоить — та ещё задача.
potan
25.05.2017 13:14+1Для Scala трансляция в native тоже вполне возможна. К тому же она меньше завязана на стандартную библиотеку Java (так как система типов диктует другой подход к разработке библиотек).
autumnl
25.05.2017 13:38Я же с этим совершенно не спорю :-)
Просто пытаюсь найти хотя бы какие-то плюсы в Kotlin. Но как не находил раньше, так и не нахожу сейчас.
zim32
24.05.2017 21:57+1Им надо не програмистам объяснять достоинства котлин, а манагерам. К примеру «Если вы внедрите котлин, то за счет более лаконичного синтаксиса, вы сможете сэкономть столько-то человеко-строк-кода-денег». Может прокатит.
aquamakc
25.05.2017 14:41) и тактично умолчать об убытках понесённых в процессе перехода с одного языка, на другой…
SAKrisT
25.05.2017 00:46-2Улыбнуло. «Swift is like Kotlin».
А не наоборот ли? Или Kotlin первый появился?nile1
25.05.2017 00:54+5Kotlin — 2011, Swift — 2014.
Просто Swift сразу зарелизился, и ломали совместимость уже по ходу выпуска новых версий.
А Kotlin разрабатывался много лет открыто вместе с сообществом, и зарелизился только в 2016.
moonster
25.05.2017 01:14+1Хочется рассказать впечатлениях от боевого использования.
Проекту, где я тружусь, уже больше 3-х лет. Мы последовательно попробовали Java, Groovy, Scala, Kotlin (последние полтора года).
Итого: победил Kotlin, Java и Groovy остались только в виде legacy, причем Groovy только в тестах (из-за Spock Framework), Scala не прижилась совсем.
Все разработчики смогли относительно безболезненно перейти на Kotlin, а лично я после Groovy и Scala просто сел и начал писать.
Действительно, не все фичи Kotlin удобно использовать из Java, в обратную сторону таких проблем не наблюдается.
Итого: если legacy вас не сдерживает — пробовать можно, нужно и приятно. Если сдерживает — просто немножко подумайте над API ваших компонентов.
arturgspb
25.05.2017 01:25+4Астрологи объявили год поклонения Котлину. )) Как это знакомо все… Года не проходит, начинаются посты Почему вас стоит… А через год, может и от этого же автора про другой язык и что Х, оказался не так хорош и бла бла. Прямо как с javascript, но там итерации короче — где-то полгода, до очередного просветления.
yanchenko
25.05.2017 01:29-7А что, всем на самом деле так нравится синтаксис Котлина?
Меня он местами выбешивает.
- вместо
var,valзачастую полезнее видеть тип - аналогично
fun— лишний визуальный мусор companion objectдля статических методов и констант выглядит прилепленным сбоку- постоянно приходится использовать
!! - не протикся идеей одного конструктора и впихиванием его и нформации о наследовании в одну строчку
- синтаксис значения по умолчанию для аргумента функции
off: Int = 0явно разрабатывался в Мюнхенском офисе (как по-немецки говорят "сто четые и двадцать", а не "сто двадцать четыре"). - ключевое слово
overrideдля метода — лишний мусор по сравнению с@Override. - по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)
- т.д.
Cинтаксис Java ИМХО значительно гармоничнее, а киллер-фич, значительно повышающих производительность, не обнаружил. Зато намного проще написать в одну строчку код, который потом сложно понять.
moonster
25.05.2017 02:12+41) Одно другого не исключает. Нужен тип — пишите.
2) В котлине вы можете объявить функцию в теле метода, вне класса, в классе. И везде такое объявление выглядит одинаково.
3) Объявляйте константы вне класса, если companion object не нравится.
4) "!!" aka оператор "костыли" — не самая изящная часть kotlin, однако, его почти всегда можно избежать.
5) Не со всем понимаю, о чем речь. Конструкторов может быть больше одного.
6) Сначала выглядит странно, но привыкнуть не сложно.
7) Ключевое слово override гораздо строже, чем аннотация (которой может не быть), и это скорее хорошо.
8) Отсутствие наследования по умолчанию — это явный плюс. Я и в java класс не предназначенный для расширения объявлял final, и таковых всегда было большинство. Вообще в большом проекте запрещение всего, что явно не разрешено, чаще сказывается благотворно.
Sirikid
25.05.2017 02:18+4- Давайте proof of concept, хватит BNF. Из очевидных плюсов вывода типов можно выделить более простую работу со вложенными дженериками.
- См. 1.
- Статические члены, в свою очередь, прилеплены сбоку к классам и объектам.
- Так вы от NPE не спасетесь.
- Вы же в курсе что можете сделать по другому? Ещё Дейкстра говорил что поведением по умолчанию должен быть частоиспользуемый вариант, в Kotlin это так.
- А вот тут соглашусь, могли бы и сюда вывод типов завести.
- Почему? То, что раньше было просто правилом хорошего тона, стало обязательной конструкцией языка, по-моему вполне естественная и полезная метаморфоза.
- См. 5 про Дейкстру. (И вообще пользуйтесь интерфейсами, JIT придет — порядок наведет!)
- И т. д.
leventov
25.05.2017 08:34по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)
Читайте Effective Java
Bringoff
25.05.2017 09:27+2Судя по большинству приведенных пунктов, простите, но у вас Java головного мозга.
netch80
25.05.2017 17:11+2> синтаксис значения по умолчанию для аргумента функции off: Int = 0 явно разрабатывался в Мюнхенском офисе (как по-немецки говорят «сто четые и двадцать», а не «сто двадцать четыре»).
Это спорно. Да, есть традиция (которую сохраняет C и потомки), что формат определения переменной — «тип переменная [=начальное]», в противоположность традиции, известной по Pascal и прочим — «var переменная: тип [=начальное]». Но сишная традиция заметно усложняет парсинг (уже лексер должен отдавать, чем является идентификатор — типом, переменной, чем-то иным; или парсер должен справляться с неоднозначностями уже после построения конструкций), формат записи (все эти foo (*fptr)(bar) долго учатся новичками)…
Для сравнения, Go использует паскалевский вариант (только ':' убрали — «var переменная тип») — в нём много спорных моментов, но этот явно выглядит как результат идеи прекратить топтаться заново по этим граблям. Swift использует паскалевский вариант. По сравнению же с вот такими чудесами — неудивительно, что пытаются упрощать.
Это же касается и второго замечания:
> аналогично fun — лишний визуальный мусор
та же тема — упрощение грамматики приводит к понятности всем. Дополнительно, такой fun позволяет сделать простой и ясный синтаксис замыканий/лямбд (что показал хотя бы Javascript).
> по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)
Это показывает определённый настрой, но не выглядит фатальным — ведь всегда можно умолчание изменить? В C++ умолчание для метода — не виртуальный, в Java/C# — виртуальный, от этого в C++ стало меньше возможности перекрыть метод?
> ключевое слово override для метода — лишний мусор по сравнению с Override.
Ну, тут лучше было бы поступить радикально — как по требованию .NET CLR — метод сделать любой идентификатор, даже совпадающий с ключевым словом. Если это есть — несколько лишних ключевых слов не проблема.
- вместо
lagranzh
25.05.2017 01:53+3При всем уважении к ребятам из jetbrains, я так и не понял зачем мне на очересной java-спутник переходить из-за синтактического сахара. Тем более что к лету обещали 9-ю джаву с алокацией на стеке и АОТ-компиляцией?
lany
25.05.2017 07:17+6С аллокацией на стеке? Вы про что и кто это обещал? Что-то из разряда "слышал звон".
lagranzh
25.05.2017 11:05Вы правы, я фигню сказал. не знаю откуда я это выкопал, но сейчас погуглил, и ничего похожего не могу найдти.
lany
25.05.2017 12:47+2Подозреваю, что вы value types за аллокацию на стеке приняли. В девятке их всё равно не будет. И аллокация на стеке ортогональна value-типам. Джава уже давно умеет не то что на стеке аллоцировать, а в регистры раскидывать объект вообще без аллокации. Или в принципе избавиться от объекта, если позволяет ситуация.
leventov
25.05.2017 08:36+2AOT компиляцию и в Котлин быстро завезут, после того как Java 9 выйдет, а синтаксических улучшений в Java 9 примерно ноль
september669
25.05.2017 08:56+2На андроиде java полузастряла на 1.7, так что котлин для гугля это очередная хипстерская мина при плохой игре.
akzhan
25.05.2017 02:48+1Система лямбд, объединённая с функциями-расширениями, делает Kotlin идеальным инструментом для создания [DSL](C:\Users\Desktop\Cloud Mail.Ru\Mail — Почему нужно полностью переходить на Kotlin\в Kotlin).
lxsmkv
25.05.2017 04:30+4«Жизнеспособность и практическая пригодность языка программирования в современном мире прямо пропорциональна количеству материала по нему на Stackoverflow.» © Я.
egordeev
25.05.2017 06:33+1кстати, сам mail.ru не планирует перейти полностью на kotlin в своём android-приложении «Юла»?
lany
25.05.2017 07:20+2А вот почему не стоит переходить. Компилятор до ума довели, вопросов нет. Но поддержка в IDE страдает. Каждый раз, когда я влезаю в Котлин, напарываюсь на какую-нибудь неприятность вроде этой. Тонна Java-инспекций в Котлине не работает, хотя имеет смысл, если активно используешь всякие Java API.
leventov
25.05.2017 08:39А нельзя делать инспекции сразу для двух языков, на каком-нибудь упрощенном синтактическом уровне, общем для Java и Kotlin? Конечно не для все инспекции будут так работать, но по ощущению примерно половина — должна
Kladproraba
25.05.2017 08:33Как же быстро всё меняется… Это конечно и здорово — постоянно учить что то новое, развиваться. Спасибо за полезный материал :)
baylrock
25.05.2017 08:56+1Java-разработчики вынуждены жить в постоянном страхе перед NPE
Это какая-то профанация?!
переменная типа String не гарантированно ссылается на String — она может ссылаться на null
Абсолютное непонимание того что такое null, и зачем он «нужен», тем более что приведенный далее код и пояснения не объясняют что же в 'котле' такого инновационного и избавляющего от страха NPE…
acmnu
25.05.2017 10:49+3и пояснения не объясняют что же в 'котле' такого инновационного и избавляющего от страха NPE
Насколько я понял, kotlin не скомпилирует код, в котором не сделана проверка на null для типа, который может быть нулабл. Эдакая защита от дурака на уровне комплилятора.
nerumb
25.05.2017 10:56+2Это не столько защита от дурака, сколько возможность использовать опциональность типов. Большая часть использований Optional (Option в Scala) заменяется на nullable тип в Kotlin. Так и их использование становится проще, и в коде не создается лишних инстансов.
potan
25.05.2017 13:26Но теряется возможность использовать монадический синтаксис и унифицированный код, работающий с разными типами коллекций. Да и я бы не сказал, что большое количество '?' делает код сильно проще.
nerumb
25.05.2017 13:39+2Но теряется возможность использовать монадический синтаксис и унифицированный код, работающий с разными типами коллекций
Просто один подход заменяется на другой. Да и для nullable типов в Kotlin есть специальные расширения для коллекций (типа filterNonNull и т.п.)
Да и я бы не сказал, что большое количество '?' делает код сильно проще.
Спорное утверждение, кому что ближе =)
Из своего опыта могу сказать что мне подход Kotlin ближе. К примеру код на Scala:fun1().flatMap( _.fun2).flatMap( _.fun3)заменяется наfun1()?.fun2()?.fun3()
nerumb
25.05.2017 13:48Да и, в принципе, тот же монадический синтаксис можно использовать и в Kotlin, где нужно.
acmnu
26.05.2017 10:30Я не знаком со Scala, но что-то мне кажется, замена опциональных типов (опять таки если я правильно все понял), на nullable, это какое-то слабое утешение. Нет, конечно, это хорошо, что можно отделить корректный и некорректный возврат функции не используя эксепшены (которые дороги, как известно), но если тебе вернули null, то все что ты знаешь, что что-то пошло не так.
nerumb
26.05.2017 10:35Если вы в таких местах используете Option, то у вас будет либо Some с объектом, либо None. В случае None вы так же теряете информацию о том что пошло не так. (в таких случае целесообразней использовать другой механизм, может тот же Either)
Там же где Option подходит, он заменяется успешно на nullable тип. (не везде, да бывают места где лучше оставить Option, но все же в большинстве случаев его можно заменить)acmnu
26.05.2017 11:18В Rust Option тип может быть любым. Т.е. обычно у тебя возвращает String, а в случае проблема некий Error тип с произвольным содержимым. Это довольно удобно. Здесь по всей видимости другая логика.
DarkEld3r
26.05.2017 15:27В Rust Option тип может быть любым. Т.е. обычно у тебя возвращает String, а в случае проблема некий Error тип с произвольным содержимым.
Нет, в раст
Option<T>— это или конкретное значениеTили ничего. Значение или ошибка — этоResult<T, E>.
SilentRider
26.05.2017 10:46Но nullable типы в котлине не создавались для замены исключений, и использование их так, как описано в вашем примере, действительно плохо с точки зрения api метода, если информация о ошибке важна для пользователя.
Nullable типы введены в язык, чтобы на уровне компилятора обнаруживать потенциальные NPE и выводить ошибку компиляции там, где в джаве это было бы NPE в рантайме. То есть использование nullable типов это тоже самое, что использование Optional, только на уровне синстаксиса языка.
*нужно не забывать обновлять страницу перед отправкой коммента*
eskander_service
25.05.2017 08:57+1Чем больше таких статей, тем больше будет отталкивать этот новый язык. Такое, складывается, ощущение что он разработан лишь для коммерции и громкой рекламы.
Если есть много, хорошо работающих проектов, врядли кто будет баловаться с ними ради моды и в угоду рекламы.
tekord
25.05.2017 08:57+11Гений дизайна тот, кто решил, что противоположные по смыслу модификаторы unmodifiable и modifiable должны определяться визуально сходными ключевыми словами var и val. Читабельность на высоте.
leventov
25.05.2017 09:48+1Противоположные по смыслу + и -, << и >>,… и да, это источник багов во всех современных ЯП.
Crafter2012
25.05.2017 10:13+1Ну не знаю.
var — variable
val — value
Интуитивно как-то понятно, что я для чего.
пы Интуицию стоит проверить, но делать этого я, конечно, не буду=)FirExpl
25.05.2017 11:21+9var — variable
val — value
Не, оно конечно понятно, почему названо так, но разница в 1 букву достаточно сильно снижает читаемость выражения.
Например мне больше нравится вариант как в Swift, где let / var. Смысл не меняется, но отличить одно от другого несколько проще)potan
25.05.2017 13:29+2Это правда.
Но, по крайней мере программируя на Scala, писать var приходится на столько редко, что можно считать что его просто нет.
netch80
25.05.2017 16:54+1Тут интереснее. Это для нас r и l различаются. Для китайцев, японцев, представителей многих других соседних народов — нет. Даже обучившись европейским языкам, они сохраняют эти проблемы ещё долго.
Соответственно, использование языка будет давать им серьёзные проблемы там, где надо озвучивать код — при обучении, в рабочих дискуссиях… А так как тех же китайцев в США несть числа — ожидаю активное неприятие языка.
nehaev
30.05.2017 18:43+2противоположные по смыслу модификаторы должны определяться визуально сходными ключевыми словами
Вам поможет Skala, там точно не перепутаешь :)
val -> unveranderliche var -> opportunistisch def -> verfahrensweise
tekord
30.05.2017 18:53+1Прочитал пост по ссылке, прифигел. А потом увидел дату публикации и расслабился :)
ACPrikh
25.05.2017 09:48-3Компиляция в машинный код! Я так и думал, что виртуальную машину кронштадцы пустят под откос за вслед за паровозом. (В смысле кпд)
Холивар явовцев зашкаливает :)yarric
25.05.2017 15:59Эх, сколько уже таких "более лучших" Java/C# было...
ACPrikh
26.05.2017 08:53-3А сколько было гуру Кобола и Алгола… И вот явовцы оказались в их положении. Что остается, как не злобствовать? Тем более, что бандерлогов греет мысль о том, что их стая велика.
Scf
26.05.2017 09:46-3Не оказались. JVM жила, живет и будет жить, и вместе с ней будет жить Java как "нативный" язык программирования JVM.
Даже если в будущем изобретут язык, который во всех отношениях обгоняет текущие парадигмы программирования, в настоящее время есть только один качественный и эффективный рантайм со сборкой мусора — JVM.
leventov
26.05.2017 10:42+1Go, CLR тоже качественные и эффективные рантаймы сборкой мусора
Scf
26.05.2017 16:21CLR либо только под винду, либо имеет серьезные проблемы с быстродействием
Go, насколько я знаю, использует заточенный под себя рантайм, т.е. другой язык на нем не сделаешь.mayorovp
26.05.2017 16:31-1А какие у .Net Core проблемы с быстродействием?
Scf
26.05.2017 16:32mayorovp
26.05.2017 16:52Там значения близкие во всех тестах кроме первых трех. Причем в первом тестируются возможности системных регулярок, которые разные по функциональности; во втором в коде на шарпе распаралелили не тот уровень вычислений (обратите внимание: в коде на Java создается отдельная задача для каждой комбинации offset/fragmentLength, а в коде на C# — только для каждого fragmentLength).
Я бы не назвал это серьезными проблемами с быстродействием.
yarric
26.05.2017 11:35-2Java по сравнению с COBOL и Algol имеет много значимых улучшений, какие столь же значимые улучшения имеют все эти Kotlin, Groovy, Ceylon по сравнению с Java?
j_wayne
25.05.2017 09:49Удивил способ создания массивов — через builtines:
intArrayOf(), longArrayOf(), arrayOf()
Как то непривычно, интересно, почему именно так сделали?nile1
25.05.2017 10:28+1Можно почитать здесь: https://discuss.kotlinlang.org/t/arrayof-unnatural/1637/41
Основная мотивация в том, что если и вводить специальный синтаксис, то сразу для всех коллекций (array, list, map, set), а не только для массивов.
Однажды добавив синтаксис его уже будет невозможно изменить не ломая обратную совместимость, поэтому не спешат.
Насколько я понимаю, от специального синтаксиса не отказались, но пока не приняли окончательное решение.
unabl4
25.05.2017 09:50-2Чем больше форсят что-либо, тем меньше мне хочется на это обращать внимание. Назойливость этого языка переходит вообще все границы.
impwx
25.05.2017 10:31По поводу Data Class, в оригинале было вот что:
It’s a POJO complete with toString(), equals(),…
А в переводе что-то пошло не так:
Он наполнен POJO-объектами toString(), equals(),…
nerumb
25.05.2017 10:42Плохую статью выбрали mail.ru для перевода…
Про делегаты вообще не слова, как и про вариативность. Про coroutines так же ничего не сказано…
Да и просто описание синтаксиса Kotlin сейчас уже не очень актуально, до этого и так было много статей по этому поводу.
Jukobob
25.05.2017 11:26На самом деле ограниченый лучший пример, приблизительно тоже самое можно и на Java написать, но без range.
when (x) { 1 -> print("x is 1") 2 -> print("x is 2") 3, 4 -> print("x is 3 or 4") in 5..10 -> print("x is 5, 6, 7, 8, 9, or 10") else -> print("x is out of range") }
Стоит для еще большей наглядности добавить например приведение типа.
... is Double -> print("x is Double") null -> print("x is null") "dummy" -> print("x is $x")
BTW, добавьте в статью @JvmOverloads, ну и что операторы можно передавать в функции.
В дополнение, мне кажется, что скоро с данного ресурса можно будет собрать стопку статей на перевод Kotlin Reference.nerumb
25.05.2017 11:28BTW, добавьте в статью @JvmOverloads, ну и что операторы можно передавать в функции.
это перевод…
В дополнение, мне кажется, что скоро с данного ресурса можно будет собрать стопку статей на перевод Kotlin Reference.
Документация по Kotlin на русском
FirExpl
25.05.2017 11:43+1Я бы добавил ещё один небольшой плюсик Котлину, который, однако, скорее не его заслуга :)
С Kotlin легко перейти на Swift и наоборот, что в теории может упростить для некоторых разработку под разные мобильные платформы.
tangro
25.05.2017 11:50-6Всё-таки смущает, что за языком стоит JetBrains. Это как если бы поставщик обедов для самолётов объявил о запуске своей линии самолётов на том основании, что давно связан с отраслью и хорошо её понимает. За C# стоит Microsoft, за джавой — оракл и понятно, что эти компании пилят компиляторы уже десятилетиями и никуда не денутся и через 20 лет. JetBrains, при всём уважении, пилит красивый текстовый редактор с рюшечками и откуда у них вдруг опыт разработки промышленного компилятора уровня «давайте выкинем Java нафиг» — не ясно. Вон даже Google вписывается в это всё очень осторожно, типа «да, есть такое, но это делаем не мы, а они, мы пока постоим в стороне и посмотрим как оно будет».
mayorovp
25.05.2017 12:08+5Как-то вы странно сравнили IDE для языка с обедом в самолете. В "самолетной" аналогии IDE — скорее корпус.
yarric
25.05.2017 14:51Скорее как терминал аэропорта — удобная и полезная фича, но не обязательная.
mayorovp
25.05.2017 15:11+1В данном случае речь идет не об обязательности фичи, а об уровне компетентности разработчиков. Так вот, разработчики IDE должны разбираться в языке едва ли не больше чем разработчики компилятора. Просто потому что трансляторам позволительно останавливаться после первой же ошибки, а IDE должна работать с кодом на любой стадии готовности.
yarric
25.05.2017 15:53Если IDE протупит с автодополнением — разработчик всегда может написать это руками, а вот если компилятор что-то не то накомпилирует, то тут уже туши свет.
netch80
25.05.2017 16:50> Так вот, разработчики IDE должны разбираться в языке едва ли не больше чем разработчики компилятора.
Справедливости ради, это касается только фронтэнда компиляции — парсинга. Глубины оптимизации, JIT… — это уже не его части.
Kotlin вполне соответствует этому — бэкэнды разные, но эта ниша занята собственно исполняющей VM в JRE, в Javascript машине… И поэтому я сомневаюсь в собственной native реализации — наверняка спихнут на LLVM :)SilentRider
25.05.2017 18:32+3Так а зачем гадать? можно же просто взять и посмотреть в офф репозиторий. Там первым предложением в readme написано:
Kotlin/Native is a LLVM backend for the Kotlin compiler, runtime implementation and native code generation facility using LLVM toolchain.
Так что да — нативный код будет генерироваться через LLVM, что в скорее плюс, чем минус.
nerumb
25.05.2017 12:14+1Это как если бы поставщик обедов для самолётов объявил о запуске своей линии самолётов на том основании, что давно связан с отраслью и хорошо её понимает
Все же не очень корректное сравнение. Ближе будет что-то вроде этого: Создатели промышленных роботов для производства хорошо знакомы со многими отраслями, и решили открыть свою фабрику со своими роботами…
У JetBrains большая экспертиза, есть огромное количество студий под самые разные языки. Им известны проблемы, которые есть в языках, а также все проблемы создания IDE под них. Очень показателен тут пример Scala, где под популярные макросы пишутся плагины для IDE, чтобы она их нормально понимала. Для Kotlin же планируется в будущем добавить метапрограммирование, которое будет позволять делать практически тоже самое что и макросы Scala, но только чтобы оно одновременно легко встраивалось в поддержку IDE.
Поэтому они взяли лучшее что есть в других языках, добавили своих нововведений и получился Kotlin.
За C# стоит Microsoft, за джавой — оракл и понятно, что эти компании пилят компиляторы уже десятилетиями и никуда не денутся и через 20 лет. JetBrains, при всём уважении, пилит красивый текстовый редактор с рюшечками и откуда у них вдруг опыт разработки промышленного компилятора уровня «давайте выкинем Java нафиг» — не ясно
Kotlin запускается поверх JVM, Dalvik VM, и есть транслятор в Javascript (native также есть, но пока не в релизе). Java c JVM точно никуда не денется в обозримом будущем (уж очень много написано на ней и работает сейчас), а значит и Kotlin будет работать поверх JVM. Все новые версии почти сразу будут поддерживаться Kotlin, в том числе и скорая Java 9. Для Android Kotlin теперь поддерживается официально.
Ну а web слишком быстро меняется =). Андрей Бреслав на одном из выступлений сказал, что они рассматривают возможность компилироваться в WebAssembly, как технология дозреет. Это так же дает уверенность что в web можно будет с уверенностью писать на Kotlin.
burlakadenis
25.05.2017 12:17-1Всё супер! Очень привлекательно и скорее мы попробуем kotlin на новом/новых проектах. Но вот зачем надо было делать:
fun build(title: String, width: Int = 800, height: Int = 600) { Frame(title, width, height) }
вместо более привычного:
fun build(String title, Int width = 800, Int height = 600) { Frame(title, width, height) }mayorovp
25.05.2017 12:20+3Ну очевидно же, чтобы синтаксис объявлений параметров совпадал с синтаксисом объявлений переменных.
А в объявлении переменных тип поставили вторым потому что это — необязательная часть. Необязательная часть объявления не может идти первой.
YemSalat
26.05.2017 01:07-2Необязательная часть объявления не может идти первой.
Почему?
0xd34df00d
27.05.2017 00:43Потому что парсеры таких вещей писать не очень приятно.
YemSalat
28.05.2017 10:14-4По-моему это не очень аргумент. Мне как разработчику по идее должно быть до лампочки насколько сложно было писать парсер языка который я использую.
И в чем сложность парсинга заключается, честно говоря, мне тоже не очень понятно.mayorovp
28.05.2017 13:07+2Зато вам, как разработчику, важна однозначность синтаксиса, потому что из нее напрямую следует насколько качественные сообщения об ошибках компиляции вы будете получать.
Gorthauer87
25.05.2017 19:13+1Так удобнее парсить, так что почти во всех новых языках такой порядок объявления.
Nimtar
28.05.2017 14:20-1А раньше парсить было удобнее иначе? Или Томпсон, Ричи и их последователи — мазохисты?)
Crandel
28.05.2017 14:49+3А раньше проблемы еще не было, так как все типы должны были указываться всегда. Большинство новых языков с опциональными типами используют данный синтаксис, компилятор проще, меньше ошибок
forketyfork
25.05.2017 12:34+4В русском переводе «полностью» звучит так, будто нужно вообще выкинуть Java и переписать всё на Kotlin. Слово «totally», особенно в выражении «you should totally...», чаще всего означает «определённо», «обязательно», а вовсе не «полностью».
greendimka
25.05.2017 13:22Скажите, а с переходом на Kotlin придётся постоянно платить JetBrains'ам, или планируются альтернативные IDE?
nerumb
25.05.2017 13:26+1Плагин так же есть под Eclipse и Netbeans. Да и не обязательно покупать Ultimate версию Intellij Idea, подойдет и Community.
manny21
25.05.2017 15:16Почему следует полностью переходить на Kotlin
потому что вам скучно и у вас полно свободного времени
остальные пролистали статью, задались вопросами о рисках для бизнеса не найти разработчика или рисках для разработчика не найти работу, закрыли и забыли
bisor
25.05.2017 15:27-7Очень уважаю IntelliJ, но все эти надстройки над Java ( Scala, Kotlin ....)
Пошла какая-то мода колхозить сверху языка какие-то скрипто-языки, которые транслируются в Java.
Временное явление.
Предпочитаю чистую Java.
e_Hector
25.05.2017 15:37+5Scala и Kotlin не транслируются в Java, а компилируются в байткод, собственно, как и сама Java. Т. е. они не «сверху», а «рядом»
Kopleman
25.05.2017 15:27Не много не по теме: с Java то более менее понятно, а на фронтенде кто то пробовал уже?
AKiNO
25.05.2017 15:31-3Мне кажется, что на современном этапе PR (хайп) и поддержка важных игроков рынка (Google, Pivotal) прежде всего для успеха очередного яызка. Scala это прекрасно, но тот факт, что ни IDEA ни Eclipse не могут корректно поправить импорты в проекте, когда один пакет перемещаешь в другой — реально отталкивает от использования Scala за пределами «домашних» проектов (этим плагинам уже много лет и так и не нашлось силы, которая бы развивала инструменты разработки для Scala). Все-таки для Kotlin ситуация выглядит более радужной (JetBrains, Android, Spring, Gradle — эти товарищи закомитились на поддержку Kotlin уже сейчас).
olonho
25.05.2017 15:37Native существует публично уже третий месяц, недавно мы выпустили v0.2. https://blog.jetbrains.com/kotlin/2017/05/kotlinnative-v0-2-is-out/
lxsmkv
25.05.2017 16:10Я тоже подумал, кто если хочешь написать обзор на язык — напиши туториал. А хайпить язык простым перечислением его синтаксиса — не работает. От этого такое впечатление, что человек сам не разобрался, сам ничего на нем никогда не написал, а другим советует. Ну не катит такое, и все.
(Никоим образом, конечно, это замечание не отностится к переводчику. Ему за труд спасибо.)
Scrobot
25.05.2017 17:13-2Возможно проглядел, и кто-то упомянул, но еще помимо всего прочего котлин может еще в и жабаскрипт фигачить =)
https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html
Так что он идеально подходить не только в андроиде, где он прост бесподобен, но и в веб-отрасли.
KitScribe
26.05.2017 00:43-5Похоже на какую-то помесь C# и Python
Спойлер
Wsl_F
27.05.2017 19:43-1Как Kotlin 100% совместим с Java, если оператор сравнения работает по разному?
Пример из статьи:
val john1 = Person("John") val john2 = Person("John") john1 == john2 // true (structural equality) john1 === john2 // false (referential equality)Sirikid
27.05.2017 20:02ifиtry-catchтоже по разному работают, аtry-catch-finallyвообще как конструкции языка нет. В данном контексте 100% совместимость с Java означает что в Kotlin нету таких конструкций, которые нельзя использовать из Java. В Scala такие конструкции есть, например path dependent types.senia
27.05.2017 20:04Продолжения и inline методы к таким конструкциям не относятся?
Sirikid
27.05.2017 20:52Продолжения, насколько я знаю, просто библиотека. Не знаю инлайнятся ли котлиновские функции в джавовый код, скорее всего нет, но вызывать их точно можно.
senia
27.05.2017 22:05Утверждается, что продолжения из java использовать не получится: https://stackoverflow.com/a/41561165.
И inline не получится: https://stackoverflow.com/a/42742119. Что логично, учитывая реификацию.
Мне импонирует ваша вера в то, что все так, как предполагается наиболее логичным, но, к сожалению, авторы Kotlin столкнулись с объективными трудностями, некоторые из которых разрешили ценой потери совместимости с java, в чем я их поддерживаю.
Еще когда-то они считали, что nullable типы покрывают все аспекты взаимодействия с java кодом в плане nullability, но пришлось вводить «сырые» типы. Это не хорошо и не плохо, это объективная реальность с которой приходится считаться.
Все на этом пути пожертвовали чем-то. И ceylon, и kolin, и scala. Стоит помнить чем именно они пожертвовали и ради чего.Sirikid
28.05.2017 18:04Про овеществленные дженерик-параметры вы ничего не говорили, такие функции вызвать не получится.
I want to believe как говорится :)senia
28.05.2017 18:22Это не единственная фича inline методов, требующая поддержки компилятором на вызывающей стороне. Насколько я помню inline методы из java не видны вообще.
Sirikid
28.05.2017 19:37Видны и вызвать их можно, надеятся что
javacзаинлайнит такие вызовы, конечно, глупо, но когда-нибудь может быть и такое случится.senia
28.05.2017 20:27+2В любом случае тезис о 100% совместимости оказался не верен.
Sirikid
30.05.2017 12:02Жги, Господь, мы все про…
Может это модель такая — сначала быть совместимым, а потом добавлять плюшки ценой потери совместимости?ACPrikh
30.05.2017 12:22-3Это не модель даже, а путь джедаев. Встать на место могиканина. И повести за собой всё Java племя. Для начала: «я такой же как вы, только без хвоста». Я версия Явы. Но там уже забрезжил отказ от JVM и переход на нативный производительный код. Не совместимость, а сместимость. То есть взамен.
Не в белиберду jvm-кода, а нормально, как папа учил.yarric
30.05.2017 16:51+3И кому нужна такая Java без библиотек, простите? В этой нише и так тесно: есть Rust, есть C++, есть Swift в конце-концов. Причем они все без GC.
ACPrikh
31.05.2017 09:18+1Действительно, Rust популярен в последние годы. Это как раз показатель внутренней неудовлетворенности программистов как собственно жавой, так и распиаренного ООП. И язык Go от гугла в ту же степь. Возрождение процедурного подхода, обрезание наследования, борьба за производительность. Ну и удобный параллелизм — железо требует.
Наступление Котлин даже слишком быстрое и напористое по пиару. Это и пугает жабоводов. Ну как же — подошли к их тёпленькой кормушке!yarric
31.05.2017 20:05-1Что-то лучше ООП пока что не придумали.
Лично для меня Kotlin — пока что "один из", я уже писал. Каких-то принципиальных отличий от Java, чтобы бросаться его срочно учить, не видно.
Scf
31.05.2017 20:16+1Придумали. Помните трех китов ООП? Котрые инкапсуляция, наследование и полиморфизм? Так вот, они устарели. Уже давно эксперты голосуют за агрегацию как основной инструмент повторного использования кода в ООП. Потом начали отказываться от концепции JavaBean — иммутабельные классы и чистые функции оказались выгодней.
Современный тренд — это композиция. Т.е. создание операторов, позволяющих естественным образом объединить два и более объектов или функций в один объект. Простейший пример — Stream API в джава, собирающий коллекцию и набор функций в новую коллекцию.
А Java, как язык, к сожалению, не очень хорошо подходит для композиции. Но я уверен, что в Java10 что-нибудь придумают.
yarric
31.05.2017 22:32-1Насколько я вижу функциональное программирование дополняет ООП в некоторых местах (например удобно для обработки списков), если же мы хотим что-то моделировать, то тут ООП замены нет, поскольку оно ближе всего к реальному миру. Например наследование позволяет избавиться от копипейста и обеспечить абстракцию и SOLID — что его заменяет в функциональном программировании?
Scf
31.05.2017 23:04ФП — это слишком громко сказано :-). Чистое ФП достаточно сложно и в массы навряд ли пойдет.
Насчет объектов и реального мира, вот цитата из классика:
О проектировании иерархии классов говорили все, кому не лень — одни по делу, другие болтали «об имитации объектов реального мира».
Jeff Alger, «C++ for real programmers»
Проблемы копипаста в большинстве своем лучше решаются агрегацией.
В чистом ФП нет наследования и поэтому понятие полиморфизма к нему неприменимо. Вместо него использутся лямбды и абстрактные типы. Например, если в классическом ООП у нас есть interface Colored { Color getColor(); }, то в ФП это будет выглядеть так:
void drawColored <T>(T object, Function<T, Color> getColor) //getColor получает экземпляр T и возвращает его цвет
ACPrikh
01.06.2017 10:57-2ООП — вообще не технология. Это коммерческий пиар в голом виде. Инкапсуляция — чисто для сокрытия кода. Поэтому появилась инкапсуляция без сокрытия. Какой в здравом уме программист предпочтёт скрывать код и использовать что-либо в виде черного ящика? Damn DLL Hell! А вот проблемы копирайта он замечательно решает. Именно с сокрытием.
С наследованием всё ясно — всё более и более обрезается и обрезается по факту с каждым свежим языком.
Полиморфизм никогда и не работал, как было заявлено в начале.
Объекты к объектам реального мира отношения не имеют никакого, а являются лишь структурой данных с присобаченным интерфейсом. Синтаксический обман.
И главное. Все объекты собраны в иерархии. Топологически -дерево. Это самая простая топология, которую можно вообразить для графа. Количество связей минимально — на 1 больше, чем элементов.
Элементы объектов реального мира связаны практически всегда намного большим количеством связей. Наличие обратных связей — колец основа кибернетики, о которой кодеры забыли от слова «совсем».
А почему так произошло? О потому, что царство ООП заменило алгоритмы, модели объектов реального мира на иерархии деревьев классов, нанизанных искуственным наследованием.
Да, Котлин «один из». Но уже помазанник Гугла.yarric
01.06.2017 11:44+2Ну так и какая же альтернатива? Обвешиваться "открытым кодом"-копипейстом? Код большинства библиотек и так открыт — всё равно никто не захочет использовать библиотеки, в которых придётся смотреть код. Черные ящики в мире на каждом шагу — никто не пользовался бы мобильным телефоном, если бы нужно было знать детали реализации команд процессора.
помазанник Гугла
А сколько даже своих собственных проектов Гугл уже закопал…
ACPrikh
01.06.2017 15:59-2Пользоваться мобилкой — это про программистов или про пальцетычеров? Аргумент просто убийственный.
Копипейст это как раз про нашёл в инете и скопипастил решение из библиотеки без включения головы.yarric
01.06.2017 20:09+1программистов или про пальцетычеров
Да хоть про разработчиков интегральных схем: один разрабатывает AC/DC, другой ALU, третий — RAM, четвёртый — IO, а потом всё это интегрируется. Без крайней необходимости никто не вникает в детали реализации чужих блоков.
DistortNeo
27.05.2017 23:06+2От совместим точно так же, как совместимы C# и Visual Basic — на уровне сборок / библиотек классов.
rjhdby
29.05.2017 18:26А еще можно задавать многострочные строки, без плясок с бубном :)
val string = """This is
multiline
string"""
SilentRider
29.05.2017 18:44На самом деле все-таки не совсем без плясок.
Если важны отступы в строчках и одновременно хочется видеть красиво отформатированный код, то, насколько мне известно, сейчас нет способа это сделать в compile time. Вместо этого есть несколько костылей типого такого.
Также, одновременное отключения экранирования в многострочных строках (на самом деле они не многострочные, а просто сырые) и поддержка интерполяции в них приводят к конструкции${'$'}, когда нужно чтобы строка содержала$.rjhdby
29.05.2017 22:33Но согласитесь, что всяко удобнее нежели чем как в Java. С интерполяцией, думается мне, можно попробовать попедалировать тему на предмет добавления, например, синтаксиса '''text''', а-ля HEREDOC/NOWDOC.
Что же касается красивого форматирования при необходимости соблюдения отступов, то я слабо себе представляю, как такое можно по человечески реализовать. Если же вы вдруг знаете, где это реализовано, то поделитесь ссылочкой — с удовольствием поизучаю.yarric
30.05.2017 00:24В нормальных IDE достаточно нажать перевод строки внутри строкового литерала, плюсики будут расставлены автоматом.
SilentRider
30.05.2017 01:50-1Бесспорно, это в разы удобнее, чем в Java.
Подобное поведение реализовано в Rust. Конечно, там тоже не все так гладко, так как\в конце строки так же убирает и сам перевод строки, и если он нужен, приходится вручную добавлять\n. Но лично для меня такая реализация выглядит несколько более приятной.
m1ld
30.05.2017 10:15Ох же эти изобретатели велосипедов. Каждый мечтает сделать своё.
Вместо объединения усилий и создания действительно единого пространства для разработки всего и вся.lxsmkv
30.05.2017 11:23+3причина совсем не в этом. Даже если бы все сели вместе разрабатывать единый язык программирования в каменном веке, дискуссия длилась бы до сих пор. Потому проще сделать свое чем заставить кого-то поменять точку зрения.Это раз. И два, это то что не всегда измененение существующего продукта целесообразно. Некоторые вещи лучше оставлять как они есть.
relgames
01.06.2017 10:49+2Язык, может, и хорош.
Но останавливает JetBrains.
Нет ни одного релиза IDEA, где не было бы что-то сломано. Некоторые баги не фиксят годами.
При этом я не вижу, чтобы они сами писали на Котлине. Отдельные проекты есть, тесты в IDEA, но это капля в море.
TheKnight
01.06.2017 13:26А что не капля в море?
relgames
01.06.2017 13:35Они говорили, что будут IDEA писать на Kotlin. Наверное, не такой хороший язык, если они сами его с опаской используют. Выше писали, что лишь отдельные тесты на Котлине.
mayorovp
01.06.2017 14:08-2IDEA уже как бы давно написана
relgames
01.06.2017 15:52Как это противоречит моему комменту?
Вот в 2013 году, например, я высказывал те же опасения
https://habrahabr.ru/company/JetBrains/blog/168265/#comment_5825955
За 4 года ничего не изменилось — язык сырой и сама IDEA его не использует.
nerumb
01.06.2017 15:51Ну на самом деле они у себя его вовсю используют. Код на Kotlin в продакшене начал использоваться еще с начала его создания (вроде 2011) и у них же проходил боевую обкатку. Сейчас полностью на Kotlin написан сервис авторизации. В Rider фронтенд также полностью написан на Kotlin. Как минимум еще тесты пишутся также на Kotlin. В своем новом проекте они также используют Kotlin.
Сам язык постепенно проникает в их проекты. Нет смысла все сразу переписывать на Kotlin, они для того и делали язык с осознанием того, чтобы он прекрасно дружил с большой кодовой базой на Java.relgames
01.06.2017 15:53Заголовок статьи: «следует полностью переходить на Kotlin»
Перейдем, как только все новые фичи в IDEA будут писать полностью на Kotlin :)nerumb
01.06.2017 16:01-1Вам бы пообщаться в живую с Андреем Бреславым, ну или посмотреть его выступления… зарядиться Kotlin'ом…
А по поводу этой статьи, она мягко говоря не очень удачная, вместе с картинкой сверху. Больше смахивает на троллинг перехода на Kotlin.
В Kotlin есть одно неоспоримое преимущество, с ним будет больше ежедневного «фана» (original: fun) чем в других языках =)
alesto
Интересно. Местами выглядит как родной для меня c#
Stridemann
Скорее жабоскрипт чем C# (вырвиглазное объявление переменных)
madDig
Мне больше TypeScript напоминает.
northicewind
И не только вам kotlin-is-like-typescript
SergeiD
Это не удивительно, Kotlin много заимствовал синтаксиса из Pascal (Delphi), а идеолог TypeScript разрабатывал Delphi в Borland.
DrPass
Собственно говоря, и С# тоже проектировал этот же господин.
vasIvas
И не удивительно, ведь typescript имеет самый совершенный синтаксис на сегодня.
Было бы здорово если бы и он компилировался в java.
JC_IIB
Не согласен. Но это дело вкуса.
Dmitry_4
У бэйсика или ассемблера гораздо более приятный синтаксис.
LoadRunner
Вы просто не пробовали писать сразу в опкодах.
funky_busturd
лучше чем у лиспа не будет синтаксиса
djank
возьми ещё этих мягких лисповых скобок
Kassab
Самый совершенный синтаксис — у Parser Студии Лебедева )
DistortNeo
Так и есть. Иногда, глядя на фрагмент кода, сложно понять, на каком языке он написан: C# или Java.
Изначально C# создавался как конкурент Java, но с более богатыми языковыми возможностями. И это сохраняется и до сих пор.
Дело в том, что ввод новых фишек в Java — процесс медленный и конфликтный, тогда как у C# разработчик один. И можно легко проследить, что сначала новые языковые возможности появляются сначала в C#, а затем через пару лет перекочёвывают в Java. Это, кстати, одна из причин, почему я и пишу на C#, а не Java.
Вот умные люди решили, что лучше создать новый язык, чем бодаться с корпорациями. И велика вероятность, что этот язык не станет мёртвым.
А самое крутое было бы, если бы JVM и CLR допилили до такого состояния, чтобы они стали эквивалентны по своим возможностям. Писать на C# под JVM было бы весьма заманчиво.
aquamakc
Xamarin же.
byme
Xamarin работает на CLR, которая встраивается в основное приложение.
PsyHaSTe
Ждем переезда на Core и все станет хорошо.
yarric
Создание альтернативных языков для JVM и .NET уже превращается в специальную дисциплину. Их уже много наклепали в надежде прославиться, но при этом не напрягаться с созданием собственной библиотеки классов.
DistortNeo
Как раз с библиотеками классов проблем нет ну совсем никаких. Их в принципе не нужно разрабатывать, потому что они есть изначально.
Проблемы таких языков исключительно в IDE. Вы можете изобрести супер язык, но без полноценной IDE он будет бесполезен. Здесь же отличие в том, что язык разрабатывают сами создатели IDE.
yarric
В качестве IDE обычно используется заточенный Eclipse, или плагин для Eclipse.
DistortNeo
Спасибо, не надо.
yarric
Ну можно и плагин для IDEA написать или найти, дело вкуса. Под Eclipse их гораздо больше.