[Программирование, Java, Kotlin] Почему Kotlin лучше Java?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Это ответ на переведенную публикацию «Почему Kotlin хуже, чем Java?». Поскольку исходная аргументация опирается всего на два примера, то не теряя времени пройдем по этим «недостаткам» Kotlin.Проприетарные метаданные?
изрядное количество подробностей внутренней работы kotlinc скрыто внутри сгенерированных файлов классов...без IDEA Kotlin немедленно умрет
Это не проприетарный код, а просто способ для компилятора дописать дополнительные данные в жестко заданном формате .class-файлов, который ранее был заточен только под javac. Метаданные нужны для рефлексии и их можно удалить при компиляции. Исходный код метаданных открыт и общедоступен.Kotlin будет отставать?Вкратце, посыл исходной статьи таков, что Kotlin был иновационным, но Java добавит все те же языковые возможности, только продуманее и лучше, и уже Kotlin-вариант выпадет из мейнстрима.
В качестве примера автор приводитinstanceof:
В Kotlin сделали примерно так
if (x instanceof String) {
// теперь x имеет тип String!
System.out.println(x.toLowerCase());
}
Но в Java версии 16+ стало так:
if (x instanceof String y) {
System.out.println(y.toLowerCase());
}
Получается, что оба языка имеют способ обработать описанный сценарий, но разными способами. Я уверен, что если бы мог вдавить огромную кнопку «сброс», разработать Kotlin с нуля и снова выпустить сегодня бета-версию, то в Kotlin было бы сделано так же, как сейчас в Java. Учитывая, что синтаксис Java более мощный: мы можем сделать с ним намного больше, чем просто «проверить тип» (например, «деконструировать» типы-значения).
...
Ему придётся опираться только на себя и перестать рекламировать доступность всех преимуществ Java и её экосистемы. Пример с instanceof уже демонстрирует, почему я думаю, что Kotlin не будет лучше Java: почти каждая новая фича, которая появилась в Java недавно или вот-вот появится (в смысле, имеет активный JEP и обсуждается в рассылках) выглядит более продуманной, чем любая фича Kotlin.
Этот аргумент вызван плохим знанием Kotlin. Автор использовал неидиоматичный подход, и вся его критика по сути направлена против своего же неверно написаного Kotlin кода. На самом деле, стоит прочесть лишь вводную страницу документации по базовым инструкциям (чего автор видимо не сделал), чтобы понять что Kotlin вариант не только более лаконичный, но и намного функциональнее, судите сами:
when(val v = calcValue()) {
is String -> processString(v)
}
Здесь в одной области можно проверить сразу несколько типов вместе со значениями, без создания дополнительных переменных. Попробуйте повторить в Java c if/instanceof/switch:
when(val v = calcValue()) {
is String -> processString(v)
42 -> prosess42()
is Int -> processInt(v)
else -> processElse(v)
}
Остается разобраться с аргументом, что Kotlin, якобы, придется что-то делать с изменениями вносимыми Java, адаптироваться или расходиться, что это, якобы, создает проблему развития для Kotlin.
Прямо сейчас Kotlin оседлал волну успеха, но со временем жизнь его будет тем тяжелее, чем шире будет зазор между ним и Java, и чем сложнее будет преодолеть этот зазор.
Здесь автор путает местами причину и следствие, пытаясь выдать Kotlin за догоняющий язык. На самом деле, адаптация новых возможностей это в первую очередь проблема именно для Java. Именно новые возможности таких конкурентов как C# и Kotlin подстегивают Java изменяться, и именно для Java сложнее это сделать по причине изначально тяжеловесного и сложившегося за десятилетия синтаксиса, не предусматривавшего появление новых, функциональных возможностей. В Java-парадигме для них попросту осталось не так много места, где их можно прикрутить к синтаксису, и именно поэтому они выглядят чужеродно обременительно для восприятия.
Нативная поддержка null, которая греет душу любого котлиниста, легко заменяется в Java на обёртку из Optional.ofNullable. Data-объекты могут быть заменены более богатым функционалом record.
Все догоняющие возможности Java содержат фатальные изъяны по умолчанию, все больше заставляют прибегать к соглашениям, а не к дизайну языка. Вместо Optional можно передать null, а record ничуть не более богатый чем data class.
Как думаете, сохранит Kotlin свою популярность через пять лет и почему?
Некоторые в комментариях к исходной статье вспомнили историю Scala и Java. Но есть и другая история, история того что сделал С++ со старым Си.
Несомненно, Java останется там где нужно поддерживать старые решения. Однако новые решения будут все больше писаться на Kotlin, пока он не станет языком по умолчанию, как это уже произошло в Android экосистеме, и прямо сейчас происходит для backend разработки в jvm экосистеме. Kotlin не просто лучше, он дает думать в другой парадигме, открыт для новых возможностей, страхует от многих ошибок на этапе компиляции.
===========
Источник:
habr.com
===========
Похожие новости:
- [Perl, Ruby, PHP, Python, JavaScript] Насколько вам наплевать на фичи последней версии языка?
- [Программирование, Совершенный код] Практическое руководство по именованию классов, функций и переменных (перевод)
- [Python, Программирование, Совершенный код, Научно-популярное] Разукрашиваем вывод в консоли: теория и практика
- [Python, Программирование, Работа с 3D-графикой, Учебный процесс в IT] 3D teeth instance segmentation. В темноте, но не один
- [Программирование микроконтроллеров, Схемотехника] USB на регистрах: isochronous endpoint на примере Audio device
- [Программирование, Анализ и проектирование систем, Хранение данных, Хранилища данных] Транзакции. Часть 2. Конспект книги «Designing Data-Intensive Applications»
- [Open source, Программирование, Геоинформационные сервисы, Визуализация данных, Научно-популярное] Легенды и мифы геофизики
- [Программирование, Звук] Старт в музыкальном программировании — для начинающих достаточно и простого браузера
- [CMS, PHP, MySQL, JavaScript] CS Cart или через терни к черной дыре костылей и оптимизаций
- [Программирование, C++] Мета-программирование атрибутов для сериализации
Теги для поиска: #_programmirovanie (Программирование), #_java, #_kotlin, #_java, #_kotlin, #_jvm, #_jetbrains, #_programmirovanie (
Программирование
), #_java, #_kotlin
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Ноя 20:13
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Это ответ на переведенную публикацию «Почему Kotlin хуже, чем Java?». Поскольку исходная аргументация опирается всего на два примера, то не теряя времени пройдем по этим «недостаткам» Kotlin.Проприетарные метаданные? изрядное количество подробностей внутренней работы kotlinc скрыто внутри сгенерированных файлов классов...без IDEA Kotlin немедленно умрет
В качестве примера автор приводитinstanceof: В Kotlin сделали примерно так
if (x instanceof String) {
// теперь x имеет тип String! System.out.println(x.toLowerCase()); } Но в Java версии 16+ стало так:
if (x instanceof String y) {
System.out.println(y.toLowerCase()); } Получается, что оба языка имеют способ обработать описанный сценарий, но разными способами. Я уверен, что если бы мог вдавить огромную кнопку «сброс», разработать Kotlin с нуля и снова выпустить сегодня бета-версию, то в Kotlin было бы сделано так же, как сейчас в Java. Учитывая, что синтаксис Java более мощный: мы можем сделать с ним намного больше, чем просто «проверить тип» (например, «деконструировать» типы-значения).
... Ему придётся опираться только на себя и перестать рекламировать доступность всех преимуществ Java и её экосистемы. Пример с instanceof уже демонстрирует, почему я думаю, что Kotlin не будет лучше Java: почти каждая новая фича, которая появилась в Java недавно или вот-вот появится (в смысле, имеет активный JEP и обсуждается в рассылках) выглядит более продуманной, чем любая фича Kotlin. when(val v = calcValue()) {
is String -> processString(v) } when(val v = calcValue()) {
is String -> processString(v) 42 -> prosess42() is Int -> processInt(v) else -> processElse(v) } Прямо сейчас Kotlin оседлал волну успеха, но со временем жизнь его будет тем тяжелее, чем шире будет зазор между ним и Java, и чем сложнее будет преодолеть этот зазор.
Нативная поддержка null, которая греет душу любого котлиниста, легко заменяется в Java на обёртку из Optional.ofNullable. Data-объекты могут быть заменены более богатым функционалом record.
Как думаете, сохранит Kotlin свою популярность через пять лет и почему?
Несомненно, Java останется там где нужно поддерживать старые решения. Однако новые решения будут все больше писаться на Kotlin, пока он не станет языком по умолчанию, как это уже произошло в Android экосистеме, и прямо сейчас происходит для backend разработки в jvm экосистеме. Kotlin не просто лучше, он дает думать в другой парадигме, открыт для новых возможностей, страхует от многих ошибок на этапе компиляции. =========== Источник: habr.com =========== Похожие новости:
Программирование ), #_java, #_kotlin |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Ноя 20:13
Часовой пояс: UTC + 5