Kotlin — язык другого предназначения. Чтобы понять, какое место он занимает в иерархии языков JVM, нужно обратиться к истории, как это ни странно, языков под CLR.
Под CLR существуют два главных языка — это C# и F#, которые соответствуют Java и Scala в JVM-мире. F# как и Scala развивается очень быстро, экспериментирует в слиянии различных парадигм и подходов. Все, что достаточно обкаталось на F# через пару лет появляется в C#. Так в новых C# появились кортежи, линк и вся остальная функциональщина.
Проблемой же Java в данном случае является маниакальный принцип совместимости с кодом 20 летней давности. И все новые идеи из Scala она в себя либо интегрирует очень медленно, либо не интегрирует вовсе. С интегрированным тоже есть проблема. Если вы посмотрите историю Java, то увидите, что многие решения интегрируются крайне криво из-за принципа полной совместимости. И каждая выходящая фича получается defective by design. Например, дженерики в Java, которые можно взорвать в три строчки. Объявление ко/контравариантности в месте вызова, а не объявления. Stream API из Java 8 тоже вышло очень сильно кривеньким и не таким удобным как в Scala.
А людям хочется программировать уже на чем-то более удобном, чем Java. Так и появился Kotlin, который, если вы посмотрите поближе, является смесью Scala и C#. И людям он понравился, потому что удобнее и красивее Java. Ну неприятно людям в 2016 году не иметь таких базовых удобств, как type inference например.
Несмотря на все вышенописанное все же хочу отметить, что Scala и F# — не являются просто песочницами для экспериментирования, а являются полноценными языками с собственной философией и парадигмой.
На поддержание компиляцию в CLR требовалось очень много ресурсов. И когда человеческих ресурсов стало не хватать, проект закрыли. Потому что было непонятно какие преимущества это дает, и необходимость компиляции в CLR была крайне сомнительна по ряду причин
На CLR есть F#, который по духу и идеям очень близок к Scala.
JVM работает под виндой, непонятно зачем нужен тогда CLR, который ни под чем другим не запускается.
При разработке возникало множество проблем из-за различий внутреннего устройства виртуальных машин и различий в стандартной библиотеки.
Одним из главных плюсов разработки на Scala является все-таки возможность использовать любую из миллионов Java-библиотек.
Если вам нужно написать, к примеру, консольную утилиту, то вы не можете ждать пока у вас поднимется java
runtime, пока он прогреется. Вам нужен мгновенный запуск и чтобы все было быстро сразу.
Scala Native — это что-то уровня C. Оно может использовать низкоуровневые структуры данных, указатели, дергать функции из C и компилируется в честный бинарник.
На сайте есть примеры использования структур и объявления интерфейса к malloc, и получения указателя. То есть по сути вы пишете со Scala синтаксисом на C.
А как вы даете номера версиям? Если Idea 15 вышла всего несколько месяцев назад, то почему эта версия уже 16, а не 15.1 например?
Ведь никаких особых мажорных изменений вроде бы нет.
На сайте Kotlin есть сравнение, где сказано, что если вы счастливы со Scala, то Kotlin вам не нужен. Основное различие состоит в том, что Kotlin позиционирует себя как better Java, а у Scala все же своя парадигма и идеология.
В самом Scala dotty тулзы по выпиливанию кода не будет. Будет тулза linker поверх компилятора, разработкой которой занимается хабраюзер darkdimius. И выпиливание ненужного кода — это лишь часть работы, которую linker делает. Он также оптимизирует (ан)боксинг примитивных типов и value-классов. Кроме того ожидается оптимизация создания быстроумирающих объектов в off-heap.
Интересно другое. Кто может в трезвом уме заплатить за логотип $29,6 млн? Зачем? Почему бы не заказать 100 логотипов за $1.000 и выбрать из них лучший?
Вот спасибо. После просмотра нормального примера кода на Обероне без однобуквенных имен переменных и процедур, не такими уж и плохими кажутся BEGIN-END вместо скобок
Это лечится код стайлом, запрещающем писать как-то иначе. И со временем это вживается в подкорку мозга, и ты забываешь, что можно их и не ставить.
В крайнем случае, это лечится статическим анализатором, в котором прописана выдача ошибки на написание if без скобок.
Они стали популярны не просто так.
Скобочки (особенно в сочетании с отступами) делают код гораздо более наглядным и логически разделенным.
BEGIN-END плохо выполняют эту роль, потому как по написанию сливаются с самим кодом.
А отступы без скобочек не так наглядны и иногда порождают проблемы, которые описаны в комментарии выше
Лично я бросил курс по алгоритмам и структурам данных на Coursera по одной простой причине. Я записался туда, чтобы узнать что-то полезное для работы, что-то применимое на практике, а курс оказался полон теоретической «воды» с кучей уравнений. К реальности курс не имел почти никакого отношения, и никакой пользы для работы программиста он не имел. До конца надеясь, что дальше будет что-то хорошее и умное, я прослушал пару десятков уроков, но в конце концов бросил это дело.
Сразу на ум приходит несколько вещей.
1) Доступ к хардварным частям устройства. Через HTML/js это если и возможно, то очень трудно
2) Доступ к частям операционной системы.
3) Стандартизация интерфейсов. Хорошо, когда гайдлайны по UI намертво вшиты в платформу. Например, интерфейс любого приложения под Андроид, сделанного стандартными средствами может быть плох, но не отвратителен. А если дать разработчикам возможность лепить на HTML/js, то родится адское множество монстров.
Под CLR существуют два главных языка — это C# и F#, которые соответствуют Java и Scala в JVM-мире. F# как и Scala развивается очень быстро, экспериментирует в слиянии различных парадигм и подходов. Все, что достаточно обкаталось на F# через пару лет появляется в C#. Так в новых C# появились кортежи, линк и вся остальная функциональщина.
Проблемой же Java в данном случае является маниакальный принцип совместимости с кодом 20 летней давности. И все новые идеи из Scala она в себя либо интегрирует очень медленно, либо не интегрирует вовсе. С интегрированным тоже есть проблема. Если вы посмотрите историю Java, то увидите, что многие решения интегрируются крайне криво из-за принципа полной совместимости. И каждая выходящая фича получается defective by design. Например, дженерики в Java, которые можно взорвать в три строчки. Объявление ко/контравариантности в месте вызова, а не объявления. Stream API из Java 8 тоже вышло очень сильно кривеньким и не таким удобным как в Scala.
А людям хочется программировать уже на чем-то более удобном, чем Java. Так и появился Kotlin, который, если вы посмотрите поближе, является смесью Scala и C#. И людям он понравился, потому что удобнее и красивее Java. Ну неприятно людям в 2016 году не иметь таких базовых удобств, как type inference например.
Несмотря на все вышенописанное все же хочу отметить, что Scala и F# — не являются просто песочницами для экспериментирования, а являются полноценными языками с собственной философией и парадигмой.
runtime, пока он прогреется. Вам нужен мгновенный запуск и чтобы все было быстро сразу.
Scala Native — это что-то уровня C. Оно может использовать низкоуровневые структуры данных, указатели, дергать функции из C и компилируется в честный бинарник.
На сайте есть примеры использования структур и объявления интерфейса к malloc, и получения указателя. То есть по сути вы пишете со Scala синтаксисом на C.
Ведь никаких особых мажорных изменений вроде бы нет.
В самом Scala dotty тулзы по выпиливанию кода не будет. Будет тулза linker поверх компилятора, разработкой которой занимается хабраюзер darkdimius. И выпиливание ненужного кода — это лишь часть работы, которую linker делает. Он также оптимизирует (ан)боксинг примитивных типов и value-классов. Кроме того ожидается оптимизация создания быстроумирающих объектов в off-heap.
Я не знаю специфики C++, но в том же куске кода из статьи в двух идущих подряд линиях написано и klass и class
begin;
int beginningBegin = 25;
int endd = 34;
if (beginningBegin > endd)
then
begin
beginningBegin -= beginningBegin;
endd = endd — beginningBegin;
end;
beginningBegin = 45;
end;
В крайнем случае, это лечится статическим анализатором, в котором прописана выдача ошибки на написание if без скобок.
Скобочки (особенно в сочетании с отступами) делают код гораздо более наглядным и логически разделенным.
BEGIN-END плохо выполняют эту роль, потому как по написанию сливаются с самим кодом.
А отступы без скобочек не так наглядны и иногда порождают проблемы, которые описаны в комментарии выше
1) Доступ к хардварным частям устройства. Через HTML/js это если и возможно, то очень трудно
2) Доступ к частям операционной системы.
3) Стандартизация интерфейсов. Хорошо, когда гайдлайны по UI намертво вшиты в платформу. Например, интерфейс любого приложения под Андроид, сделанного стандартными средствами может быть плох, но не отвратителен. А если дать разработчикам возможность лепить на HTML/js, то родится адское множество монстров.
Хотя, возможно, Вы и правы. Время покажет.