Компания Google объявила (https://android-developers.googleblog.com/2017/05/android-an... о включении Kotlin (https://kotlinlang.org/) в список официально поддерживаемых языков для разработки приложений для платформы Android. Более того, совместно с компанией JetBrains, курирующей разработку Kotlin, инициировано создание некоммерческой организации, которой будут делегированы функции принятия решений в отношении дальнейшего развития языка.
Язык Kotlin создан в санкт-петербургском центре разработки компании JetBrains и изначально рассчитан на компиляцию приложений в форму для последующего выполнения внутри стандартной виртуальной машины Java (JVM) или Android. Разработчики Kotlin попытались сохранить максимальную совместимость и похожесть на Java, при этом избавившись от имеющихся в Java ограничений и недостатков. Язык обеспечивает нелохую переносимость с Java - из программ на Java вызывать компоненты, написанные на Kotlin, и, наоборот, из программ Kotlin можно вызывать Java-классы. Среди отличий Kotlin выделяется ориентация на обеспечение более высокой безопасности за счет реализации статических проверок, отсутствия raw-типов, полного сохранения информации о типах в процессе выполнения и реализации массивов в виде инварианта (http://confluence.jetbrains.net/display/Kotlin/Basic+types#B.... Язык обеспечивает поддержку функций высшего порядка (http://ru.wikipedia.org/wiki/%D0%A4%D1%8... вывода типов (http://ru.wikipedia.org/wiki/%D0%92%D1%8... значений, уточняющих "примесей (http://ru.wikipedia.org/wiki/%D0%9F%D1%8... (mixin) и делегирования (http://ru.wikipedia.org/wiki/%D0%94%D0%B....
Одновременно представлен (https://android-developers.googleblog.com/2017/05/android-st... тестовый выпуск интегрированной среды разработки Android Studio 3.0 (https://developer.android.com/studio/preview/index.html), в состав которой включён плагин для написание Android-приложений на языке Kotlin. Кроме средств для сопровождения разработки плагин предоставляет возможность преобразования имеющихся Java-проектов в представление для дальнейшей разработки на языке Kotlin.Из других заметный улучшений в Android Studio 3.0 отмечается новый набор инструментов для профилирования и диагностики проблем с производительностью, а также существенное ускорение процесса сборки больших проектов с использованием Gradle, включение Google Play Store и поддержки OpenGL ES 3.0 в эмулятор Android, поддержка разработки для Android Things, средства разработки Instant App (приложения, которые можно напрямую запускать из Google Play без выполнения процесса установки), поддержка новых возможностей языка Java 8 и платформы Android O, режим отладки уже собранных APK-файлов.
URL: https://android-developers.googleblog.com/2017/05/android-an...
Новость: http://www.opennet.me/opennews/art.shtml?num=46568
Очередной проблемно-ориентированный язык.
"Мышки плакали, кололись, но продолжали жрать кактус!" (с)
Очередная реинкарнация Паскаля.
"Мышки не смогли осилить ничего выше школьного курса информатики, но тоже хотят в IT" (с)
сейчас в школах помимо паскаля доступны СИ, пейтон, жабаскрипт.
Да тут целый тред экспертов!
Среди учащихся всегда много экспертов.
> Среди учащихся всегда много экспертов....и только те, кто сами ничего не умеют, удут дугих учить.
Всегда знал что с преподшой было что-то не так.
ага, иди Сократу расскажи
один дурак скажет, так другой обязательно повторит
Крепитесь, скоро ещё и каникулы.
больше всяких языков, на которых даже олигофрен программировать сможет. ну и полученный код сможет любое быстрое железо легко опустить.
Лучше бы Rust запилили. А то шило на мыло.
Для гугла перейти на Rust - значит признать бесполезность Go. Это примерно то же, что надеяться на официальное включение Swift в андроид-студию
Cмешались в кучу кони, люди.
Вообще разные языки с разными назначениями.
Был уже вброс: https://thenextweb.com/dd/2016/04/07/google-facebook-uber-swift
С каких пор Rust стал инструментом для относительно быстрой разработки с большим инструментарием?
Хеллоувордщикам хочется переписать весь мир на ассемблере.
> RustОчень долго компилируется, почти как WebKit-Gtk2.
А ее какие языки там поддерживаются и почему этой студии нет в репах?
Есть она в репах. Дистрибутив меняйте.
сразу видно большинство комментаторов ничего не писали под android, но мнение имеют
Прохожий #мимопроходя сказал ровно настолько насколько смог выщурить со стороны.
я бы сказал больше - большинство комментаторов даже рядом с андроид разработчиками не сидели
Не так, я думаю все еще хуже: большинство комментаторов даже рядом с разработчиками не сидели.
> Не так, я думаю все еще хуже: большинство комментаторов даже рядом с
> разработчиками не сидели.Может хватит называть html верстальщиков разработчиками?
Алгебраические типы данных и pattern-matching в Kotlin уже добавили? Если нет - то ненужно. Зачем вообще создавать язык в 2010-х, не закладывая в него этих фич?
Первая "фича" в языке, поддерживающем ООП может и имеет какой-то смысл (хотя обычно спокойно делается в библиотеке). Вторая - на фиг не нужна, а то и вредна. На то и наследование, требующее вменяемого проектирования вместо ad-hoc подхода pattern-matching.
Библиотечная реализация алгебраических типов через ООП всегда будет выглядеть более громоздкой чем реализация "в языке".
>Вторая - на фиг не нужна, а то и вредна. На то и наследование, требующее вменяемого проектирования вместо ad-hoc подхода pattern-matching.И почему тогда разработчики Swift и C# так не считают т.к. реализовали/добавили pattern-matching? Никто ведь не призывает использовать pattern-matching вместо наследования с виртуальными методами.
И да, Kotlin разве не мультипарадигмальный язык, что вы делаете такой упор на ООП?
Что там громоздкого? Описал Variant - и вперёд.Тоже мне, примеры.
Swift - вообще не аргумент, судя по ругани сидящих рядом со мной ios-ников это полигон, в который напихали что можно и что нельзя без какого-либо проектирования. Шарп - тем более сборная солянка, созданная в надежде привлечь всех мыслимых developers.А на ООП я в данном случае делаю упор, потому что оно предоставляет гораздо более поддерживаемый подход, чем pattern matching. Ровно то же различие, что, например, между case c кодами ошибки и иерархией исключений, или между finally и плюсовым RAII, или между пользовательской функцией init и конструктором - в одном случае можно что-то забыть или сделать неконсистентно, во втором - получаешь предсказуемое поведение.
Попробуйте реализовать что-то похожее https://doc.rust-lang.org/std/result/ через ООП без patter-matching и алгебраических типов данных, а потом попробуйте это использовать. И не надо здесь говорить, что нужно использовать исключения - есть случаи, когда похожий на Result подход более приемлем.Сразу скажу, что получается громоздко и далеко не так красиво, как в Rust: приходится каждый раз создавать классы для возвращаемых значений функции вместо использованиями sum-type; отсутствует возможность проверки на этапе компиляции, все ли типы в switch-е перебрал из sum-type, реализованного в виде иерархии/композиции классов.
Нет, спасибо, я лучше пешком постою. Кром совсем уж сурового эмбеда такого же сурового легаси именно исключения и надо использовать. Я вдоволь напроверялся ошибок на C чтобы ненавидеть этот адски неудобный (и тормозной) подход.И нет, в приличных языках вроде С++/D ничего каждый раз создавать не надо - делается один раз шаблон с неявным преобразованием в тип-результат, для проверки статуса ошибки - либо специальная функция (для параноиков), либо реализовываем оператор преобразования в bool. Выглядит всё совершенно прозрачно. А проблема "все ли типы в свитче перебрал" - это явно не к этому примеру, здесь перебирать нечего. А там, гд ехочется перебрать - нужны интферфейсы/абстрактные классы и наследование, там не реализовать метод не дадут.
> А проблема
> "все ли типы в свитче перебрал" - это явно не к
> этому примеру, здесь перебирать нечего. А там, гд ехочется перебрать -
> нужны интферфейсы/абстрактные классы и наследование, там не реализовать метод не дадут.Ок. Пример: модуль взвращает ошибки 5-и типов (пусть будут хоть объекты Exception-в, если вам они ближе). У модуля 2 пользователя и каждый из них по-совему обрабатывает ошибки этих типов.
Обработка этих ошибок реализуется довольно просто и надёжно в виде свича по этим типам, если язык поддерживает проверку, что все типы из возможных проверены. Не надо ничего более создавать.
Как вы предлагаете обрабатывать эти ошибки с помощью интерфейсов и наследования?
Вот (следуя подсказке анонима в ветке ниже) как это будет выглядеть на сабже для 3х типов:sealed class ErrorException : Throwable()
class ErrorException1 : ErrorException()
class ErrorException2 : ErrorException()
class ErrorException3 : ErrorException()
class MyModule
{
fun Foo(x: Int) : Int
{
when (x)
{
1 -> throw ErrorException1()
2 -> throw ErrorException2()
3 -> throw ErrorException3()
else -> { return x;}
}
}
}fun main(args: Array<String>) {
val myModule = MyModule()
try
{
println(myModule.Foo(2))
}
catch(e: ErrorException)
{
when(e)
{
is ErrorException1 -> println("E1")
is ErrorException2 -> println("E2")
is ErrorException3 -> println("E3")
}
}
try
{
println(myModule.Foo(8))
}
catch(e: ErrorException)
{
when(e)
{
is ErrorException1 -> println("EE1")
is ErrorException2 -> println("EE2")
is ErrorException3 -> println("EE3")
}
}
}
> Swift - вообще не аргумент, судя по ругани сидящих рядом со мной
> ios-ников это полигон, в который напихали что можно и что нельзя
> без какого-либо проектирования.И это правда, переход на версию 3 был болезненным. Но надо отдать должное для своих лет очень даже неплохо всего понапихали.
> И почему тогда разработчики [...] C# [...] реализовали/добавили pattern-matching?Не удивлюсь, если в итоге по соображениям вида "вали всё в раковину", которая kitchen-sink.
Вообще-то в котлине более широкий подход чем pattern matching. К тому-же оператор when вкупе со смарт кастами делает то же самое что и паттерн матчинг, нет нужды реализовывать его отдельно.
и что, when + smart casts на этапе компиляции обнаружит добавление ещё одного дочернего класса для базового типа, объект которого проверяется в when?
Обнаружит, но только при условии использования sealed классов.
Тогда за это большой плюс для Kotlin!
Не обнаруживает, хотя по спецификации действительно должен.
https://try.kotlinlang.org/#/UserProjects/125pl5cgj8l6daio9v...Может ещё сырой?
А кложуру не добавили? Понятно, Андроид всё ещё не нужен.
Это кложур (всё ещё и уже) не нужен
Так здорово же. JetBrains молодцы!
но зачем, когда есть groovy?
Сравнили ж*пу с пальцем. Еще бы с php сравнили (а что, есть jphp).
Лучше бы официально C# добавили без взяких Замаринов.
но зачем - еси java то же самое и уже давно есть
> KotlinОтлично!
Очередное "ненужно"! :)))
Всегда хотел спросить у тех кто пишет "ненужно" - а что "нужно"?