LINUX.ORG.RU

Представлены исходные тексты компилятора и библиотек Kotlin

 ,


0

1

Компания JetBrains, во многом известная благодаря своему продукту IDE IntelliJ IDEA, сегодня открыла исходный код собственного языка программирования, компилирующегося в байт-код для виртуальной машины Java и в JavaScript.

Kotlin — статически типизированный язык программирования, основные свойства:

  • Максимальная совместимость с Java и JVM, с расчетом на совместное использование вместе с Java кодом
  • Быстрая компиляция (не медленее Javac)
  • Больший уровень безопасности, в том числе избегание NullPointerException за счет более совершенной системы типов, проверки generic-типов во время исполения и др.
  • Более краткий и выразительный код благодаря выводу типов локальных переменных, наличию функций высшего порядка, возможности добавления функций в существующие классы и т.п.
  • Проще Scala при том же уровне выразительности кода

JetBrains сделала доступными следующие инструменты для разработки (в дополнение к уже известной веб-консоли Kotlin Web Demo, в которой кстати появилось несколько примеров кода и небольших заданий для ознакомления):

  • Компилятор Kompiler;
  • Расширения для базовых библиотек Java из состава JDK;
  • Интеграция с инструментами для сборки приложений Ant, Gradle и Maven;
  • Плагин для IntelliJ IDEA (требуется обновление до последней версии IDE)

Исходные тексты доступны на GitHub под лицензией Apache 2.

Стоит заметить, что это первый вариант Kotlin, который разработчики представляют сообществу, причем стадия готовности продукта - pre-alpha, поэтому всячески приветствуются любые мнения и отчеты об ошибках от пользователей.

В дополнение к вышесказанному, команда разработчиков будет рада любой помощи, в том числе в виде патчей-исправлений.

(спасибо ins3y3d за помощь в составлении новости)

>>> Подробности

★★★★★

Последнее исправление: maxcom (всего исправлений: 7)

Ответ на: комментарий от ymn

вот мне интересно, когда кложа только создавалась, сколько неадекватных фанатиков на форумах кричало что есть жаба, а кривая поделка рукожопого идиотика хикки не нужна?

Ты отчасти прав. На уровне идеи всё новое воспринимается в штыки.

Но можешь сравнить две страницы: раздел Why a new language? котлина http://confluence.jetbrains.net/display/Kotlin/FAQ и Rationale кложуры http://clojure.org/rationale .
Джетбрейновцы выдавили из себя пять причин для чего они создавали свой язык. Давай их пересмотрим:
- to create a Java-compatible language - это не причина, это цель
- that compiles at least as fast as Java - то же самое
- make it safer than Java, i.e. statically check for common pitfalls such as null pointer dereference - хз, хз. Если моя программа захочет дереференснуть нулл, я предпочту, чтобы она поскорее сделала это и сдохла. А статически все NPE даже Хахаскель не отловит.
- make it more concise than Java by supporting variable type inference, higher-order functions (closures), extension functions, mixins and first-class delegation, etc; - наконец-то первая причина
- and, keeping the useful level of expressiveness (see above), make it way simpler than the most mature competitor – Scala. - снова не причина и дурацкие претензии на конкуренцию со Скалой. Сравнили гуй с терминалом.

Итак, из ничтожных пяти причин осталась одна - сделать чтобы джава была с замыканиями, ФВП и прочими трендовыми фишечками. Собственно, то, что сейчас делают 90% языков для JVM.

Теперь немного понятнее почему это поделии более «ненужно», чем скала или кложура?

unlog1c ★★★
()
Ответ на: комментарий от uhbif19

Все-то на нем можно сделать, на удобных макросах... но вот почему-то никто ничего удобного не делает !

Почему, делает. Просто ты этим не интересуешься, следовательно этого не видишь.

unlog1c ★★★
()
Ответ на: комментарий от uhbif19

Паскаль появился в 1970. Это почти «изначально». То что вы называете «ошибками предыдущих» на самом деле уже давно пройденный этап. Вот вам пример двух мертвых языков в которых все ключевые слова используются без сокращений: алгол и кобол. Алгол конечно дедушка, его изобрели аж 58 году. Но именно паскаль и явился «работой над ошибками» алгола. Лисп, лишенный таких заморочек, тоже изобрели в 58 но используется он и по сей день. Говорят что на коболе тоже до сих пор лабают но тут скорее как с адой, необходимость поддерживать то что уже есть и работает плюс - язык стал стандартом для приложений в своей области. Все это конечно очень субъективно но я лично знаю людей пописывающих на лиспе но нигде не встречал не то что программиста на коболе но даже того кто видел живого программиста на коболе :)

A-234 ★★★★★
()

Кому не хватает джавы - осилит скалу. Кто не осиливает скалу, тот и джаву не знает толком, никакие котлины ему и близко не нужны. Не очень верю в перспективы.

Но мало ли.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Кому не хватает джавы - осилит скалу. Кто не осиливает скалу, тот и джаву не знает толком, никакие котлины ему и близко не нужны. Не очень верю в перспективы.

Не осиливающие скалу вполне успешно пишут код на яве в больших проектах, где 90% его - взять из базы/положить в базу и отрисовать формочку в вебе. И как мне при этом начинать проект на скале, если я знаю - что хрен под нее найду потом программера на эту, довольно тупую, работу типа формоклепательства?

Nagwal ★★★★
()
Ответ на: комментарий от Nagwal

Ну а со всякийми ceylon/kotlin - проблема не стоит столь критично, поскольку ни фактически и есть та-же ява, только с небольшими плюшками. Получается вполне разумный компромисс.

Nagwal ★★★★
()
Ответ на: комментарий от Nagwal

Scala тоже можно использовать, как яву с небольшими плюшками. Это раз.

Я сомневаюсь в наличии большого числа программистов, способных и имеющих желание осиливать ceylon/kotlin, но неспособных осилить Scala на уровне явы с небольшими плюшками.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Знаешь, я тут сейчас смотрю на проект на яве и плачу горючими слезами над тем, как даже на кондовой яве можно испохабить и запутать код. Представь себе что с ним будет, если таким умельцам скалу со всей ее мощью в руки дать?

Сейчас ситуация довольно банальная. Простой кодер пишет код. Хрен с ним что он говенный, лапшеобразный итд. Дело он делает, формочки рисует. Этот код поемщается в отдельный пакет, оборачивается интерфейсами и не торчит своими внутренностями в остальной системе. А теперь внимание, вопрос: насколько более трудоемким станет процесс этого рефакторинга в случае использования скалы?

Nagwal ★★★★
()
Ответ на: комментарий от Nagwal

Ты только что сформулировал, собственно, основное преимущество Java, ту причину, по которой она порвет в клочья все остальные языки. Java тупая, и оставляет очень мало простора для умничанья, а это вообще самое важное в программировании. Из этой ее тупизны следует и другое важное свойство - ее очень легко анализировать, что делает средства разработки под Java самыми мощными и гибкими. Тот же автоматический рефакторинг на уровне Idea для Скалы практически невозможен, а для Java делается тривиально.

По той же причине всякие Лиспы с Нимерлами всегда будут ненужны, а за их использование в промышленном коде надо будет сажать или расстреливать. Да и тот же шарп уже стал недопустимо сложным. LINQ и лямбды испортили язык окончательно.

anonymous
()
Ответ на: комментарий от uhbif19

Ты как-то очень эмоционально это написал. Не зависть ли тому причиной?

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

Угу, я в курсе что это ее основное преимущество. Именно поэтому я вряд-ли приму решение писать что-то с долгим сроком жизни и большим функционалом на чем-то кроме явы.

Но она от этого не становится приятным языком с прямой базовой библиотекой. Неспроста под нее есть over9k мелких библиотек типа apache-commons. И именно поэтому я приветствую языки типа ceylon/kotlin, которые стараются сделать язык не силльно более сложным, но при этом более приятным для вменяемого разработчика.

Nagwal ★★★★
()
Ответ на: комментарий от Nagwal

Хрен с ним что он говенный, лапшеобразный итд. Дело он делает, формочки рисует. Этот код поемщается в отдельный пакет, оборачивается интерфейсами и не торчит своими внутренностями в остальной системе. А теперь внимание, вопрос: насколько более трудоемким станет процесс этого рефакторинга в случае использования скалы?

Заворачивание говна в обертку уже называется рефакторингом?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Куда яву дальше то упрощать? Вот стандартную библиотеку да, надо бы переписать заново, с учетом всех ошибок и с прицелом на максимальную простоту использования.

Nagwal ★★★★
()
Ответ на: комментарий от tailgunner

Заворачивание говна в обертку уже называется рефакторингом?

А что с этим говном еще делать то? Переписывать никакого времени не хватит, да и работает оно.

Nagwal ★★★★
()
Ответ на: комментарий от unlog1c

- make it safer than Java, i.e. statically check for common pitfalls such as null pointer dereference - хз, хз. Если моя программа захочет дереференснуть нулл, я предпочту, чтобы она поскорее сделала это и сдохла.

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

А статически все NPE даже Хахаскель не отловит.

Можешь примеры привести?

Пока что приходит в голову только две вещи: 1) абсолютно мерзостная реализации низкоуровневых указателей, очевидно сбацанная на скорую руку людьми с прогрессирующей nullpointerophilia 2) всевозможные unsafe операции, которыми все равно очень просят не пользоваться.

rtvd ★★★★★
()
Ответ на: комментарий от Nagwal

Заворачивание говна в обертку уже называется рефакторингом?

А что с этим говном еще делать то? Переписывать никакого времени не хватит, да и работает оно.

Переписать на Coq. И на основе доказанных теорем сгенерить код для Java.

Шучу, конечно.

rtvd ★★★★★
()
Ответ на: комментарий от ymn

Переписать на Coq

истинно джедайский путь!

У этого подхода есть один скрытый плюс: можно потом написать научную статью. Может даже диссертацию защитить на тему «использование Coq для создания математически точного геренатора формочек».

rtvd ★★★★★
()
Ответ на: комментарий от Nagwal

Заворачивание говна в обертку уже называется рефакторингом?

А что с этим говном еще делать то?

Вопрос был не о том, что делать, а о том, как называть эти действия. То, что ты описал - это не рефакторинг.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Из этой ее тупизны следует и другое важное свойство - ее очень легко анализировать, что делает средства разработки под Java самыми мощными и гибкими. Тот же автоматический рефакторинг на уровне Idea для Скалы практически невозможен, а для Java делается тривиально.

Простые рефакторинги вроде переименования или вынесения выражения в функцию возможны и для скалы. Сложные рефакторинги можно и руками сделать, т.к. делаются они редко, а умная скала проследит, чтобы опечаток не было.

Legioner ★★★★★
()
Ответ на: комментарий от Nagwal

Знаешь, я тут сейчас смотрю на проект на яве и плачу горючими слезами над тем, как даже на кондовой яве можно испохабить и запутать код. Представь себе что с ним будет, если таким умельцам скалу со всей ее мощью в руки дать?

Они её не осилят и уволятся. В мире не появится испохабленный и запутанный код. Профит же.

Сейчас ситуация довольно банальная. Простой кодер пишет код. Хрен с ним что он говенный, лапшеобразный итд. Дело он делает, формочки рисует. Этот код поемщается в отдельный пакет, оборачивается интерфейсами и не торчит своими внутренностями в остальной системе. А теперь внимание, вопрос: насколько более трудоемким станет процесс этого рефакторинга в случае использования скалы?

Не знаю, мне кажется - нисколько не труднее. В плане интерфейсов скала особо от джавы не отличается. Так же обернут, и всё.

Legioner ★★★★★
()
Ответ на: комментарий от tailgunner

Почему не рефакторинг? Происходит вынос кода в отдельное место, оборачивание его вменяемыми интерфейсами. Чем это не рефакторинг в рамках всей системы?

Nagwal ★★★★
()
Ответ на: комментарий от ugoday

Это в лиспе можно на лету добавлять новые фичи с помощью макросов. А в жабе для этого приходится делать новый язык.

Засуньте себе в жопу свой лисп. Он не масштабируется вообще, Hunchentoot дохнет на паре-тройке тысяч коннектов, и это при 128 гигах памяти.

anonymous
()
Ответ на: комментарий от anonymous

Тот же автоматический рефакторинг на уровне Idea для Скалы практически невозможен, а для Java делается тривиально.

А можно пояснить, почему со Scala всё плохо даже в теории? Я вот не могу это порка формально обосновать.

sv75 ★★★★★
()
Ответ на: комментарий от anonymous

Он не масштабируется вообще, Hunchentoot дохнет на паре-тройке тысяч коннектов, и это при 128 гигах памяти.

Вы уверены, что это проблема языка? Если делать fork на каждый коннект, и иметь общую память с мьютексом, то у меня и Си сдохнет так же )

sv75 ★★★★★
()
Ответ на: комментарий от anonymous

(да, я не утверждал что в Hunchentoot fork, лень на него смотреть)

sv75 ★★★★★
()
Ответ на: комментарий от sv75

Я хз чьи это проблемы, т.к. кроме Hunchentoot больше ничего нет. Ну даже 2 тыс. процессов, для системы с такими ресурсами, разве это много?

anonymous
()
Ответ на: комментарий от Nagwal

Ну, например убрать примитивые типы (: Банально, да.

uhbif19
()
Ответ на: комментарий от sv75

аноним имеет ввиду, что в языках с выводом типов сложнее сделать подсказывальщик, потому что тип надо ещё нетривиально вычислять...

Kakadu
()
Ответ на: комментарий от anonymous

Это вовсе не простота. Это называется идеология. Ну и немножко маразма в придачу.

C# это такая джава, где разрешили неидеологичные вещи. Ну и убрали пару маразмов, да.

Google://Haskell

uhbif19
()
Ответ на: комментарий от uhbif19

это в джаве тип переменной выводим из одной строчки, её определения. А если тип выводим только из всего тела функции? а если в теле функции есть ошибки? а если она не дописана ещё?

Kakadu
()
Ответ на: комментарий от A-234

Мне кажется, что на популярности этих языков, сказалась далеко не только длина ключевых слов (:

Примеры таких древних языков и их судьбы, мне кажется не ключевой фактор при выборе стратегии для новых языков.

uhbif19
()
Ответ на: комментарий от Legioner

Они её не осилят и уволятся. В мире не появится испохабленный и запутанный код. Профит же.

А формочки кто клепать будет? ;) Осилившие скалу от них нос воротят, а делать их приходится.

Не знаю, мне кажется - нисколько не труднее. В плане интерфейсов скала особо от джавы не отличается. Так же обернут, и всё.

Чтобы правильно код обернуть - его надо для начала разобрать и понять как он все-таки рботает. И в случае скалы это сделать будет на порядок сложнее, если код говенный.

Nagwal ★★★★
()
Ответ на: комментарий от Kakadu

А если тип выводим только из всего тела функции? а если в теле функции есть ошибки? а если она не дописана ещё?

Это может значить, что IDE написать несколько сложнее. И?

tailgunner ★★★★★
()
Ответ на: комментарий от Kakadu

И что ? Компилятор это делать умеет ? С него и скопируем. Open Source - же.

а если в теле функции есть ошибки? а если она не дописана ещё?

IDE обычно работают, для функций без ошибок. А до этого, ничего хорошего не делают, а просто выводят флажок ошибки.

uhbif19
()
Ответ на: комментарий от anonymous

Многовато. Ну и умело поставленный мьютекс может создать боттленек. Им небось select надо использовать, как ngnix (хотя если там не select/poll, то они вообще идиоты ))

sv75 ★★★★★
()
Ответ на: комментарий от Kakadu

аноним имеет ввиду, что в языках с выводом типов сложнее сделать подсказывальщик, потому что тип надо ещё нетривиально вычислять...

Ясно.

sv75 ★★★★★
()
Ответ на: комментарий от uhbif19

Компилятор это делать умеет ? С него и скопируем. Open Source - же.

Если вы настолько скиллованный, то вперед. Но опыт подсказываюь что для окамля норм IDE так и не сделали. Потому сложнее всё же чем для обычных языков. ИМХО. :-)

Kakadu
()
Ответ на: комментарий от Kakadu

Вы конечно правы. Но мне кажется, что вовсе не это причина, отсуствия IDE. Если надо кому-либо: сделают. А пока видимо это никому не нужно.

PS И, да. OCaml еще менее популярен. И авто-вывод типов, как мне кажется не самая сложная в Scala штука.

uhbif19
()
Ответ на: комментарий от unlog1c

Вы правы.

Не могли бы вы привести примеров, как Lisp решил некую важный недостаток языка используя метапрограммирование ?

uhbif19
()
Ответ на: комментарий от uhbif19

Не могли бы вы привести примеров, как Lisp решил некую важный недостаток языка используя метапрограммирование ?

Если поставим вопрос по другому «Как Lisp добавил некое преимущество в язык», то могу. Видение недостатков у нас с вами может отличаться.

https://github.com/clojure/core.match - библиотека оптимизированного патерн матчинга для Clojure (изначально pattern matching в Кложуре отсутствует). На этапе компиляции разворачивает pattern-matching структуры в оптимизированную вереницу if-ов. По заявкам автора работает быстрее, чем pattern matching в Скале. Без метапрограммирования сделать это не удалось бы.

Или, например, https://github.com/clojure/core.logic - реализациия логического программирования. Несколько не так полезна, но тоже пример того, что с помощью метапрограммирования можно ввести в язык хоть целую парадигму.

Конечно же, в большинстве случаев макросы используются для более ежедневных и простых целей облегчения жизни, но вы просили серьезные примеры, я привел серьезные;).

unlog1c ★★★
()
Ответ на: комментарий от uhbif19

Мне кажется, что на популярности этих языков, сказалась далеко не только длина ключевых слов (:

Да конечно эта причина не единественная, но согласитесь, когда однострочный комментарий должен начинаться со слова comment - это финиш.

Сейчас мы - программисты, повторяем путь пройденный математиками несколько сотен лет назад в поиска своей парадигмы. То что сейчас умеет даже школьник, в 1500 году, например, представлялось сложным логическим трюком. Поиск решений кубического уравнения был предметом конкурсов, потому что условие выглядело обычно так: неизвестная часть, множимая саму на себя трижды, умножается еще на десять, к ней прибавляется все та же неизвестная часть, множимая сама на себя дважды и еще на пять, далее прибавляем эту неизвестную часть, умноженную на четыре, полученный результат равняется минус трем. Чему должно равняться неизвестное число? Теперь сравните с этим эквивалентом: 10*x^3 + 5*x^2 + 4*x = -3. В деталях скорее всего напутал, не помню когда появилось представление об отрицательных числах, но суть ясна.

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

A-234 ★★★★★
()
Ответ на: комментарий от rtvd

Можешь примеры привести?

Я достаю значение из словаря по ключу и делаю ему fromJust. Каким образом компилятор может статически предугадать, что здесь может возникнуть NPE?

Я понимаю, что ССЗБ, и что я должен таскать это значение в Maybe и разбирать случай для null'а при каждом дереференсе. Но чем это тогда отличается от простой проверки на null в Джаве?

А если сделать обязательное указание действия при null'е, то это будет все равно, что сделать в Джаве checked NPE.

unlog1c ★★★
()
Ответ на: комментарий от unlog1c

А если сделать обязательное указание действия при null'е, то это будет все равно, что сделать в Джаве checked NPE.

Надо:

1. Ввести понятие Nullable Reference и Nonnullable reference.

2. Методы, переменные и т.д. могут вызываться только через Nonnullable reference.

3. Тип ссылки может указываться аналогично final, например ключевым словом nullable. По умолчанию ссылка считается nonnullable. Тип ссылки указывается у переменных, полей, параметров методов, возвращаемых значений методов и т.д.

4. Присваивать nonnullable ссылке nullable значение запрещено.

5. Компилятор в ряде случаев может понимать, что данное значение не может быть равно null и изменять для него тип, например:

new MyClass(); // result not null
nullable MyClass c = getMyClassOrNull();
if (c != null) { // c is not null here }
MyClass c2 = (MyClass) c; // throws NullPointerException if c == null

В итоге получится очень надёжно и удобно. Подавляющее большинство ссылок никогда не должны принимать значения null, и ничего не надо писать. Те, которые должны - специально выделены в коде. Случайный NPE можно сделать, только если злоупотреблять кастами, но тут уже ССЗБ. При ошибках NPE вылетает гораздо раньше.

Возникает проблема обратной совместимости. Она достаточно просто решается флажком компилятора, который указывает ему, что файл из старой джавы и считает nullable все параметры и возвращаемые значения. Интерфейситься со старыми классами, к сожалению, будет неудобно, но это не страшно, также неудобно интерфейситсья сейчас с библиотеками для Java 1.4.

Legioner ★★★★★
()
Ответ на: комментарий от unlog1c

библиотека оптимизированного патерн матчинга для Clojure (изначально pattern matching в Кложуре отсутствует) [...] Без метапрограммирования сделать это не удалось бы.

С галерки кричат, что все эти метапрограммные трюки не получают распространения, так что полезность введения в язык аж целых новых парадигм остается сомнительной.

tailgunner ★★★★★
()
Ответ на: комментарий от Legioner

То есть, насколько я понял идею, статическая защита от NPE на этапе компиляции тут будет происходить благодаря 2. Методы, переменные и т.д. могут вызываться только через Nonnullable reference.

Всё замечательно, но ты сам пишешь:

MyClass c2 = (MyClass) c; // throws NullPointerException if c == null
И выбросит он NPE очень даже в рантайме. Так какой же тогда смысл, если по другому от nullable до nonnullable не перейти?

Нет, я понимаю, к чему ты ведешь. Сделать всё это для того, чтобы программист мог чётко увидеть где он уже рассмотрел возможность обьекта быть равным null, а где нет. Но, как я и говорил, это почти всё равно, что сделать checked NPE. Ну немного приятнее, естественно (checked exceptions вообще дикий ад), но по моему не причина делать целый новый язык.

unlog1c ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.