Предлагаю вашему вниманию перевод оригинальной статьи Роберта С. Мартина.

За последние несколько месяцев я попробовал два новых языка. Swift и Kotlin. У этих двух языков есть ряд общих особенностей. Действительно, сходство настолько сильное, что мне стало интересно, не является ли это новой тенденцией в нашей языкомешалке. Если это действительно так, то это тёмный путь.

Оба языка включают в себя некоторые функциональные характеристики. Например, в них обоих есть лямбды. В целом, это хорошая штука. Чем больше мы узнаем о функциональном программировании, тем лучше. Эти языки далеки от по-настоящему функционального языка программирования; но каждый шаг в этом направлении — хороший шаг.

Проблема в том, что оба языка сделали ставку на сильную статическую типизацию. Кажется, оба намерены заткнуть каждую дыру в своём родном языке. В случае со Swift – это странный гибрид C и Smalltalk, который называется Objective-C; поэтому, возможно, упор на типизацию понятен. Что касается Kotlin – его предком является уже довольно строго типизированная Java.

Я не хочу, чтобы вы думали, что я против статически типизированных языков. Я не против. Есть определенные преимущества как для динамических, так и для статических языков; и я с удовольствием пользуюсь обоими видами. Я предпочитаю динамическую типизацию, и поэтому я иногда использую Clojure. С другой стороны, я, вероятно, пишу больше Java, чем Clojure. Поэтому вы можете считать меня би-типичным. Я иду по обеим сторонам улицы — если так можно выразиться.

Дело не в том, что меня беспокоит статическая типизация Swift и Kotlin. Скорее меня беспокоит глубина статической типизации.

• Взаимодействие с разработчиками и процесс эволюции языка
• Компиляцию в JS, проект Kotlin Native и мультиплатформенность в общем
• Несовершенства
• Kotlin-паззлеры
• Ожидания и амбиции

Мы рады представить вам Kotlin 1.1, новую версию языка программирования Kotlin.

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

DSL (Domain-specific language) — язык, специализированный для конкретной области применения (Википедия)

На написание этого поста меня натолкнула статья "Почему Kotlin отстой", в которой автор сетует на то, что в Kotlin "нет синтаксиса для описания структур". За некоторое время программирования на Kotlin у меня сложилось впечатление, что в нём если нельзя, но очень хочется, то можно. И я решил попробовать написать свой DSL для описания структуры данных. Вот что из этого получилось.

Эта статья родилась по мотивам вот этой статьи в виде полу-шутки. В той статье большая часть "проблем" является либо синтетическими и крайне редко используемыми, либо притянутыми за уши из-за ожидания соответствия языка теоретической парадигме которой, по мнению автора, язык должен соответствовать. С другой стороны не упомянуты вещи, которые мне лично действительно усложняют жизнь.

Типы сообщений ошибок и предупреждений Kotlin

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

Вводная

Статья основана на версии Kotlin «1.1-М04».

Эта статья посвящена описанию механизма генерации автоматических классов компилятором Kotlin для анонимного блока пользовательского кода. Описано в каких случаях создаются автоматические классы, где они располагаются, как реализованы и используются.

В Java существует только один способ создания элемента кода – это лямбда-выражение, которое может реализовывать только функциональный интерфейс (подробнее см. в документации на Java). В Kotlin существует несколько различных способов описать объект, содержащий пользовательский код.

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

fun Action( cb:()->Unit ) { cb() }
fun Test() {
  Action{
    // Этот блок кода будет выполнен в функции
  }
}

Как это реализовано и чем чревато использование такого кода в программе?

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

Сериализация (Serialize, в последующем «сохранение») – это процесс сохранения данных объекта во внешнем хранилище.
Эта операция работает в паре с обратной – восстановлением данных, называемой десереализацией (Deserealize, в последующем «восстановление»).

Операции сохранения и восстановления данных применяются очень часто. В классических языках программирования готовых механизмов для сохранения и восстановления данных объектов нет и, при возникновении такой необходимости, приходится создавать их самостоятельно.

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

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

Контекстные действия с элементами списка широко используются с Android-приложениях. Довольно удобно выделить несколько элементов или все элементы списка и применить какое-то действие ко всем выбранным элементам сразу. Удалить, например.

В Android-приложениях для этого может использоваться ActionMode, который позволяет отобразить доступные действия над выделенными элементами поверх Toolbar. Там же можно показывать пользователю сколько элементов выделено в текущий момент или другую полезную информацию. Это удобно и хорошо смотрится, но в некоторых случаях информация, отображаемая на самом Toolbar, может быть важна и скрывать ее не хотелось бы. К примеру, там может быть имя и фото пользователя, список сообщений с которым отображается в списке. При выделении некоторых сообщений полезно было бы видеть имя пользователя, которому эти сообщения адресованы.

В этом случае можно отображать панель контекстных действий с элементами списка поверх самого списка, не загораживая Toolbar. О создании такой панели контекстных действий я и расскажу в этой статье.

Разрабатываемый CustomView — панель контекстных действий я назвал FloatingActionMode или просто FAM.

FloatingActionMode во время работы (Зафиксирован снизу)

Видео — пример работы с FloatingActionMode (Зафиксирован снизу)

В предыдущей статье я сделал беглый обзор async-await в Android. Теперь пришло время погрузиться немного глубже в грядущий функционал kotlin версии 1.1.

Для чего вообще async-await?

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

От переводчика

Это мой первый перевод, поэтому прошу прощения за неточности. Если вы найдете ошибки в переводе, пожалуйста, сообщите об этом. Я не нашел лучшего перевода слова сoroutine, чем сопрограмма, поэтому решил использовать оригинал. Если у вас появятся идеи по этому поводу, буду рад узнать.

Kotlin версии 1.1 принесет в язык coroutin'ы, которые позволяют приостанавливать вычисления в какой-то точке, а затем продолжить их позднее. Очевидный пример этой возможности — async-await, который был добавлен в C# несколько лет назад.

Каждый android разработчик знает, что когда мы имеем дело с сетевыми запросами или другими I/O задачами, то нам необходимо удостовериться, что не происходит блокировка основного потока, а так же, что мы не трогаем UI из фонового потока. На протяжении многих лет приходят и уходят десятки приемов. В этой статье перечислены наиболее популярные, и показаны примеры удобства, которое несет с собой async-await.

Открытие

Всем привет!

Эта статья про реализацию одного конкретного DSL (domain specific language, предметно-ориентированный язык) для регулярных выражений средствами Kotlin, но при этом она вполне может дать общее представление, о том, как написать свой DSL на Kotlin и что обычно будет делать "под капотом" любой другой DSL, использующий те же возможности языка.

Многие уже используют Kotlin или хотя бы пробовали это делать, да и остальные вполне могли слышать о том, что Kotlin располагает к написанию изящных DSL, чему есть блестящие примеры — Anko и kotlinx.html.

Конечно же, для регулярных выражений подобное уже делали (и ещё: на Java, на Scala, на C# — реализаций много, похоже, это распространённое развлечение). Но если хочется попрактиковаться или попробовать DSL-ориентированные языковые возможности Kotlin, то добро пожаловать под кат.

variable("hello") + variable("habr") * 2016 where ("hello" to 1) and ("habr" to 2)

name?.length

Наша команда, аналогично с автором статьи, уже почти как год перешла со Scala на Kotlin в качестве основного языка. Мое мнение во многом совпадает с автором, поэтому предлагаю вам перевод его интересной статьи.

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

Ниже я хочу привести примеры, которые мне нравятся в Scala и Kotlin, а также их сравнение в том, как они реализованы в обоих языках.