Comments 325
такую конструкцию я встречал только в Kotlin! TypeScript не беру т.к. там влияние Pascal четко прослеживается.
Go:
var i int
Swift:
let greeting = "Hello, " + person + "!"
var currentMin = array[0]
var name: String?
Процесс пошёл, как говорится. Ну и старые Pascal-like языки можно вспомнить (хотя из них сейчас жива только Ada в хорошо изолированных клетках).
Было бы здорово если бы и он компилировался в java.
Так и есть. Иногда, глядя на фрагмент кода, сложно понять, на каком языке он написан: C# или Java.
Изначально C# создавался как конкурент Java, но с более богатыми языковыми возможностями. И это сохраняется и до сих пор.
Дело в том, что ввод новых фишек в Java — процесс медленный и конфликтный, тогда как у C# разработчик один. И можно легко проследить, что сначала новые языковые возможности появляются сначала в C#, а затем через пару лет перекочёвывают в Java. Это, кстати, одна из причин, почему я и пишу на C#, а не Java.
Вот умные люди решили, что лучше создать новый язык, чем бодаться с корпорациями. И велика вероятность, что этот язык не станет мёртвым.
А самое крутое было бы, если бы JVM и CLR допилили до такого состояния, чтобы они стали эквивалентны по своим возможностям. Писать на C# под JVM было бы весьма заманчиво.
Писать на C# под JVM было бы весьма заманчиво.
Xamarin же.
Создание альтернативных языков для JVM и .NET уже превращается в специальную дисциплину. Их уже много наклепали в надежде прославиться, но при этом не напрягаться с созданием собственной библиотеки классов.
Как раз с библиотеками классов проблем нет ну совсем никаких. Их в принципе не нужно разрабатывать, потому что они есть изначально.
Проблемы таких языков исключительно в IDE. Вы можете изобрести супер язык, но без полноценной IDE он будет бесполезен. Здесь же отличие в том, что язык разрабатывают сами создатели IDE.
Это и не удивительно. Андрей не скрывает, что они взяли много разного из разных языков.
Осталось понять на сколько хорош его транслятор.
Не всегда рабочий, а иногда даже компилирующийся, но с привнесенными багами. Транслировать без ревью нельзя!
Меня интересует как вся эта магия с динамическими кастами транслируется в систему типов Java. И как это сказывается на памяти и производительности.
А где вы увидели динамические касты? О_о
Но ведь нет никакой магии в Smart Casts.
Просто если компилятор может вывести, что переменная на данном участке программы имеет более "узкий" тип, то компилятор позволяет использовать особенности этого типа, автоматически расставляя касты, если это нужно.
С точки зрения java/байткода это либо простой каст к подтипу, который бы в java пришлось ручками писать, либо же это каст от nullable типа к not nullable, что отражается только в том, что в коде можно писать . вместо ?. и никак не отражается в сгенерированном байткоде.
Соответственно это никак не отражается на памяти и производительности по сравнению с java.
Думал, хоть что-то из практики применения будет.
А тут очередная копипаста документации.
Не соглашусь. Да, перечисление фич, но это те фичи, которые реально вырастают из практики. Многие из них мне, как прикладному программисту на С++, очень хотелось бы использовать для повышения читаемости и надежности кода команды (или это уже есть в C++ и активно используется).
Например, именованные аргументы исключают ошибки, когда путаются местами параметры одинакового типа, и повышают читабельность функций с многими аргументами. Цена такой ошибки — от 2 минут до многих часов отладки. Читабельнось экономит кучу времени при анализе чужого и позапрошлогоднего своего кода.
Аналогично:
- when (иначе — длинные ошибкоемкие цепочки if-else для небанальных случаев)
- декомпозиция (удобный возврат нескольких аргументов из функции, иначе приходится создавать на каждый чих структуру либо нарушать RAII)
- not nullable (в С++ можно использовать &, но это не всегда достаточно гибко и трудно переучить народ),
- перегрузка операторов (читаемость математики)
Конечно, сами по себе эти вещи не должны побуждать сразу сменить язык (тут автор статьи перегнул), но забота о таких неочевидных практических деталях показывает, что разработчики языка приближены к жизни и имеют хороший опыт коммерческой разработки.
декомпозиция (удобный возврат нескольких аргументов из функции, иначе приходится создавать на каждый чих структуру либо нарушать RAII)
А чем tuple/tie не подходят?
Для tie надо заранее заводить переменные, к которым привязываешь значение (т.е. нарушение RAII). Есть в 17-м стандарте Structured Bindings (https://skebanga.github.io/structured-bindings/) — ровно то, что нужно, но пока они еще далеко не везде реализованы.
Тем, что параметры получаются неименованные.
коммерция
Когда Kotlin станет мейнстрим-языком, значение компании JetBrains для рынка Software Engineering, на котором она работает, будет совершенно другим. То есть, про нас будут говорить, что мы не какие-то ребята, которые делают удобные, но в любой момент заменяемые инструменты, а как про тех, кто делает некоторую корневую фичу экосистемы, на которой всё строится. Это другой вес, другой информационный поток, и деньги, я думаю, тоже другие.
А станет ли?
Пока что на hh.ru есть 320 резюме, где указано слово Kotlin. Либо всё ещё впереди, либо...
То есть предлагается выучить новый язык чисто во славу JetBrains. Называется "not invented here".
Интересно, переводит ли JetBrains свои проекты на Kotlin.
Это должно быть мотиватором для тех, кто не осилил Scala?
Может и к Скале
Про скалу вечно пишут что Мартин сошел с ума и пренебрегает Enterprise в пользу своих академических интересов. Я с этим решительно не согласен.
https://github.com/lampepfl/dotty/issues/2491
Парни, которые понаписали много кода на скале уже думают, что им делать — переписывать все или вечно сидеть на устаревшей версии.
https://github.com/lampepfl/dotty/issues/2491#issuecomment-304212551
В обсуждении восторги явно не доминировали и решили, что оно того не стоит.
Akka, Spark можно легко использовать в Kotlin и их не нужно переписывать если они вам нужны.
Хотя оригинальные штуки на Kotlin уже появляются, вот например очень интересный проект https://github.com/corda/corda
Кроме того JVM тем и хороша — если давать удобный Java Interface, то можно свободно мешать языки в проекте.
>(опустим compileStatic и core.typed
Почему опустим-то? Практической разницы — почти никакой.
Очень низкое быстродействие по сравнению с джавой, непонятные перспективы из-за отсутствия финансирования. groovy-eclipse заброшен и только благодаря jetbrains этот язык еще на плаву.
>только благодаря jetbrains
да что вы говорите? А я думал благодаря gradle…
Так что понять авторов котлина вполне можно — они пытаются создать очередной компромисс.
P.S. Я вовсе не хочу сказать, что у котлина все хорошо. Тут еще посмотреть надо будет.
Ну какая ломка? О чем вы?
У скалы с этим нормально все. Поддерживается совместимость в рамках мажорной версии.
Для 11-й версии это порядка 5 лет. Ну вот нафига нужны библиотеки которые 5 лет не поддерживаются?
Кейсы получения проблем в этом месте настолько малы, что не стоит заморачиваться.
А даже если прижмет где-то, можно пересобрать под актуальную версию…
>Ну вот нафига нужны библиотеки которые 5 лет не поддерживаются?
Ну скажем так — работая на java, я вам таких покажу сотни. То есть тут этой проблемы нет вообще, исключения редчайшие.
У всех библиотек обязательно есть версии _2.10, _2.11, потому что иначе не работает, одни уже дропнули поддержку какой-то там версии, а другие еще не смигрировали… и такая веселуха постоянно. Все отлично в Скале с совместимостью.
Проблемы есть с тем что множество социально-безответственных авторов из всего jvm мира любят прибивать гвоздями определенные версии и включать их в поставку. Типичная ситуация — вязанка netty, сериализатор древней версии и т.д.
По поводу "крупные либы обновляются быстро" — Apache Samza только-только добавила поддержку 2.11.
А вообще, экосистема так не работает. Библиотеки должны оставаться рабочими, даже если вообще некому ими заниматься. В крупных java-проектах сотни-тысячи зависимостей (включая транзитивные), древних версий, многие (не на первом уровне) — давно заброшены, но все это собирается и решает задачи.
Экосистемы, где библиотека=живая библиотека, будут оставаться уделом увлеченных энтузиастов и мейнстримом не станут никогда
Но вот опять сильно передергиваете…
Эти ваши говно энтерпрайзы так и останутся на Java. Им не нужны эти хипстерские замашки с новыми языками.
Те проекты, кому это надо, будут использовать актуальные версии библиотек. Все, что имеет смыл — обновляется регулярно. И с этим нет никаких жутких проблем, описываемых всеми…
Подавляющее большинство древних легаси библиотек никогда не будут переписаны даже под новую Java, не говоря уже про новые языки. И для них так же как и сейчас, будут писать обертки, для удобства.
Все будет происходить ровно так же как сейчас на Java. Многие конторы только сейчас переходят на Java8, много еще сидит на Java6.
То же самое будет и со скалой. Люди будут долго сидеть на мажорной версии. А это все атаки несколько лет поддержки. Потом захотят перейти, обовиться, и либо найдут замену древним легаси библиотекам, либо пересоберут их сами. Ну или, как тоже делают, переосмыслят проект. Возможно и на другом языке. Слишком быстро сейчас все движется, что бы 20 лет сидеть на древних библиотеках…
Еще раз повторюсь, конечно такие конторы есть и будут. Которым надо 20 лет поддержки. Для них есть Java. Все остальные никаких особых проблем с обратной бинарной совместимостью библиотек для Scala не почувствуют…
У меня java6 в 10 магазинах на дебиане пятилетней свежести работает на местах кассира — я не вижу смысла в обновлении ради обновления. У меня есть масса более интересных занятий чем раз месяц кататься по магазинам с обновлениями дебиана на флэшке )
В прошлом годе даунгрейдил библиотеку для печати qr-кодов с java8 на java6, потому что это быстрее и проще. Я невменяемый )
Если вам это не нужно — это немножко другой случай. Особено если вы это приложение не разрабатываете.
У меня другая ситуация — пришли безопасники, и принудительно потребовали обновиться на поддерживаемую Java 8. Возражения принимаются, но не охотно.
По поводу «крупные либы обновляются быстро» — Apache Samza только-только добавила поддержку 2.11.Могу еще спарк привести в пример, но это не значит что это поголовная проблема.
У вас может быть библиотка с какой-то сложной математикой написанной под Java 1.4. И при переходе на Java 8 она все еще будет корректно рабоать (и почти наверняка станет работать быстрее).
Вопрос: зачем хоть что-то делать с библиотекой, если за пятнадцать лет математика и формулы не поменялись? Это очень хорошо и важно, когда можно использовать старые библиотеки без изменений. Если этого нет — то экосистема убивает сама себя.
Как ни странно, но математика меняется. И алгоритмы и оптимизации, которые могут быть применены тоже. Не говоря уже про blas библиотеки, которые стоят у многих java либ под капотом. Поэтому про перформанс, который улучшается с годами как вино, не надо говорить.
Понимаю, что это пример был, но он неудачный (опыт собственно был с этим).
Я сам очень люблю Scala, прошёл пару курсов на Coursera, писал программы «для себя» на ней, но как только попробовал Kotlin, так возвращаться к Scala совсем не хочется.
Про 95% это вы так же с потолка взяли, так же как и JetBrains про 100% интероп?
жуткие конструкции с "++=" и прочим
Т.е. в java/kotlin x += 1 понятная конструкция, а вот xs ++= List(1,2,3,4) уже жуткая, если учесть конкатенация двух списков это ++
В Котлин придостаточно жутких конструкция по типу
thing?.thing1?.thing2 ?: 10или сложных конструкций по типу делегатов, которые Джавистам не знакомы. Я лично до сих пор не могу понять как работают эти делегаты.
Kotlin почти не сложнее Java, он не про «сделать новый сложный, мощный и красивый язык», а про «убрать болевые точки, упростить стандартные паттерны, не делая дороже совокупную стоимость владения и переиспользуя текущих людей». Поэтому, например, у Kotlin есть кросс-трансляция в Java и обратно, поэтому гарантируется полная интероперабельность с Java-кодом, а не как в Scala, когда Scala-классы из-под Java использовать зачастую нереально больно, если только они изначально не проектировались с расчетом на этом.
Для личных проектов for fun я бы выбрал Scala — она интересная; для бизнес-проектов — Kotlin — это стабильно, удобно и лучше в плане цена/качество.
Не претендую на истину, конечно, но для меня это выглядит так.
Scala мощная и красивая, но за ней необходим очень-очень тщательный уход, чтобы избежать появления «i >>#$<<+=$ j col **%%# k», нужны очень дорогие разработчики и лид из-за высокого порога вхождения, дорого передавать проект другой команде.
Чтобы такие символы не появлялись, нужно код ревью. Стоимость разрабов этому ортогональна.
То сложное, что скала позволяет делать, завязано на работу с типами. Нужно в реализации приложений редко и можно обойтись. Как раз для таких финтов и нужны более дорогие разрабы.
По-моему, после нескольких лет серьезной разработки становится все равно, на каком языке писать. Если у меня долгоиграющий проект, то я буду его продолжать на том языке, на котором написана большая часть кода, хоть на дельфи.
Если у меня новый проект, то я буду смотреть на:
- наличие специалистов в команде
- лицензионные ограничения
- требования к рабочему окружению
- среду разработки
- возможности стандартной библиотеки
- наличие сторонних библиотек
- поддержку параллелизма
- перспективу развития
- интеграцию с инструментами документирования, багтрекинга, управления ЖЦ, Continuos Integration и т. п.
и где-то там, пунктов на 10 ниже, будет синтаксис.
Поэтому описание особенностей синтаксиса не отвечает на вопрос из заголовка: «Почему следует полностью переходить на Kotlin».
В плане меньше печатать — это к фреймворкам типа Spring. Интересно, есть ли подробные гайды по использованию Spring в Kotlin...
https://kotlinlang.org/docs/tutorials/spring-boot-restful.html
не сказал бы что это прям гайды, просто несколько фактов, которые полезно знать. А в целом гайды нужны именно для использования Spring, а уж использование его в Kotlin ничем не отличается от использования апи других библиотек/фрэймворков
если же интересуют именно подобные посты на хабре, то да, тут были несколько:
https://habrahabr.ru/post/274997/
https://habrahabr.ru/post/274713/
Из опыта работы был долгоиграющий проект на FORTH, и писали…
интеграцию с инструментами документирования, багтрекинга, управления ЖЦ, Continuos Integration и т. п.
Как язык программирования должен интегрироваться с багтрекерами? Подсветка синтаксиса разве что.
В некоторых случаях это может быть очень важно. Например, есть такая штука как SSIS-пакеты, в них практически невозможно изменения сматчить с дефектами, потому что там файлы почти бинарные. И разумеется, разработчики, когда их начинали писать, читали интересные статьи о том, какая это классная штука.
В части багтрекинга мне было бы достаточно, если бы в багтрекере была подсветка синаксиса, а в IDE работали бы ссылки из комментариев вида // Also see Issue 166;.
Почему… почему в каждой статье пишут про 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 только с сахаром.
Если почаще кричать, то толпа не будет задумываться, а хайп покроет все.
Когда пыль рассеется, поздно будет давать заднюю…
А по поводу интеграции в Джаву вообще вопрос интересный. Вот реально субъективно возникает меньше ощущения «другой» платформы, чем от Скалы, хотя на Скале промышленно писать не доводилось.
Банальный пример, Скала:
collection.mutable.Map[String, String]().isInstanceOf[java.util.Map[String, String]] // false
и Котлин
emptyMap<String, String>() is java.util.Map<*, *> // true
И хотя у Скалы есть asJava, но все равно не используя полностью всю мощь коллекций Скалы наверное жить в мире Скала не очень весело.
Еще Котлин хорошо интегрируется во все системы байт-код «хакинга» (типа Мокито, хотя и не без проблем), анализа и т.п. Поэтому с ним работают Спринг (официально) и даже магические библиотеки типа Quasar (которые от поддержки Скалы отказались как раз по причине заморочек с байт-кодом). Т.е. Котлин чувствуется именно что «лучшей Java-ой», а Скала все таки другим языком и иногда даже другой платформой. Что в целом не плохо само по себе.
На какой-то конференции была фраза, что Котлин и Джава достаточно похожи, чтобы можно было легко перейти с одного языка на другой, но достаточно разные, чтобы этот переход того стоил.
А по поводу интеграции в Джаву вообще вопрос интересный. Вот реально субъективно возникает меньше ощущения «другой» платформы, чем от Скалы
Безусловно интеграция с джавой у Котлина лучше (и наверное лучше чем у любого другого JVM языка), по поводу этого не спорю. Но лучше, это относительное понятие, а не величина. Если мы говорим про цифры, то эти цифры должны быть подтверждены (а если нет подтверждения, то какой смысл в конкретных величинах?), тем более если мы говорим про громогласное заявленное на офф сайте 100%. 100% — значит что мы должны иметь возможность без костылей вызвать это в Java, не смотря на сколько это "чужеродно". И такие "чужеродности" не только с suspend method их ещё много, все это придется пережить и узнать кто будет использовать Котлин, выполняя роль тестировщика языка.
Я бы не советовал как пример приводить вызов suspend методов.
Осталось сделать такой список на офф сайте Котлина: "Мы не советуем вам использовать эти фичи Kotlin'а т.к. вы потеряйте интероп" и я бы даже слова не сказал. Или ещё лучше какой-нибудь флаг компилятора, который выключал все эти фичи и позволял бы писать на каком-нибудь подмножестве Котлина, который бы имел интероп. Потому что уже сейчас появляются библиотеки на Котлине, которые используют спицифичные для Котлина фичи, и которые сложно вызывать из Java, но создатели этих либ особо об этом не парятся. В результате получается своя экосистема, такая же как в Clojure или Scala.
Еще Котлин хорошо интегрируется во все системы байт-код «хакинга» (типа Мокито, хотя и не без проблем), анализа и т.п. Поэтому с ним работают Спринг (официально) и даже магические библиотеки типа Quasar
Если вы посмотрите issues лист Quasar, то увидите что там достаточно специфичных багов связанных с использованием Котлина.
А с ними что не так?
с extension methods все отлично, вот только проблема в том в Java их нет. Приходится вызывать статические методы. Особенно это уродски выглядит когда либа на Котлине их использует повсеместно.
companion object приходится анноторивать @JvmStatic, что бы можно было нормально из Java вызывать, вот только к сожалению часто их не аннотируют почему-то.
на скале вызывать почти невозможно
Да уж невозможно конечно. Поэтому большинство мейн-стримовых скаловских фреймворках доступны из java.
В котлине таких проблем нет
Есть с тем же suspend methods. Или вы собрались использовать некое подмножество языка? Ну так это можно так с X где X любой JVM язык.
К слову, большенство кода написанного на скале вызывать почти невозможно.
Дело не в выигрышах или проигрышах, а дело в заявленных 100%, смотрите я ответил выше. Особенно это актуально для Джавистов, если они собрались потом использовать Котлиновский код.
… делает Kotlin идеальным инструментом для создания [DSL](C:\Users\Desktop\Cloud Mail.Ru\Mail — Почему нужно полностью переходить на Kotlin\в Kotlin). Anko — пример DSL...
Мне кажется, что что-то не дописано...
А вообще, конечно, «это уже было в Симпсонах» (с)
Под native же ещё native-библиотека понадобится, язык на этом фоне будет незначительной проблемой.
К чему это я? Стараюсь, упорно стараюсь найти use-case для Kotlin, и native звучит как некоторый возможный задел на будущее. Однако в данный момент — не нужно.
А вот мне понравился Fantom, давайте переходить на него. Приятный синтаксис с сахарком, плюс совместим с JVM и .NET, плюс существует дольше — проверен временем.
Чем-то напомнило — https://www.parser.ru/
А не наоборот ли? Или Kotlin первый появился?
Проекту, где я тружусь, уже больше 3-х лет. Мы последовательно попробовали Java, Groovy, Scala, Kotlin (последние полтора года).
Итого: победил Kotlin, Java и Groovy остались только в виде legacy, причем Groovy только в тестах (из-за Spock Framework), Scala не прижилась совсем.
Все разработчики смогли относительно безболезненно перейти на Kotlin, а лично я после Groovy и Scala просто сел и начал писать.
Действительно, не все фичи Kotlin удобно использовать из Java, в обратную сторону таких проблем не наблюдается.
Итого: если legacy вас не сдерживает — пробовать можно, нужно и приятно. Если сдерживает — просто немножко подумайте над API ваших компонентов.
Астрологи объявили год поклонения Котлину. )) Как это знакомо все… Года не проходит, начинаются посты Почему вас стоит… А через год, может и от этого же автора про другой язык и что Х, оказался не так хорош и бла бла. Прямо как с javascript, но там итерации короче — где-то полгода, до очередного просветления.
А что, всем на самом деле так нравится синтаксис Котлина?
Меня он местами выбешивает.
- вместо
var,valзачастую полезнее видеть тип - аналогично
fun— лишний визуальный мусор companion objectдля статических методов и констант выглядит прилепленным сбоку- постоянно приходится использовать
!! - не протикся идеей одного конструктора и впихиванием его и нформации о наследовании в одну строчку
- синтаксис значения по умолчанию для аргумента функции
off: Int = 0явно разрабатывался в Мюнхенском офисе (как по-немецки говорят "сто четые и двадцать", а не "сто двадцать четыре"). - ключевое слово
overrideдля метода — лишний мусор по сравнению с@Override. - по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)
- т.д.
Cинтаксис Java ИМХО значительно гармоничнее, а киллер-фич, значительно повышающих производительность, не обнаружил. Зато намного проще написать в одну строчку код, который потом сложно понять.
1) Одно другого не исключает. Нужен тип — пишите.
2) В котлине вы можете объявить функцию в теле метода, вне класса, в классе. И везде такое объявление выглядит одинаково.
3) Объявляйте константы вне класса, если companion object не нравится.
4) "!!" aka оператор "костыли" — не самая изящная часть kotlin, однако, его почти всегда можно избежать.
5) Не со всем понимаю, о чем речь. Конструкторов может быть больше одного.
6) Сначала выглядит странно, но привыкнуть не сложно.
7) Ключевое слово override гораздо строже, чем аннотация (которой может не быть), и это скорее хорошо.
8) Отсутствие наследования по умолчанию — это явный плюс. Я и в java класс не предназначенный для расширения объявлял final, и таковых всегда было большинство. Вообще в большом проекте запрещение всего, что явно не разрешено, чаще сказывается благотворно.
по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)
Читайте Effective Java
Судя по большинству приведенных пунктов, простите, но у вас Java головного мозга.
Это спорно. Да, есть традиция (которую сохраняет C и потомки), что формат определения переменной — «тип переменная [=начальное]», в противоположность традиции, известной по Pascal и прочим — «var переменная: тип [=начальное]». Но сишная традиция заметно усложняет парсинг (уже лексер должен отдавать, чем является идентификатор — типом, переменной, чем-то иным; или парсер должен справляться с неоднозначностями уже после построения конструкций), формат записи (все эти foo (*fptr)(bar) долго учатся новичками)…
Для сравнения, Go использует паскалевский вариант (только ':' убрали — «var переменная тип») — в нём много спорных моментов, но этот явно выглядит как результат идеи прекратить топтаться заново по этим граблям. Swift использует паскалевский вариант. По сравнению же с вот такими чудесами — неудивительно, что пытаются упрощать.
Это же касается и второго замечания:
> аналогично fun — лишний визуальный мусор
та же тема — упрощение грамматики приводит к понятности всем. Дополнительно, такой fun позволяет сделать простой и ясный синтаксис замыканий/лямбд (что показал хотя бы Javascript).
> по умолчанию класс не наследуется (так взяли и задушили всю прелесть OOП)
Это показывает определённый настрой, но не выглядит фатальным — ведь всегда можно умолчание изменить? В C++ умолчание для метода — не виртуальный, в Java/C# — виртуальный, от этого в C++ стало меньше возможности перекрыть метод?
> ключевое слово override для метода — лишний мусор по сравнению с Override.
Ну, тут лучше было бы поступить радикально — как по требованию .NET CLR — метод сделать любой идентификатор, даже совпадающий с ключевым словом. Если это есть — несколько лишних ключевых слов не проблема.
Ну за этим языком не будет Oracle стоять, и вилять своими адвокатами перед носом
С аллокацией на стеке? Вы про что и кто это обещал? Что-то из разряда "слышал звон".
Подозреваю, что вы value types за аллокацию на стеке приняли. В девятке их всё равно не будет. И аллокация на стеке ортогональна value-типам. Джава уже давно умеет не то что на стеке аллоцировать, а в регистры раскидывать объект вообще без аллокации. Или в принципе избавиться от объекта, если позволяет ситуация.
AOT компиляцию и в Котлин быстро завезут, после того как Java 9 выйдет, а синтаксических улучшений в Java 9 примерно ноль
Система лямбд, объединённая с функциями-расширениями, делает Kotlin идеальным инструментом для создания [DSL](C:\Users\Desktop\Cloud Mail.Ru\Mail — Почему нужно полностью переходить на Kotlin\в Kotlin).
Такое чувство, будто обзор на Swift прочитал. Хаха
А вот почему не стоит переходить. Компилятор до ума довели, вопросов нет. Но поддержка в IDE страдает. Каждый раз, когда я влезаю в Котлин, напарываюсь на какую-нибудь неприятность вроде этой. Тонна Java-инспекций в Котлине не работает, хотя имеет смысл, если активно используешь всякие Java API.
А нельзя делать инспекции сразу для двух языков, на каком-нибудь упрощенном синтактическом уровне, общем для Java и Kotlin? Конечно не для все инспекции будут так работать, но по ощущению примерно половина — должна
Можно, но пока довольно ограниченно и без квик-фиксов (см. uast). Да и придётся переписывать кучу существующих инспекций.
Java-разработчики вынуждены жить в постоянном страхе перед NPE
Это какая-то профанация?!
переменная типа String не гарантированно ссылается на String — она может ссылаться на null
Абсолютное непонимание того что такое null, и зачем он «нужен», тем более что приведенный далее код и пояснения не объясняют что же в 'котле' такого инновационного и избавляющего от страха NPE…
и пояснения не объясняют что же в 'котле' такого инновационного и избавляющего от страха NPE
Насколько я понял, kotlin не скомпилирует код, в котором не сделана проверка на null для типа, который может быть нулабл. Эдакая защита от дурака на уровне комплилятора.
Но теряется возможность использовать монадический синтаксис и унифицированный код, работающий с разными типами коллекций
Просто один подход заменяется на другой. Да и для nullable типов в Kotlin есть специальные расширения для коллекций (типа filterNonNull и т.п.)
Да и я бы не сказал, что большое количество '?' делает код сильно проще.
Спорное утверждение, кому что ближе =)
Из своего опыта могу сказать что мне подход Kotlin ближе. К примеру код на Scala:
fun1().flatMap( _.fun2).flatMap( _.fun3) заменяется на fun1()?.fun2()?.fun3() 
Монадический синтаксис — это средство, а не самоцель.
Я не знаком со Scala, но что-то мне кажется, замена опциональных типов (опять таки если я правильно все понял), на nullable, это какое-то слабое утешение. Нет, конечно, это хорошо, что можно отделить корректный и некорректный возврат функции не используя эксепшены (которые дороги, как известно), но если тебе вернули null, то все что ты знаешь, что что-то пошло не так.
Там же где Option подходит, он заменяется успешно на nullable тип. (не везде, да бывают места где лучше оставить Option, но все же в большинстве случаев его можно заменить)
В Rust Option тип может быть любым. Т.е. обычно у тебя возвращает String, а в случае проблема некий Error тип с произвольным содержимым. Это довольно удобно. Здесь по всей видимости другая логика.
В Rust Option тип может быть любым. Т.е. обычно у тебя возвращает String, а в случае проблема некий Error тип с произвольным содержимым.
Нет, в раст Option<T> — это или конкретное значение T или ничего. Значение или ошибка — это Result<T, E>.
Nullable типы введены в язык, чтобы на уровне компилятора обнаруживать потенциальные NPE и выводить ошибку компиляции там, где в джаве это было бы NPE в рантайме. То есть использование nullable типов это тоже самое, что использование Optional, только на уровне синстаксиса языка.
*нужно не забывать обновлять страницу перед отправкой коммента*
Если есть много, хорошо работающих проектов, врядли кто будет баловаться с ними ради моды и в угоду рекламы.
Противоположные по смыслу + и -, << и >>,… и да, это источник багов во всех современных ЯП.
var — variable
val — value
Интуитивно как-то понятно, что я для чего.
пы Интуицию стоит проверить, но делать этого я, конечно, не буду=)
Соответственно, использование языка будет давать им серьёзные проблемы там, где надо озвучивать код — при обучении, в рабочих дискуссиях… А так как тех же китайцев в США несть числа — ожидаю активное неприятие языка.
Вот это плюсану. l/r бесят
противоположные по смыслу модификаторы должны определяться визуально сходными ключевыми словами
Вам поможет Skala, там точно не перепутаешь :)
val -> unveränderliche var -> opportunistisch def -> verfahrensweise
Холивар явовцев зашкаливает :)
Эх, сколько уже таких "более лучших" Java/C# было...
Не оказались. JVM жила, живет и будет жить, и вместе с ней будет жить Java как "нативный" язык программирования JVM.
Даже если в будущем изобретут язык, который во всех отношениях обгоняет текущие парадигмы программирования, в настоящее время есть только один качественный и эффективный рантайм со сборкой мусора — JVM.
Go, CLR тоже качественные и эффективные рантаймы сборкой мусора
CLR либо только под винду, либо имеет серьезные проблемы с быстродействием
Go, насколько я знаю, использует заточенный под себя рантайм, т.е. другой язык на нем не сделаешь.
А какие у .Net Core проблемы с быстродействием?
Там значения близкие во всех тестах кроме первых трех. Причем в первом тестируются возможности системных регулярок, которые разные по функциональности; во втором в коде на шарпе распаралелили не тот уровень вычислений (обратите внимание: в коде на Java создается отдельная задача для каждой комбинации offset/fragmentLength, а в коде на C# — только для каждого fragmentLength).
Я бы не назвал это серьезными проблемами с быстродействием.
Java по сравнению с COBOL и Algol имеет много значимых улучшений, какие столь же значимые улучшения имеют все эти Kotlin, Groovy, Ceylon по сравнению с Java?
intArrayOf(), longArrayOf(), arrayOf()
Как то непривычно, интересно, почему именно так сделали?
Основная мотивация в том, что если и вводить специальный синтаксис, то сразу для всех коллекций (array, list, map, set), а не только для массивов.
Однажды добавив синтаксис его уже будет невозможно изменить не ломая обратную совместимость, поэтому не спешат.
Насколько я понимаю, от специального синтаксиса не отказались, но пока не приняли окончательное решение.
It’s a POJO complete with toString(), equals(),…А в переводе что-то пошло не так:
Он наполнен POJO-объектами toString(), equals(),…
Про делегаты вообще не слова, как и про вариативность. Про coroutines так же ничего не сказано…
Да и просто описание синтаксиса Kotlin сейчас уже не очень актуально, до этого и так было много статей по этому поводу.
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.
BTW, добавьте в статью @JvmOverloads, ну и что операторы можно передавать в функции.
это перевод…
В дополнение, мне кажется, что скоро с данного ресурса можно будет собрать стопку статей на перевод Kotlin Reference.
Документация по Kotlin на русском
С Kotlin легко перейти на Swift и наоборот, что в теории может упростить для некоторых разработку под разные мобильные платформы.
Как-то вы странно сравнили IDE для языка с обедом в самолете. В "самолетной" аналогии IDE — скорее корпус.
Скорее как терминал аэропорта — удобная и полезная фича, но не обязательная.
В данном случае речь идет не об обязательности фичи, а об уровне компетентности разработчиков. Так вот, разработчики IDE должны разбираться в языке едва ли не больше чем разработчики компилятора. Просто потому что трансляторам позволительно останавливаться после первой же ошибки, а IDE должна работать с кодом на любой стадии готовности.
Если IDE протупит с автодополнением — разработчик всегда может написать это руками, а вот если компилятор что-то не то накомпилирует, то тут уже туши свет.
Справедливости ради, это касается только фронтэнда компиляции — парсинга. Глубины оптимизации, JIT… — это уже не его части.
Kotlin вполне соответствует этому — бэкэнды разные, но эта ниша занята собственно исполняющей VM в JRE, в Javascript машине… И поэтому я сомневаюсь в собственной native реализации — наверняка спихнут на LLVM :)
Так а зачем гадать? можно же просто взять и посмотреть в офф репозиторий. Там первым предложением в readme написано:
Kotlin/Native is a LLVM backend for the Kotlin compiler, runtime implementation and native code generation facility using LLVM toolchain.
Так что да — нативный код будет генерироваться через LLVM, что в скорее плюс, чем минус.
Я из 2020 года, Kotlin зашёл и ещё как зашёл. Теперь он официальный язык для Android. И теперь все пишут на Kotlin.
Это как если бы поставщик обедов для самолётов объявил о запуске своей линии самолётов на том основании, что давно связан с отраслью и хорошо её понимает
Все же не очень корректное сравнение. Ближе будет что-то вроде этого: Создатели промышленных роботов для производства хорошо знакомы со многими отраслями, и решили открыть свою фабрику со своими роботами…
У 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.
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)
}
Ну очевидно же, чтобы синтаксис объявлений параметров совпадал с синтаксисом объявлений переменных.
А в объявлении переменных тип поставили вторым потому что это — необязательная часть. Необязательная часть объявления не может идти первой.
Необязательная часть объявления не может идти первой.
Почему?
Kotlin весьма похож на упрощенную Scala:
def build(title: String, width: Int = 800, height: Int = 600) = {
Frame(title, width, height)
}Наверное, оттуда и взяли.
Так удобнее парсить, так что почти во всех новых языках такой порядок объявления.
Тут хорошо написано автором Скалы:
Скажите, а с переходом на Kotlin придётся постоянно платить JetBrains'ам, или планируются альтернативные IDE?
Почему следует полностью переходить на Kotlin
потому что вам скучно и у вас полно свободного времени
остальные пролистали статью, задались вопросами о рисках для бизнеса не найти разработчика или рисках для разработчика не найти работу, закрыли и забыли
Пошла какая-то мода колхозить сверху языка какие-то скрипто-языки, которые транслируются в Java.
Временное явление.
Предпочитаю чистую Java.
Native существует публично уже третий месяц, недавно мы выпустили v0.2. https://blog.jetbrains.com/kotlin/2017/05/kotlinnative-v0-2-is-out/
(Никоим образом, конечно, это замечание не отностится к переводчику. Ему за труд спасибо.)
https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html
Так что он идеально подходить не только в андроиде, где он прост бесподобен, но и в веб-отрасли.
Это не новый язык программирования — это новая ява.
Похоже на какую-то помесь C# и Python
Пример из статьи:
val john1 = Person("John")
val john2 = Person("John")
john1 == john2 // true (structural equality)
john1 === john2 // false (referential equality)
И inline не получится: https://stackoverflow.com/a/42742119. Что логично, учитывая реификацию.
Мне импонирует ваша вера в то, что все так, как предполагается наиболее логичным, но, к сожалению, авторы Kotlin столкнулись с объективными трудностями, некоторые из которых разрешили ценой потери совместимости с java, в чем я их поддерживаю.
Еще когда-то они считали, что nullable типы покрывают все аспекты взаимодействия с java кодом в плане nullability, но пришлось вводить «сырые» типы. Это не хорошо и не плохо, это объективная реальность с которой приходится считаться.
Все на этом пути пожертвовали чем-то. И ceylon, и kolin, и scala. Стоит помнить чем именно они пожертвовали и ради чего.
Не в белиберду jvm-кода, а нормально, как папа учил.
И кому нужна такая Java без библиотек, простите? В этой нише и так тесно: есть Rust, есть C++, есть Swift в конце-концов. Причем они все без GC.
Наступление Котлин даже слишком быстрое и напористое по пиару. Это и пугает жабоводов. Ну как же — подошли к их тёпленькой кормушке!
Что-то лучше ООП пока что не придумали.
Лично для меня Kotlin — пока что "один из", я уже писал. Каких-то принципиальных отличий от Java, чтобы бросаться его срочно учить, не видно.
Придумали. Помните трех китов ООП? Котрые инкапсуляция, наследование и полиморфизм? Так вот, они устарели. Уже давно эксперты голосуют за агрегацию как основной инструмент повторного использования кода в ООП. Потом начали отказываться от концепции JavaBean — иммутабельные классы и чистые функции оказались выгодней.
Современный тренд — это композиция. Т.е. создание операторов, позволяющих естественным образом объединить два и более объектов или функций в один объект. Простейший пример — Stream API в джава, собирающий коллекцию и набор функций в новую коллекцию.
А Java, как язык, к сожалению, не очень хорошо подходит для композиции. Но я уверен, что в Java10 что-нибудь придумают.
Насколько я вижу функциональное программирование дополняет ООП в некоторых местах (например удобно для обработки списков), если же мы хотим что-то моделировать, то тут ООП замены нет, поскольку оно ближе всего к реальному миру. Например наследование позволяет избавиться от копипейста и обеспечить абстракцию и SOLID — что его заменяет в функциональном программировании?
Насчет объектов и реального мира, вот цитата из классика:
О проектировании иерархии классов говорили все, кому не лень — одни по делу, другие болтали «об имитации объектов реального мира».
Jeff Alger, «C++ for real programmers»
Проблемы копипаста в большинстве своем лучше решаются агрегацией.
В чистом ФП нет наследования и поэтому понятие полиморфизма к нему неприменимо. Вместо него использутся лямбды и абстрактные типы. Например, если в классическом ООП у нас есть interface Colored { Color getColor(); }, то в ФП это будет выглядеть так:
void drawColored <T>(T object, Function<T, Color> getColor) //getColor получает экземпляр T и возвращает его цвет
С наследованием всё ясно — всё более и более обрезается и обрезается по факту с каждым свежим языком.
Полиморфизм никогда и не работал, как было заявлено в начале.
Объекты к объектам реального мира отношения не имеют никакого, а являются лишь структурой данных с присобаченным интерфейсом. Синтаксический обман.
И главное. Все объекты собраны в иерархии. Топологически -дерево. Это самая простая топология, которую можно вообразить для графа. Количество связей минимально — на 1 больше, чем элементов.
Элементы объектов реального мира связаны практически всегда намного большим количеством связей. Наличие обратных связей — колец основа кибернетики, о которой кодеры забыли от слова «совсем».
А почему так произошло? О потому, что царство ООП заменило алгоритмы, модели объектов реального мира на иерархии деревьев классов, нанизанных искуственным наследованием.
Да, Котлин «один из». Но уже помазанник Гугла.
Ну так и какая же альтернатива? Обвешиваться "открытым кодом"-копипейстом? Код большинства библиотек и так открыт — всё равно никто не захочет использовать библиотеки, в которых придётся смотреть код. Черные ящики в мире на каждом шагу — никто не пользовался бы мобильным телефоном, если бы нужно было знать детали реализации команд процессора.
помазанник Гугла
А сколько даже своих собственных проектов Гугл уже закопал…
От совместим точно так же, как совместимы C# и Visual Basic — на уровне сборок / библиотек классов.
val string = """This is
multiline
string"""
На самом деле все-таки не совсем без плясок.
Если важны отступы в строчках и одновременно хочется видеть красиво отформатированный код, то, насколько мне известно, сейчас нет способа это сделать в compile time. Вместо этого есть несколько костылей типого такого.
Также, одновременное отключения экранирования в многострочных строках (на самом деле они не многострочные, а просто сырые) и поддержка интерполяции в них приводят к конструкции ${'$'}, когда нужно чтобы строка содержала $.
Что же касается красивого форматирования при необходимости соблюдения отступов, то я слабо себе представляю, как такое можно по человечески реализовать. Если же вы вдруг знаете, где это реализовано, то поделитесь ссылочкой — с удовольствием поизучаю.
В нормальных IDE достаточно нажать перевод строки внутри строкового литерала, плюсики будут расставлены автоматом.
Бесспорно, это в разы удобнее, чем в Java.
Подобное поведение реализовано в Rust. Конечно, там тоже не все так гладко, так как \ в конце строки так же убирает и сам перевод строки, и если он нужен, приходится вручную добавлять \n. Но лично для меня такая реализация выглядит несколько более приятной.
Язык, может, и хорош.
Но останавливает JetBrains.
Нет ни одного релиза IDEA, где не было бы что-то сломано. Некоторые баги не фиксят годами.
При этом я не вижу, чтобы они сами писали на Котлине. Отдельные проекты есть, тесты в IDEA, но это капля в море.
Они говорили, что будут IDEA писать на Kotlin. Наверное, не такой хороший язык, если они сами его с опаской используют. Выше писали, что лишь отдельные тесты на Котлине.
IDEA уже как бы давно написана
Вот в 2013 году, например, я высказывал те же опасения
https://habrahabr.ru/company/JetBrains/blog/168265/#comment_5825955
За 4 года ничего не изменилось — язык сырой и сама IDEA его не использует.
Сам язык постепенно проникает в их проекты. Нет смысла все сразу переписывать на Kotlin, они для того и делали язык с осознанием того, чтобы он прекрасно дружил с большой кодовой базой на Java.
Перейдем, как только все новые фичи в IDEA будут писать полностью на Kotlin :)
А по поводу этой статьи, она мягко говоря не очень удачная, вместе с картинкой сверху. Больше смахивает на троллинг перехода на Kotlin.
В Kotlin есть одно неоспоримое преимущество, с ним будет больше ежедневного «фана» (original: fun) чем в других языках =)
Говорят, что пишут GUI Rider-а на Kotlin.
Самое больное — функции с большим количеством аргументов, для которых нет синтаксического эквивалента. Без именованных аргументов и значений по умолчанию пользоваться ими и поддерживать читабельность кода практически нереально. Место настолько больное, что в последних версиях Идеи есть подсветка названий параметров прямо в IDE.
Потом дата-классы. Поскольку возвращать множественные значения нельзя — приходится делать классы пачками. К каждому напиши геттеры/сеттеры/туСтринг/экваваленцию и т.д. Просто беда.
Третья боль — это нулл-значения. Весь код утыкан просто бесконечными проверками, а если цепочка идёт a.b.c.d, то хоть на стенку лезь. И начинаются опять аннотации NotNull и т.д.
Единственное, что не понравилось, Delphi-style объявления переменных — зачем оно так делать, непонятно. А в остальном прямо хочется попробовать Kotlin.
Delphi-style объявления переменных — зачем оно так делать, непонятно
Это как раз понятно: так не будет неоднозначности, учитывая то, что указание типов не обязательно.
Интересно есть ли какие-то аргументы против помимо "непривычности"...
Проблема во всём этом — множество ненужного мусора, который хоть и быстро собирается GC, но всё равно не бесплатный.
По теме. Очень хочется лёгких классов в Java, наподобие структур в Си. Множество мелких классов с 40 байтам заголовка — Одна из самых прожорливых статей расходов по памяти.
На одно это смотришь «var i: Int = 0» это полный…
Раньше я думал, что питон это отстой, но теперь вижу, что есть еще хуже
А что не так с var i: Int = 0?
Замечу сразу, что каждый язык хорош под свою задачу.
Ну давайте посмотрим на ходовые языки:
c/cpp
«int i = 0;»
C#, Java:
«Int i = 0;»
Python:
«i = 0»
Питон вообще обошел для любителей сладенького по простоте
Delphi/Pascal:
«var i: Integer;»
И так во многих языках, название переменной и ее тип. И главное максимально коротко. Это более привычно!
А с учетом, что они хотят быть совместимы с Java, то этот кульбит вообще не ясен.
Но котлин с учетом, что это типа «новый» язык сделал еще сложне и решил выделиться
Сначала слово var затем переменная, ну этого мало и добавили : (двоеточие) и уже затем тип, но если нужно null, ставим еще и ? — сразу видно намного легче и привычнее!
Kotlin
var i: Int = 0
А когда где-то в коде видишь такое
var index = 0
val resultJson = JSONObject()
то становится грустно читая и разгребая чужие исходы. Человек при таком подходе пишет не задумываясь о читабельности когда.
Намного было бы лучше, если бы они свою IDE по скорости увеличили.
Сначала слово var затем переменная
{
index = 0
}здесь мы создаем новую переменную или используем существующую?
var index = 0
val resultJson = JSONObject()
А что тут непонятного?
Почему у вас var i: Integer; попадает в категорию "И главное максимально коротко", а var i: Int = 0 вы описываете как "Сначала слово var затем переменная, ну этого мало и добавили: (двоеточие) и уже затем тип"? Лично я вижу только одно отличие — в Паскале инициализацию нельзя совместить с объявлением, и я бы не назвал это достоинством Паскаля.
А что не так с читаемостью кода var index = 0? Неужели тут не видно типа переменной? Или тип переменной виден — но слово var вместо int мозолит глаза?
но слово var вместо int мозолит глаза? Ага, если учесть, что люди пытаются из Java перенести и подружить )
Если бы это был кардинально новый язык, то я бы еще понял. Но когда они ставят его рядом с Java, ну вы хоть посмотрите. Зачем менять, что-то привычное с переменными. Добавьте где-то другое. Но так изуродовать.
но слово var вместо int мозолит глаза?нет, особенно если
надо хоть как-то иметь опыт в других языках
И еще, в Java есть var medium.com/@afinlay/java-10-sneak-peek-local-variable-type-inference-var-3022016e1a2b
в Паскале инициализацию нельзя совместить с объявлением, и я бы не назвал это достоинством Паскаля.
Можно, только там синтаксис несколько сбивает с толку. Переменная, у которой значение задаётся при объявлении, в Delphi объявляется так:
const i: Integer = 100500;
Если вам нужна не инициализированная переменная, а именно константа, которая компилируется статически, и значение которой менять нельзя, то надо убрать тип: const i = 100500;
И так во многих языках, название переменной и ее тип. И главное максимально коротко. Это более привычно!
var fis = FileInputStream() — 3 «лишних» символаFileInputStream fis = new FileInputStream(); — 19 «лишних» символовПро «более привычно» вообще очень странно слышать от человека, позиционирующего себя как разработчика.
Я понимаю, у вас основное направление Web, PHP, CSS, XML и прочее.
Не путайте только )
А такие как C/CPP/C#/JAVA это чуждо.
Но мне то есть с чем сравнивать.
и давно new стало лишним? Погуглите, что такое new и в каких случаех используется.
FileInputStream fis = new FileInputStream(); — 19 «лишних» символов
ну можно и так написать
var fis = new FileInputStream(); — бещ «лишних» символов )
прежде чем коммент писать, другие языки по изучайте. )
Удивляюсь как еще комменты в коде пишите ) Не обленились буковки вбивать
Я понимаю, у вас основное направление Web, PHP, CSS, XML и прочее.Нет, вы неправильно понимаете.
Про «более привычно» вообще очень странно слышать от человека, позиционирующего себя как разработчика. при чем тут это?При том, что специфика профессии подразумевает постоянное обучение новому и, в том числе, непривычному.
и давно new стало лишним?Я бы поставил вопрос так — когда и зачем оно стало необходимым? Погуглите, для саморазвития.
Тот стиль объявлений переменных и функций, который в C (а изначально в Fortran, Algol) и который перетёк в Java и прочие, при минимальном усложнении превращается в эффекты вроде Most Vexing Parse. Которые вслед бьют и по авторам компилятора, и по программистам, которые не могут понять, что у них происходит в коде и почему то компилятор жалуется, то (ещё хуже) молча генерирует не то, что ожидалось.
Введение дополнительного слова и перестановка порядка имя — тип нормализуют парсинг, делают его понятным для пользователей и простым для авторов компиляторов. Последнее, вам кажется, не ваши проблемы, но когда компилятор C++ превращается в сопрограммы между парсером (который повторяет отработку кусков под новые условия) и семантическим анализатором, количество ошибок в этом наверняка ненулевое.
Двоеточие — да, возможно, не нужно; Go достаточно одного пробела:
var i int
но я считаю, что лёгкая многословность в языке скорее полезна — в частности, за счёт того, что можно ввести новые синтаксические элементы.
Извините, еще раз, за язвительность, но:
1) означает ли «100%-я совместимость» с java, что байткод, собранный компилятором котлина на 6й джава машине будет работать на 7й без пересборки? (замените цифры 6 и 7 на актуальные или вами любимые по возрастанию). A если будет, то будет ли он работать точно так же?
2) кто гарантирует что новые версии котлина будут 100% обратно совместимы со своими предшественниками? будет поддерживаться несколько веток котлина как это (все еще?) происходит с питоном или авторы котлина просто откажутся от поддержки старых версий, написав письмо вида «извините, мы знаем, что все еще не можете перейти на новую версию из-за проблем с обратной совместимостью в языке, и большого объема ваших проектов, но (нам пофиг) мы снимаем старую версию с поддержки», как это было с руби?
Скептик внутри меня говорит, что есть серьезное подозрение, что с точки зрения идеологов котлина, ни первое ни второе решать корректно «совершенно не обязательно», потому что «это всё это уже 100 раз видели» на примере других «байткод-совместимых языков», разных «убийц джавы» и многих других хороших и не очень языков.
А если не ответить правильно на эти 2 вопроса, это означает что это никакого большого промышленного будущего у этого языка нет, и говорить о котлине как о заменителе джавы нельзя. равно как и писать большие, долгоживущие проекты тоже «опасно» (банально есть риски отхватить тружноотлаживаемые проблемы при смене версий). Сначала — удобный синтаксис, приятные фичи… а потом…
Ну так как дела у котлина «с этим»?
кто гарантирует что новые версии котлина будут 100% обратно совместимы со своими предшественниками?Вообще, авторы в каждом докладе, где рассматриваются эти вопросы, клянутся, что обратная совместимость для них наиважнейший фактор при развитии языка. Со слов Андрея Бреслава, «пока люди используют Java 6, Kotlin будет с ней совместим» (почти дословно)
означает ли «100%-я совместимость» с java, что байткод, собранный компилятором котлина на 6й джава машине будет работать на 7й без пересборки? (замените цифры 6 и 7 на актуальные или вами любимые по возрастанию). A если будет, то будет ли он работать точно так же?У меня работает
Вообще, авторы в каждом докладе, где рассматриваются эти вопросы, клянутся, что обратная совместимость для них наиважнейший фактор при развитии языка. Со слов Андрея Бреслава, «пока люди используют Java 6, Kotlin будет с ней совместим» (почти дословно)
Я не про совместимость с Java 6. Я про совместимость версий языка — старых версий с новыми.
Вот скажем, как авторы котлина собираются обеспечить гарантии того, что когда выйдет версия 1.3, вам не потребуется перекраивать код уже написанный на котлине 1.2?
Ну и… «клятвы» — это хорошо. Но «где ваши доказательства»?
Есть ли для котлина полная спецификация языка с детальным описанием поведения каждой конструкции, как это есть для Java и Java-машины?
Вот в джаве описанные вещи обеспечиваются именно детальной спекой, с последовательным включением в эту спеку всех оговорок и исключений, связанных с поведением старых версий джавы на новой машине и в окружении новых фич языка.
А что с котлином?
У меня работает
Ну, вы же понимаете, что это не доказательно? Хелло-ворды, вот скажем, всегда везде работают. Но мы же не про них говорим.
Я не про совместимость с Java 6. Я про совместимость версий языка — старых версий с новыми.Надо было мне про джаву отдельным абзацем :) Нет, я как раз про обратную совместимость языка писал. Про джаву — это отдельно, как пример того, что даже к вопросам совместимости с ней они подходят серьезно, что уж говорить про свой язык.
Вот скажем, как авторы котлина собираются обеспечить гарантии того, что когда выйдет версия 1.3, вам не потребуется перекраивать код уже написанный на котлине 1.2?
Официальная документация компании разработчика языка подойдет?
patch version updates (e.g. 1.1.X) are fully compatible;
minor version updates (e.g. 1.X) are backwards compatible.Специфика продуктов JetBrains такова, что они лучше многих понимают проблемы, с которыми сталкиваются ЯП и разработчики их использующие. Первый релиз Kotlin появился через 5 лет после начала его разработки — это большой срок по меркам разработки нового ЯП, и, с их слов, так получилось именно из-за детальной проработки языка — чтобы потом не пришлось идти по пути Swift, например. Так что есть все основания надеяться и верить.
означает ли «100%-я совместимость» с java, что байткод, собранный компилятором котлина на 6й джава машине будет работать на 7й без пересборки?Я вот правда не знаю что вам ответить. Это вопрос из разряда «Ты перестал бить жену по утрам?». Так как котлин компилируется в байткод исполняемый JVM, как и Java, то и бинарная совместимость будет как у Java. Ну как-то так.
Официальная документация компании разработчика языка подойдетНе уверен.
Тут ситуация в чем — просто документации мало.
т.е. хорошо что оно есть, но это только начало.
Эта документация и стандарт языка воплощены в виде автоматических тестов?
Есть процесс сертификации сторонних реализаций котлина на предмет совместимости? Если вы обеспечите процесс сертификации под каждую версию, то и вопросы обратной совместимости будут выявляться на раз-два. Если нет — то что — остается «верить на слово»?
Если вспомнить историю, то (фактически) отсутствие процесса сертификации привело к тому, что, например, разные версии руби под разные платформы и среды не полностью совместимы друг с другом. А про разнообразие сишных не совместимых друг с другом компиляторов — помолчу — это «притча во языцах».
Если противопоставить джаву этому хаосу, то у джавы, например, есть процесс сертификации компилятора/джавамашины.
Вы же, по крайней мере пока, предлагаете «наслово поверить документации» и обещаниям. Но, повторюсь, чем они подтверждены? Заверениями что внутренние процессы компании производителя это обеспечивают? ага… 3 раза вам поверили.
Если вы предлагаете переходить на другой язык, причем _полностью_, надо нечто большее — например механизм обеспечения гарантии того, что кто-то другой может производить 100%-совместимые компиляторы. Почему это важно? Сегодня JetBrains есть, а завтра обанкротились. А нам что делать с туевой массой кода на хйповом котлине? Где вот скажем Borland со своим Delphi? «а нигде», образно говоря. В былые времена все и всё на дельфятине писали.… огогооо!… С джавой же ситуация кардинально другая — джаву, извините, не только Oracle поддерживает. Тут и сообщество, и IBM… т.е джаве есть хоть какая-то уверенность в завтрашнем дне. А в котлине?
И вот к JetBrains — вопрос — как они собираются обеспечивать долгую жизнь котлину? обещаниями и документацией? нуну…
SUN, имхо, в свое время понимали эту проблему, и сделали спеки полными и отрытыми. В том числе был создан, в конце концов и процесс сертификации сторонних джава-машин. И это, в том числе, обеспечило распространение джавы, «буквально везде», а в купе с обратной совместимостью — позволило стать промышленным стандартом. После них, по моим сведениям, никто другой такой подвиг не повторил.
И так… процесс сертификации компиляторов котлин от других производителей.
Он есть? Потому что это один из немногих, действенных способов обеспечить гарантии совместимости. Если у вас есть другие мысли о том как это гарантировать кроме как «поверить на слово производителю» — предлагайте.
Я вот правда не знаю что вам ответить. Это вопрос из разряда «Ты перестал бить жену по утрам?». Так как котлин компилируется в байткод исполняемый JVM, как и Java, то и бинарная совместимость будет как у Java. Ну как-то так.Аналогия интересная, но не совсем.
Тут скорее вопрос о том, как производитель обеспечит совместимость с новымми версиями джавы, и я, признаться, надеялся, что вы скажете, что либо типа «они используют те возможности джава6 которые остались неизменными на протяжении 6-7-8-9 версий… ». Ну в варианте, когда вы используете Java6 и последнюю версию компилятора котлин конечно…
Но ничего подобного не прозвучало. Вы предлагаете, повторюсь, довериться разработчикам?
Если посмотреть в спеки различий между java6 и java7 то в принципе становится понятно, почему, некоторые проекты имеют проблемы с поддержкой новых версий джавы. Вот скажем
Почему так? не знаю… то ли они рефлекшен пользуют для доступа к приватным фунциям (вам разве сразу не говорили что так делать не надо?) или их логика работы завязана на порядок выдачи функций класса в рефлекшен-функциях? (а у вас в доках разве гарантирован порядок выдачи элементов?)…
Но на своей шкуре проверил — оно работает только под java 6.
И вот глядя на ЭТО, у меня и возникает вопрос — как именно производитель котлина собирается обеспечивать совместимость с Java 6|7|8|9|10? Какие методы обеспечения совместимости или хотя бы методы выявления несовместимостей… а вы мне про бинарную совместимость байткода. Ну не про это же речь.
Вот с джава все понятно — есть сертификация сторонних компиляторов и систем/сред/программ… а что с котлином и JetBrains?
Если вы предлагаете переходить на другой язык, причем _полностью_, надо нечто большее — например механизм обеспечения гарантии того, что кто-то другой может производить 100%-совместимые компиляторы. Почему это важно? Сегодня JetBrains есть, а завтра обанкротились.Компилятор лежит на гитхабе под лицензией Apache 2. Да и гугл с андроидом никто пока не отменял, если что.
И вот к JetBrains — вопрос — как они собираются обеспечивать долгую жизнь котлину?Тенденции обнадеживающие.
Тут скорее вопрос о том, как производитель обеспечит совместимость с новымми версиями джавы, и я, признаться, надеялся...Немного не ко мне вопрос, а, скорее, к разработчикам.
Единственно, что меня смущает, так это ваши претензии к Kotlin аргументируемые существованием кривых поделий на Java. Я, если честно, связь немного не улавливаю.
Обычно в мире ISO, IETF и прочих, чьи стандарты хотя бы уважают, считается, что возможность (такую, как язык, среда исполнения, библиотека и т.п.) можно считать реализованной и вводить в стандарт, когда есть хотя бы два независимых разработчика, реализовавших оное на различной кодовой базе. Лучше — больше.
Наличие только одного источника откровенно недостаточно: это vendor lock, возможность его ухода с рынка и т.д., и самое серьёзное — отсутствие консенсуса заинтересованных организаций.
Да, схема не идеальна. Например, Microsoft только в 2015 году начал показывать поддержку C99, и то, кажется, неполную. Но она хотя бы работает в среднем по больнице.
В случае Kotlin мы имеем продукт ровно одного производителя. Где гарантии, что, например, Гугл подхватит его, если с JetBrains что-то случится?
«Компилятор лежит на гитхабе» — аж никак не гарантия, что после JetBrains его тупо не забудут в течение пары лет.
> Тенденции обнадеживающие.
Да бросьте. Достаточно того, что, независимо от моей или вашей политической позиции, основные силы разработчика в стране под санкциями той части мира, в которой основные потребители языка.
Вот пример: проект IKVM вроде как заброшен. Но буквально три недели назад я использовал его для того чтобы подключить Apache FOP (тоже не очень активно развивающийся проект) к проекту на C# — потому что аналогов в мире .NET не оказалось. И никаких проблем они не принесли, в отличии от активно развивающегося Firefox без вендорлока!
Вот выйдет Java 11, затем 12, там начнут по мелочи что-то отламывать… и уже потребуются героические усилия, чтобы на коленке это починить.
Если же что-то серьезно пойдет не так (например, все PDF-ридеры перестанут понимать старый формат) — что ж, придется искать другое решение. Но это все равно выгоднее чем искать другое решение прямо сейчас.
PS IKVM.NET — это реализация JVM на .NET. Преобразователь байт-кода из одного формата в другой плюс стандартная библиотека Java.
Из прочитанного заинтересовали только аргументы по умолчанию, ну может диапазоны немного
Почему следует полностью переходить на Kotlin